Escalonamento automático do Serverless para Apache Spark
Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
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 a 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 da carga 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 do 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
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 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
versões do tempo de execução do Spark1.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 ExecutorDeadException
e FetchFailedException.
Solução: ative a busca de novo local de embaralhamento definindo
spark.reducer.fetchMigratedShuffle.enabled como true ao 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.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[[["\u003cp\u003eDataproc Serverless for Spark uses dynamic resource allocation to automatically scale workload resources, such as the number of executors, for efficient processing.\u003c/p\u003e\n"],["\u003cp\u003eAutoscaling V2 is an improved version of the default V1 and offers asynchronous node downscaling, intelligent node selection for downscaling, and configurable Spark graceful decommissioning and shuffle migration behavior.\u003c/p\u003e\n"],["\u003cp\u003eThe \u003ccode\u003espark.dataproc.scaling.version\u003c/code\u003e property controls whether autoscaling V1 or V2 is active, and setting it to \u003ccode\u003e2\u003c/code\u003e enables V2's enhanced features.\u003c/p\u003e\n"],["\u003cp\u003eVarious Spark dynamic allocation properties, such as \u003ccode\u003espark.dynamicAllocation.minExecutors\u003c/code\u003e and \u003ccode\u003espark.dynamicAllocation.maxExecutors\u003c/code\u003e, can be configured to control autoscaling behavior when submitting a batch workload.\u003c/p\u003e\n"],["\u003cp\u003eSetting \u003ccode\u003espark.reducer.fetchMigratedShuffle.enabled\u003c/code\u003e to \u003ccode\u003etrue\u003c/code\u003e mitigates \u003ccode\u003eExecutorDeadException\u003c/code\u003e and \u003ccode\u003eFetchFailedException\u003c/code\u003e errors by allowing reducers to refetch shuffle output locations after an executor is decommissioned.\u003c/p\u003e\n"]]],[],null,["# Serverless for Apache Spark autoscaling\n\nThis document provides information about Google Cloud Serverless for Apache Spark autoscaling.\nWhen you submit your Spark workload, Serverless for Apache Spark\ncan dynamically scale workload resources, such as the number of executors,\nto run your workload efficiently. Serverless for Apache Spark autoscaling is the\ndefault behavior, and uses\n[Spark dynamic resource allocation](https://spark.apache.org/docs/latest/job-scheduling.html#dynamic-resource-allocation)\nto determine whether, how, and when to scale your workload.\n\nServerless for Apache Spark autoscaling V2\n------------------------------------------\n\nServerless for Apache Spark autoscaling version 2 (V2) adds features and improvements\nto default version 1 (V1) to help you manage Serverless for Apache Spark workloads, improve\nworkload performance, and save costs:\n\n- **Asynchronous node downscaling**: Autoscaling V2 replaces V1's synchronous downscaling with asynchronous downscaling. Using asynchronous downscaling, Serverless for Apache Spark downscales workload resources without waiting for all nodes to finish shuffle migration. This means that long-tail nodes that scale down slowly won't block upscaling.\n- **Intelligent scaling down node selection**: Autoscaling V2 replaces V1's random node selection with an intelligent algorithm that identifies the best nodes to scale down first. This algorithm considers factors such as the node's shuffle data size and idle time.\n- **Configurable Spark grace decommission and shuffle migration behavior**: Autoscaling V2 lets you use standard Spark properties to configure Spark graceful decommissioning and shuffle migration. This feature can help you maintain migration compatibility with your customized Spark properties.\n\n| **Note:** Set the `spark.dataproc.scaling.version=2` property to enable Serverless for Apache Spark autoscaling V2 when you [submit a Spark batch workload](/dataproc-serverless/docs/quickstarts/spark-batch#submit_a_spark_batch_workload).\n\n### Serverless for Apache Spark autoscaling features\n\nSpark dynamic allocation properties\n-----------------------------------\n\nThe following table lists\n[Spark Dynamic Allocation](https://spark.apache.org/docs/latest/configuration.html#dynamic-allocation)\nproperties that you can set when you submit a batch workload to control autoscaling (see\n[how to set Spark properties](/dataproc-serverless/docs/concepts/properties)).\n| **Note:** Also see [Spark properties](/dataproc-serverless/docs/concepts/properties), which describes additional properties that you can set when you submit a Serverless for Apache Spark Spark batch workload.\n\nSpark dynamic allocation metrics\n--------------------------------\n\nSpark batch workloads generate the following metrics related to Spark dynamic\nresource allocation (for additional information on Spark metrics, see\n[Monitoring and Instrumentation](https://spark.apache.org/docs/latest/monitoring.html)).\n| **Note:** See [Spark metrics](/dataproc-serverless/docs/concepts/metrics), which describes properties you can set to control the collection of Spark metrics.\n\nSpark dynamic allocation issues and solutions\n---------------------------------------------\n\n- **FetchFailedException caused by ExecutorDeadException**\n\n Cause: When Spark dynamic allocation scales down an executor, the shuffle file is migrated to\n live executors. However, since the Spark reducer task on an executor fetches shuffle\n output from the location set by the Spark driver when the reducer task started, if\n a shuffle file is migrated, the reducer can continue to attempt to\n fetch shuffle output from a decommissioned executor, causing `ExecutorDeadException`\n and `FetchFailedException` errors.\n\n Solution: Enable shuffle location refetching by setting\n the `spark.reducer.fetchMigratedShuffle.enabled` to `true` when you run your\n Serverless for Apache Spark batch workload (see\n [Set Spark batch workload properties](/dataproc-serverless/docs/concepts/properties#set_spark_batch_workload_properties)).\n When this property is enabled, the reducer task refetches the shuffle output\n location from the driver after a fetch from a decommissioned executor fails."]]
