Por padrão, o Cloud Data Fusion usa o escalonamento automático como perfil de computação. É difícil estimar o número ideal de workers (nós) de cluster para uma carga de trabalho, e um único tamanho de cluster para um pipeline inteiro geralmente não é o ideal. O escalonamento automático do Managed Service for Apache Spark 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, em que é possível ver uma lista de perfis, há uma coluna Total de núcleos, que tem o número máximo de vCPUs que o perfil pode escalonar verticalmente, como Up to 84.
Se você quiser usar o perfil de computação do Managed Service for Apache Spark , gerencie os tamanhos dos 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ê 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 saber se você precisa de nós mestres maiores, monitore o uso de memória e CPU no nó. Recomendamos dimensionar os nós de trabalho com pelo menos 2 CPUs e 8 GB de memória. Se você configurou 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 dimensionar os nós de trabalho com pelo menos 2 CPUs e 8 GB de memória. Se você configurou os 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 worker terá 4 CPUs e 12 GB disponíveis para executar contêineres do YARN. Se o pipeline estiver configurado para executar 1 CPU e executores de 8 GB, o YARN não poderá executar mais de um contêiner por nó de trabalho. Cada nó de trabalho 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, a memória YARN e as CPUs precisam ser um múltiplo exato da quantidade necessária por executor do Spark. Para verificar quanta memória cada worker reservou para o YARN, confira a propriedade yarn.nodemanager.resource.memory-mb no YARN.
Se você estiver usando o Managed Service para Apache Spark, 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. Alguns tamanhos de worker comuns e as configurações correspondentes do YARN estão na tabela a seguir.
| 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 definida para o pipeline, e o YARN arredonda esse valor para cima. Por exemplo, suponha que você tenha definido a memória do executor como 2.048 MB e não tenha informado um valor para spark.yarn.executor.memoryOverhead, o que significa que o padrão de 384 MB será usado. Isso significa que o Spark solicita 2.048 MB + 384 MB para cada executor, que o YARN arredonda para um múltiplo exato da alocação mínima do YARN. Ao executar em um nó de trabalho de 8 GB, como a alocação mínima do YARN é de 512 MB, ela é arredondada para 2,5 GB. Isso significa que cada worker pode executar dois contêineres, usando todas as CPUs disponíveis, mas deixando 1 GB de memória do YARN (6 GB - 2,5 GB - 2,5 GB) sem uso. Isso significa que o nó de trabalho pode 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, 2048 MB + 1024 MB são arredondados 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 dar 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 trabalho 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 que sobrem recursos extras. Você também pode multiplicar o tamanho dos workers. Por exemplo, se a memória do executor estiver 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 uma 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 e no máximo 26 GB de memória. 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 embaralhamentos, 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 causam um grande impacto na performance. Se o pipeline estiver embaralhando muitos dados, a performance do disco fará diferença. Se você estiver usando o Managed Service para Apache Spark, recomendamos usar 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 aos requisitos de performance.
Número de workers
Para minimizar o tempo de execução, verifique se o cluster é grande o suficiente para executar o máximo possível em paralelo. Por exemplo, se a origem do pipeline ler dados usando 100 divisões, verifique se o cluster é grande o suficiente para executar 100 executores de uma só vez.
A maneira mais fácil de saber se o cluster está subdimensionado é analisar a memória pendente do YARN ao longo do tempo. Se você estiver usando o Managed Service para Apache Spark, um gráfico poderá ser encontrado na página de detalhes do cluster.
Se a memória pendente for alta por longos períodos, aumente o número de workers para adicionar essa capacidade extra ao cluster. No exemplo anterior, o cluster precisa ser aumentado 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 worker primário sejam envolvidos ao embaralhar dados. Como os workers secundários não são mais responsáveis pelos dados intermediários de embaralhamento, quando eles são removidos de um cluster, os jobs do Spark não sofrem atrasos nem erros. Como os workers principais nunca são reduzidos, o cluster é reduzido com mais estabilidade e eficiência. Se você estiver executando pipelines com embaralhamentos em um cluster estático, recomendamos usar o EFM.
Para mais informações sobre o EFM, consulte Modo de flexibilidade avançada do Managed Service para Apache Spark.