Este documento fornece informações sobre o escalonamento automático do Google Cloud Serverless para Apache Spark. Quando você envia sua carga de trabalho do Spark, o Serverless para Apache Spark pode escalonar dinamicamente os recursos da carga de trabalho, como o número de executores, para executar sua carga de trabalho de maneira eficiente. O escalonamento automático do Serverless para Apache Spark é o comportamento padrão e usa a alocação dinâmica de recursos do Spark para determinar se, como e quando escalonar sua carga de trabalho.
Escalonamento automático V2 do Serverless para Apache Spark
A versão 2 (V2) do escalonamento automático sem servidor para Apache Spark adiciona recursos e melhorias à versão 1 (V1) padrão para ajudar você a gerenciar cargas de trabalho sem servidor para Apache Spark, melhorar o desempenho das cargas de trabalho e economizar custos:
- Redução assíncrona de nós: o escalonamento automático V2 substitui a redução síncrona da V1 por uma redução assíncrona. Usando o redução de escalonamento assíncrono, o Serverless para Apache Spark reduz os recursos da carga de trabalho sem esperar que todos os nós concluam a migração de embaralhamento. Isso significa que os nós de cauda longa que reduzir escala vertical lentamente não vão bloquear o upscaling.
- Seleção inteligente de nós para redução de escala: o escalonamento automático V2 substitui a seleção aleatória de nós da V1 por um algoritmo inteligente que identifica os melhores nós para reduzir escala vertical primeiro. Esse algoritmo considera fatores como o tamanho dos dados de embaralhamento e o tempo ocioso do nó.
- Comportamento configurável de desativação gradual do Spark e migração de embaralhamento: o escalonamento automático V2 permite usar propriedades padrão do Spark para configurar a desativação gradual e a migração de embaralhamento do Spark. Esse recurso pode ajudar você a manter a compatibilidade da migração com suas propriedades personalizadas do Spark.
Recursos de escalonamento automático do Serverless para Apache Spark
| Recurso | Escalonamento automático sem servidor para Apache Spark V1 | Escalonamento automático V2 do Serverless para Apache Spark |
| Redução de nós | Síncrona | Assíncrono |
| Seleção de nós para redução de escala | Aleatório | Inteligente |
| Desativação otimizada do Spark e migração de embaralhamento | Não configurável | Configurável |
Propriedades de alocação dinâmica do Spark
A tabela a seguir lista as propriedades de alocação dinâmica do Spark que podem ser definidas ao enviar uma carga de trabalho em lote para controlar o escalonamento automático. Consulte como definir propriedades do Spark.
| Propriedade | Descrição | Padrão |
|---|---|---|
spark.dataproc.scaling.version |
A versão do escalonamento automático do Spark para o Serverless para Apache Spark. Especifique a versão 1 ou 2 (consulte Escalonamento automático do Serverless para Apache Spark V2). |
1 |
spark.dynamicAllocation.enabled |
Se vai usar a alocação dinâmica de recursos, que aumenta e diminui o
número de executores com base na carga de trabalho.
Definir o valor como false desativa o escalonamento automático
para a carga de trabalho. Padrão: true. |
true |
spark.dynamicAllocation.initialExecutors |
O número inicial de executores alocados para a carga de trabalho. Depois que a
carga de trabalho é iniciada, o escalonamento automático pode mudar o número de executores ativos.
O valor mínimo é 2, e o máximo é 2000. |
2 |
spark.dynamicAllocation.minExecutors |
O número mínimo de executores para reduzir a carga de trabalho.
O valor mínimo é 2. |
2 |
spark.dynamicAllocation.maxExecutors |
O número máximo de executores para escalonar a carga de trabalho.
O valor máximo é 2000. |
1000 |
spark.dynamicAllocation.executorAllocationRatio |
Personaliza o escalonamento vertical da carga de trabalho do Spark. Aceita um valor de 0 a 1. Um valor de 1.0 oferece capacidade máxima de escalonamento vertical e ajuda a alcançar o paralelismo máximo. Um valor de 0.5 define a capacidade de escalonamento vertical e o paralelismo na metade do valor máximo. |
0.3 |
spark.reducer.fetchMigratedShuffle.enabled |
Quando definido como true, permite buscar o local de saída do
embaralhamento no driver do Spark depois que uma busca falha em um executor que foi
desativado devido à alocação dinâmica do Spark. Isso reduz os erros ExecutorDeadException causados pela migração de blocos de embaralhamento de executores desativados para executores ativos e reduz as novas tentativas de estágio causadas por erros FetchFailedException. Consulte FetchFailedException causado por ExecutorDeadException.
Essa propriedade está disponível no Serverless para Apache Spark nas versões do tempo de execução do Spark
1.1.12 e posteriores e 2.0.20 e posteriores. |
false |
Métricas de alocação dinâmica do Spark
As cargas de trabalho em lote do Spark geram as seguintes métricas relacionadas à alocação dinâmica de recursos do Spark. Para mais informações sobre métricas do Spark, consulte Monitoramento e instrumentação.
| Métrica | Descrição |
|---|---|
maximum-needed |
O número máximo de executores necessários na carga atual para atender a todas as tarefas em execução e pendentes. |
running |
O número de executores em execução que estão executando tarefas. |
Problemas e soluções de alocação dinâmica do Spark
FetchFailedException causado por ExecutorDeadException
Causa: quando a alocação dinâmica do Spark reduz um executor, o arquivo de embaralhamento é migrado para executores ativos. No entanto, como a tarefa de redução do Spark em um executor busca a saída de embaralhamento do local definido pelo driver do Spark quando a tarefa de redução é iniciada, se um arquivo de embaralhamento for migrado, o redutor poderá continuar tentando buscar a saída de embaralhamento de um executor desativado, causando erros de
ExecutorDeadExceptioneFetchFailedException.Solução: ative a busca de novo do local de embaralhamento definindo
spark.reducer.fetchMigratedShuffle.enabledcomotrueao executar sua carga de trabalho em lote sem servidor para Apache Spark. Consulte Definir propriedades da carga de trabalho em lote do Spark. Quando essa propriedade está ativada, a tarefa do reducer busca novamente o local de saída do shuffle no driver depois que uma busca de um executor desativado falha.