Este documento fornece informações sobre o Google Cloud escalonamento automático do Serverless para Apache Spark. Ao enviar 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 do Serverless para Apache Spark V2
A versão 2 (V2) do escalonamento automático do Serverless para Apache Spark adiciona recursos e melhorias à versão 1 (V1) padrão para ajudar você a gerenciar cargas de trabalho do Serverless para Apache Spark, melhorar o desempenho da carga de trabalho e economizar custos:
- Redução de escala assíncrona de nós: o escalonamento automático V2 substitui a redução de escala síncrona da V1 por uma redução de escala assíncrona. Usando a redução de escala assíncrona, 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 são reduzidos lentamente não bloqueiam o aumento de escala.
- Seleção inteligente de nós de redução de escala: o escalonamento automático V2 substitui a seleção aleatória de nós da V1's por um algoritmo inteligente que identifica os melhores nós para reduzir a escala primeiro. Esse algoritmo considera fatores como o tamanho dos dados de embaralhamento do nó e o tempo de inatividade.
- Desativação otimizada configurável do Spark e comportamento de migração de embaralhamento: o escalonamento automático V2 permite usar propriedades padrão do Spark para configurar a desativação otimizada do Spark e a migração de embaralhamento. Esse recurso pode ajudar você a manter a compatibilidade da migração com as propriedades personalizadas do Spark.
Recursos de escalonamento automático do Serverless para Apache Spark
| Recurso | Escalonamento automático do Serverless para Apache Spark V1 | Escalonamento automático do Serverless para Apache Spark V2 |
| Redução de escala de nós | Síncrona | Assíncrona |
| Seleção de nós para redução de escala | Aleatória | 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 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 deve 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 escala da carga de trabalho.
O valor mínimo é 2. |
2 |
spark.dynamicAllocation.maxExecutors |
O número máximo de executores para aumentar a escala da carga de trabalho.
O valor máximo é 2000. |
1000 |
spark.dynamicAllocation.executorAllocationRatio |
Personaliza o aumento de escala da carga de trabalho do Spark. Aceita um valor de
0 a 1. Um valor de 1.0
oferece capacidade máxima de aumento de escala e ajuda a alcançar o
paralelismo máximo. Um valor de 0.5 define a capacidade de aumento de escala e
paralelismo na metade do valor máximo. |
0.3 |
spark.reducer.fetchMigratedShuffle.enabled |
Quando definido como true, permite buscar o local de saída de embaralhamento do driver do Spark depois que uma busca falha em um executor desativado devido à alocação dinâmica do Spark. Isso reduz
ExecutorDeadException erros causados pela migração de blocos de embaralhamento
de executores desativados para executores ativos e reduz as novas tentativas de estágio
causadas por FetchFailedException
erros (consulte
FetchFailedException causada por
ExecutorDeadException).
Essa propriedade está disponível no Serverless para Apache Spark
versões
do ambiente de execução do Spark
1.1.12 e mais recentes e 2.0.20 e mais recentes. |
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. |
Problemas e soluções de alocação dinâmica do Spark
FetchFailedException causada 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
ExecutorDeadExceptioneFetchFailedExceptionerros.Solução: ative a busca de novo local de embaralhamento definindo o
spark.reducer.fetchMigratedShuffle.enabledcomotrueao executar a carga de trabalho em lote do Serverless para Apache Spark (consulte Definir propriedades de carga de trabalho em lote do Spark). Quando essa propriedade está ativada, a tarefa de redução busca novamente o local de saída de embaralhamento do driver depois que uma busca de um executor desativado falha.