O Cloud Data Fusion usava o Autoscale como o perfil de computação por padrão. É difícil estimar o número ideal de workers de cluster (nós) para uma carga de trabalho, e um único tamanho de cluster para um pipeline inteiro geralmente não é ideal. O escalonamento automático do Dataproc fornece um mecanismo para automatizar o gerenciamento de recursos do cluster e permite o escalonamento automático da VM de worker do cluster. Para mais informações, consulte Escalonamento automático.
Na página Configuração de computação, onde você pode conferir uma lista de perfis, há uma coluna Total de núcleos, que mostra o número máximo de vCPUs que o perfil pode escalar, como Up to 84.
Se você quiser usar o perfil de computação do Dataproc , poderá gerenciar os tamanhos de cluster 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ê estiver executando pipelines em clusters efêmeros, use 2 CPUs e 8 GB de memória para os nós mestres. Se você estiver usando clusters persistentes, talvez precise de nós mestres maiores para acompanhar o fluxo de trabalho. Para entender se você precisa de nós mestres maiores, monitore o uso de memória e CPU no nó. Recomendamos o dimensionamento dos nós de trabalho com pelo menos 2 CPUs e 8 GB de memória. Se você tiver configurado os pipelines para usar quantidades maiores de memória, use 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 aspectos do dimensionamento de nós de trabalho.
CPU e memória
Recomendamos o dimensionamento dos nós de trabalho com pelo menos 2 CPUs e 8 GB de
memória. Se você tiver configurado os pipelines para usar quantidades maiores de memória, use workers maiores. Por exemplo, com um nó de worker de 4 CPUs e 15 GB, cada worker terá 4 CPUs e 12 GB disponíveis para executar contêineres do YARN. Se
o pipeline estiver configurado para executar 1 CPU, executores de 8 GB, o YARN não poderá
executar mais de um contêiner por nó de worker. Cada nó de worker teria
mais 3 CPUs e 4 GB 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 e as CPUs do YARN sejam um múltiplo exato da quantidade necessária por
executor do Spark. É possível verificar a quantidade de memória que 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 contêineres do YARN será de aproximadamente 75% da memória da VM. O tamanho mínimo do contêiner do YARN também é ajustado dependendo do tamanho das VMs de worker. Confira na tabela a seguir alguns tamanhos de worker comuns e as configurações do YARN correspondentes.
| CPU do worker | Memória do worker (GB) | Memória do nó YARN (GB) | Memória mínima de alocação do YARN (MB) |
|---|---|---|---|
| 1 | 4 | 3 | 256 |
| 2 | 8 | 6 | 512 |
| 4 | 16 | 12 | 1024 |
| 8 | 32 | 24 | 1024 |
| 16 | 64 | 51 | 1024 |
O Spark solicita mais memória do que a memória do executor
definida para o pipeline, e o YARN arredonda esse valor solicitado. Por
exemplo, suponha que você tenha definido a memória do executor como 2048 MB e não tenha
atribuído um valor para spark.yarn.executor.memoryOverhead, o que significa que o padrão
de 384 MB é usado. Isso significa que o Spark solicita 2048 MB + 384 MB
para cada executor, que o YARN arredonda para um múltiplo exato da alocação
mínima do YARN. Quando executado em um nó de worker de 8 GB, a alocação mínima do YARN
é arredondada para 2,5 GB, porque é de 512 MB. Isso
significa que cada worker pode executar dois contêineres, usando todas
as CPUs disponíveis, mas deixando 1 GB de memória YARN (6 GB -
2,5 GB - 2,5 GB) não utilizado. Isso significa que o nó de trabalho pode ser
um pouco menor ou que os executores podem receber um pouco mais de memória.
Quando executado em um nó de worker de 16 GB, 2048 MB + 1024 MB é
arredondado para 3 GB, porque a alocação mínima do YARN é de 1024 MB.
Isso significa que cada nó de trabalho pode executar quatro contêineres, com todas as CPUs e a memória do YARN em uso.
Para ajudar a entender o contexto, a tabela a seguir mostra os tamanhos de worker recomendados para alguns tamanhos de executor comuns.
| CPU do executor | Memória do executor (MB) | CPU do 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 worker de 26 GB se traduz em 20 GB de memória utilizável para executar contêineres do YARN. Com a memória do executor definida como 4 GB, 1 GB é adicionado como sobrecarga, o que significa 5 GB de contêineres YARN para cada executor. Isso significa que o worker pode executar quatro contêineres sem recursos extras restantes. Também é possível multiplicar o tamanho dos workers. Por exemplo, se a memória do executor for definida como 4096 GB, um worker com 8 CPUs e 52 GB de memória também funcionará 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 quatro núcleos precisa ter pelo menos 7,25 GB de memória e, no máximo, 26 GB. Isso 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 os executores forem configurados para usar 2 CPUs e 8 GB de memória, todas as CPUs serão utilizadas.
Disco
O disco é importante para alguns pipelines, mas não para todos. Se o pipeline não contiver nenhum embaralhamento, o disco só será usado quando o Spark ficar sem memória e precisar transferir dados para o disco. Para esses tipos de pipelines, o tamanho e o tipo do disco geralmente não têm um grande impacto no desempenho. Se o pipeline estiver embaralhando muitos dados, a performance do disco vai fazer a diferença. Se você estiver usando o Dataproc, é recomendável usar tamanhos de disco de pelo menos 1 TB, já que o desempenho do disco aumenta com o tamanho do disco. Para informações sobre o desempenho do disco, consulte Configurar discos para atender aos requisitos de desempenho.
Número de workers
Para minimizar o tempo de execução, verifique se o cluster é grande o suficiente para ser executado em paralelo. Por exemplo, se a fonte do pipeline ler dados usando 100 divisões, verifique se o cluster é grande o suficiente para executar 100 executores de uma vez.
A maneira mais fácil de saber se o cluster é pequeno é observando a memória pendente do YARN ao longo do tempo. Se você estiver usando o Dataproc, um gráfico pode ser encontrado 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 mais capacidade ao cluster. No exemplo anterior, o cluster precisa ser aumentado em cerca de 28 GB para garantir o nível máximo de paralelismo.
Modo de flexibilidade aprimorado (EFM)
O EFM permite especificar que apenas nós de worker primários sejam envolvidos ao embaralhar dados. Como os workers secundários não são mais responsáveis pelos dados de embaralhamento intermediário, quando eles são removidos de um cluster, os jobs do Spark não apresentam atrasos ou erros. Como os workers primários nunca são reduzidos, o cluster é reduzido com mais estabilidade e eficiência. Se você estiver executando pipelines com shuffles em um cluster estático, recomendamos usar a EFM.
Para mais informações sobre o EFM, consulte Modo de flexibilidade aprimorado do Dataproc.