Por padrão, o Cloud Data Fusion usava escalonamento automático como perfil de computação. Estimar o melhor número de workers (nós) de cluster para uma carga de trabalho é difícil, e um único tamanho de cluster para um pipeline inteiro geralmente não é o ideal. O escalonamento automático do Dataproc fornece um mecanismo para automatizar o gerenciamento de recursos de cluster e permite o escalonamento automático de VM de worker do cluster. Para mais informações, consulte Escalonamento automático
Na página Configuração de computação, onde é possível conferir uma lista de perfis, há um
Coluna Total de núcleos, que tem o máximo de v CPUs que o perfil pode
escalonadas verticalmente, como Up to 84.
Se você quiser usar o perfil de computação do Dataproc , poderá gerenciar de clusters com base no tamanho do pipeline.
Nó mestre
Os nós mestres usam recursos proporcionais ao número de pipelines ou aplicativos extras em execução no cluster. Se você executa pipelines clusters efêmeros, use duas CPUs e 8 GB de memória para o mestre. nós. Se você estiver usando clusters permanentes, talvez sejam necessários nós mestres maiores. para acompanhar o fluxo de trabalho. Para entender se você precisa de nós mestres maiores, é pode monitorar o uso da memória e da CPU no nó. Recomendamos que você dimensione nós de trabalho com pelo menos duas CPUs e 8 GB de memória. Se você configurou seus pipelines para usar quantidades maiores de memória, será necessário usar workers maiores.
Para minimizar o tempo de execução, certifique-se de que seu cluster tenha nós suficientes para permitir o máximo possível de processamento paralelo.
Workers
As seções a seguir descrevem os aspectos do dimensionamento dos nós de trabalho.
CPU e memória
Recomendamos que os nós de trabalho sejam dimensionados com pelo menos 2 CPUs e 8 GB
memória. Se você configurou seus pipelines para usar quantidades maiores de memória, use
workers maiores. Por exemplo, com um nó de trabalho de 4 CPUs e 15 GB, cada
terá 4 CPUs e 12 GB disponíveis para executar contêineres YARN. Se
o pipeline está configurado para executar 1 CPU e 8 GB de executores, o YARN
não consegue executar mais de um contêiner por nó de trabalho. Cada nó de trabalho
ter 3 CPUs e 4 GB extras desperdiçados porque não
executar qualquer coisa. Para maximizar a utilização de recursos no cluster, você precisa
a memória YARN e as CPUs sejam um múltiplo exato da quantidade necessária por
Executor do Spark. É possível verificar quanta memória cada worker reservou para o YARN
verificando a propriedade yarn.nodemanager.resource.memory-mb no YARN.
Se você estiver usando o Dataproc, a memória disponível para o YARN vão representar quase 75% da memória da VM. O tamanho mínimo do contêiner YARN também é ajustado de acordo com o tamanho das VMs de worker. Alguns workers comuns tamanhos e as configurações YARN correspondentes são fornecidas na tabela a seguir.
| CPU do worker | Memória do worker (GB) | Memória do nó YARN (GB) | Memória de alocação mínima do YARN (MB) |
|---|---|---|---|
| 1 | 4 | 3 | 256 |
| 2 | 8 | 6 | 512 |
| 4 | 16 | 12 | 1024 |
| 8 | 32 | 24 | 1024 |
| 16 | 64 | 51 | 1024 |
Lembre-se de que o Spark solicita mais memória do que a memória do executor
definido para o pipeline, e esse YARN arredonda o valor solicitado. Para
Por exemplo, digamos que você tenha definido a memória do executor como 2.048 MB e não
recebeu um valor para spark.yarn.executor.memoryOverhead, o que significa que o padrão
de 384 MB é usado. Isso significa que o Spark solicita 2.048 MB + 384 MB
para cada executor, que o YARN arredonda para um múltiplo exato do YARN
alocação mínima. Quando executado em um nó de trabalho de 8 GB, porque o YARN
a alocação mínima é de 512 MB, ela é arredondada para 2,5 GB. Isso
significa que cada worker pode executar dois contêineres,
CPUs disponíveis, mas deixando 1 GB de memória YARN (6 GB -
2,5 GB a 2,5 GB) não usados. Isso significa que o nó de trabalho pode ser
será um pouco menor, ou os executores podem receber um pouco mais de memória.
Ao executar em um nó de trabalho de 16 GB, 2.048 MB + 1.024 MB são
arredondada para 3 GB, porque a alocação mínima do YARN é de 1.024 MB.
Isso significa que cada nó de trabalho pode executar quatro contêineres, com todas as CPUs
e a memória YARN em uso.
Para contextualizar, a tabela a seguir mostra os tamanhos de worker recomendados, considerando alguns tamanhos comuns de executor.
| CPU do executor | Memória do executor (MB) | CPU de worker | Memória do worker ( GB) |
|---|---|---|---|
| 1 | 2048 | 4 | 15 |
| 1 | 3.072 | 4 | 21 |
| 1 | 4096 | 4 | 26 |
| 2 | 8192 | 4 | 26 |
Por exemplo, um nó de trabalho de 26 GB converte em 20 GB de memória utilizável para executar contêineres YARN. Com a memória do executor definida como 4 GB, 1 GB é adicionados como sobrecarga, o que significa 5 GB de contêineres YARN para cada executor. Isso o que significa que o worker pode executar quatro contêineres sem sobrar recursos extras. Também é possível multiplicar o tamanho dos workers. Por exemplo, se a memória do executor estiver definido como 4.096 GB, um worker com 8 CPUs e 52 GB de memória também funcionam bem. As VMs do Compute Engine restringem a quantidade de memória com base no número de núcleos. Por exemplo, uma VM com quatro núcleos precisa ter pelo menos 7,25 GB de memória e no máximo 26 GB de memória. Isso significa que um executor definido para usar 1 CPU e 8 GB de memória usam 2 CPUs e 26 GB de memória na VM. Se os executores forem configurados para usar duas CPUs e 8 GB de memória, todas as CPUs são utilizadas.
Disco
O disco é importante para alguns pipelines, mas não para todos. Se o pipeline não contiver embaralhamentos, o disco será usado apenas quando o Spark ficar sem memória e precisa transmitir dados para o disco. Para esses tipos de pipelines, o tamanho do disco e tipo geralmente não terão um grande impacto em seu desempenho. Se as pipeline está embaralhando muitos dados, o desempenho do disco fará a diferença. Se estiver usando o Dataproc, recomendamos que use tamanhos de disco de pelo menos 1 TB, já que o desempenho do disco aumenta com o tamanho dele. Para informações sobre o desempenho do disco, consulte Configurar discos para atender .
Número de workers
Para minimizar o tempo de execução, garanta que o cluster é grande o suficiente para ser executado o máximo possível em paralelo. Por exemplo, se a origem do pipeline ler dados usando 100 divisões, convém garantir que é grande o suficiente para executar 100 executores de uma só vez.
A maneira mais fácil de saber se o cluster está subdimensionado é observando o YARN de memória pendente ao longo do tempo. Se você estiver usando o Dataproc, um gráfico pode na página de detalhes do cluster.
Se a memória pendente estiver alta por longos períodos é possível aumentar o número de workers para adicionar essa capacidade extra ao cluster. No exemplo anterior, o cluster precisa aumentar em cerca de 28 GB para garantir que o nível máximo de paralelismo seja alcançado.
Modo de flexibilidade aprimorado (EFM)
O EFM permite especificar que apenas os nós de trabalho primários estejam envolvidos no embaralhamento dados. Como os workers secundários não são mais responsáveis pelo embaralhamento intermediário dados, quando são removidos de um cluster, os jobs do Spark não sofrem atrasos erros. Como os workers primários nunca são reduzidos, o cluster reduz o escalonamento vertical com mais estabilidade e eficiência. Se você estiver executando pipelines com embaralhamento um cluster estático, recomendamos usar o EFM.
Para mais informações sobre EFM, consulte Modo de flexibilidade aprimorado do Dataproc.