Por padrão, o Cloud Data Fusion usava escalonamento automático como perfil de computaçã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ê 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ê 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 os aspectos do dimensionamento dos 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ê 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, é 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 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 |
O Spark solicita mais memória do que a memória do executor
definida para o pipeline, e o YARN arredonda esse 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 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 trabalho 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 trabalhadores 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 overhead, o que significa 5 GB de contêineres YARN para cada executor. Isso 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 serã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 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 .
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 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 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 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 os nós de trabalho primários estejam envolvidos no embaralhamento 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.