Por predefinição, o Cloud Data Fusion usava a escala automática como perfil de computação. Estimar o melhor número de trabalhadores de cluster (nós) para uma carga de trabalho é difícil, e um único tamanho de cluster para um pipeline inteiro não é, muitas vezes, o ideal. O redimensionamento automático do Dataproc oferece um mecanismo para automatizar a gestão de recursos do cluster e permite o redimensionamento automático da VM de trabalho do cluster. Para mais informações, consulte o artigo Ajuste automático de escala
Na página Configuração de computação, onde pode ver uma lista de perfis, existe uma coluna Total de núcleos, que tem o número máximo de CPUs virtuais que o perfil pode aumentar, como Up to 84.
Se quiser usar o perfil de cálculo do Dataproc , pode gerir os tamanhos dos clusters com base no tamanho do pipeline.
Nó principal
Os nós principais usam recursos proporcionais ao número de pipelines ou aplicações adicionais que estão a ser executados no cluster. Se estiver a executar pipelines em clusters efémeros, use 2 CPUs e 8 GB de memória para os nós principais. Se estiver a usar clusters persistentes, pode precisar de nós principais maiores para acompanhar o fluxo de trabalho. Para saber se precisa de nós principais maiores, pode monitorizar a memória e a utilização da CPU no nó. Recomendamos que dimensione os nós de trabalho com, pelo menos, 2 CPUs e 8 GB de memória. Se tiver configurado os seus pipelines para usar maiores quantidades de memória, tem de usar trabalhadores maiores.
Para minimizar o tempo de execução, certifique-se de que o cluster tem nós suficientes para permitir o máximo de processamento paralelo possível.
Trabalhadores
As secções seguintes descrevem aspetos do dimensionamento dos nós de trabalho.
CPU e memória
Recomendamos que dimensione os nós de trabalho com, pelo menos, 2 CPUs e 8 GB de memória. Se configurou os seus pipelines para usar maiores quantidades de memória, use trabalhadores maiores. Por exemplo, com um nó de trabalho de 4 CPUs e 15 GB, cada trabalhador tem 4 CPUs e 12 GB disponíveis para executar contentores YARN. Se a sua pipeline estiver configurada para executar 1 CPU, 8 GB de executores, o YARN não consegue executar mais do que um contentor por nó de trabalho. Cada nó de trabalho teria 3 CPUs e 4 GB adicionais que seriam desperdiçados porque não podem ser usados para executar nada. Para maximizar a utilização de recursos no cluster, é recomendável que a memória YARN e os processadores sejam um múltiplo exato da quantidade necessária por executor do Spark. Pode verificar a quantidade de memória que cada trabalhador reservou para o YARN
verificando a propriedade yarn.nodemanager.resource.memory-mb no YARN.
Se estiver a usar o Dataproc, a memória disponível para os contentores do YARN é aproximadamente 75% da memória da VM. O tamanho mínimo do contentor YARN também é ajustado consoante o tamanho das VMs de trabalho. Alguns tamanhos de worker comuns e as respetivas definições do YARN são apresentados na tabela seguinte.
| CPU do worker | Memória do trabalhador (GB) | Memória do nó do YARN (GB) | Memória de atribuiçã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 |
Tenha em atenção que o Spark pede mais memória do que a memória do executor definida para o pipeline e que o YARN arredonda esse valor pedido para cima. Por exemplo, suponhamos que definiu a memória do executor como 2048 MB e não
atribuiu um valor a spark.yarn.executor.memoryOverhead, o que significa que é usado o valor predefinido
de 384 MB. Isto significa que o Spark pede 2048 MB + 384 MB para cada executor, que o YARN arredonda para um múltiplo exato da atribuição mínima do YARN. Quando é executado num nó de trabalho de 8 GB, uma vez que a atribuição mínima do YARN é de 512 MB, é arredondada para 2,5 GB. Isto significa que cada worker pode executar dois contentores, usando todas as CPUs disponíveis, mas deixando 1 GB de memória YARN (6 GB - 2,5 GB - 2,5 GB) por usar. Isto significa que o nó de trabalho pode ser, na verdade, um pouco mais pequeno, ou os executores podem receber um pouco mais de memória.
Quando executado num nó de trabalho de 16 GB, 2048 MB + 1024 MB é
arredondado para 3 GB porque a atribuição mínima do YARN é de 1024 MB.
Isto significa que cada nó de trabalho pode executar quatro contentores, com todas as CPUs
e a memória YARN em utilização.
Para ajudar a dar contexto, a tabela seguinte mostra os tamanhos de trabalhadores recomendados para alguns tamanhos de executores comuns.
| CPU do executor | Memória do executor (MB) | CPU do trabalhador | Memória do trabalhador ( GB) |
|---|---|---|---|
| 1 | 2048 | 4 | 15 |
| 1 | 3072 | 4 | 21 |
| 1 | 4096 | 4 | 26 |
| 2 | 8192 | 4 | 26 |
Por exemplo, um nó de trabalho de 26 GB traduz-se em 20 GB de memória utilizável para executar contentores YARN. Com a memória do executor definida como 4 GB, é adicionado 1 GB como sobrecarga, o que significa 5 GB de contentores YARN para cada executor. Isto significa que o trabalhador pode executar quatro contentores sem recursos adicionais restantes. Também pode multiplicar o tamanho dos trabalhadores. Por exemplo, se a memória do executor estiver definida como 4096 GB, um trabalhador com 8 CPUs e 52 GB de memória também funciona bem. As VMs do Compute Engine restringem a quantidade de memória que a VM pode ter com base no número de núcleos. Por exemplo, uma VM com 4 núcleos tem de ter, pelo menos, 7,25 GB de memória e, no máximo, 26 GB de memória. Isto significa que um executor configurado para usar 1 CPU e 8 GB de memória usa 2 CPUs e 26 GB de memória na VM. Se, em alternativa, os executores estiverem configurados para usar 2 CPUs e 8 GB de memória, todas as CPUs são usadas.
Disco
O disco é importante para alguns pipelines, mas não para todos. Se o seu pipeline não contiver nenhuma mistura, o disco só é usado quando o Spark fica sem memória e precisa de transferir dados para o disco. Para estes tipos de pipelines, o tamanho e o tipo do disco geralmente não têm um grande impacto no desempenho. Se o seu pipeline estiver a misturar muitos dados, o desempenho do disco faz a diferença. Se estiver a usar o Dataproc, recomendamos que use tamanhos de disco de, pelo menos, 1 TB, uma vez que o desempenho do disco aumenta com o tamanho do disco. Para obter informações acerca do desempenho do disco, consulte o artigo Configure os discos de forma a cumprir os requisitos de desempenho.
Número de trabalhadores
Para minimizar o tempo de execução, deve garantir que o cluster é suficientemente grande para poder executar o máximo possível em paralelo. Por exemplo, se a origem do pipeline ler dados com 100 divisões, deve certificar-se de que o cluster é suficientemente grande para executar 100 executores em simultâneo.
A forma mais fácil de saber se o cluster tem um tamanho inferior ao necessário é analisar a memória pendente do YARN ao longo do tempo. Se estiver a usar o Dataproc, pode encontrar um gráfico na página de detalhes do cluster.
Se a memória pendente for elevada durante longos períodos, pode aumentar o número de trabalhadores para adicionar essa capacidade adicional ao cluster. No exemplo anterior, o cluster deve ser aumentado em cerca de 28 GB para garantir que é atingido o nível máximo de paralelismo.
Modo de flexibilidade melhorada (EFM)
O EFM permite-lhe especificar que apenas os nós de trabalho principais estão envolvidos na mistura aleatória de dados. Uma vez que os trabalhadores secundários já não são responsáveis pelos dados de mistura intermédios, quando são removidos de um cluster, as tarefas do Spark não sofrem atrasos nem erros. Uma vez que os trabalhadores principais nunca são reduzidos, o cluster é reduzido com mais estabilidade e eficiência. Se estiver a executar pipelines com misturas num cluster estático, recomendamos que use o EFM.
Para mais informações sobre o EFM, consulte o artigo Modo de flexibilidade melhorada do Dataproc.