Ajuste de escala automático de Serverless para Apache Spark
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En este documento, se proporciona información sobre el ajuste de escala automático de Google Cloud Serverless para Apache Spark.
Cuando envías tu carga de trabajo de Spark, Serverless para Apache Spark puede escalar de forma dinámica los recursos de la carga de trabajo, como la cantidad de ejecutores, para ejecutar tu carga de trabajo de manera eficiente. El ajuste de escala automático de Serverless for Apache Spark es el comportamiento predeterminado y usa la asignación dinámica de recursos de Spark para determinar si, cómo y cuándo escalar tu carga de trabajo.
Ajuste de escala automático de Serverless para Apache Spark, versión 2
La versión 2 (V2) del escalamiento automático de Serverless for Apache Spark agrega funciones y mejoras a la versión 1 (V1) predeterminada para ayudarte a administrar las cargas de trabajo de Serverless for Apache Spark, mejorar el rendimiento de las cargas de trabajo y ahorrar costos:
Reducción de escala asíncrona de nodos: La versión 2 del ajuste de escala automático reemplaza la reducción de escala síncrona de la versión 1 por la reducción de escala asíncrona. Con el ajuste de escala asíncrono, Serverless for Apache Spark reduce los recursos de la carga de trabajo sin esperar a que todos los nodos finalicen la migración de la transferencia aleatoria. Esto significa que los nodos de cola larga que se reducen lentamente no bloquearán el aumento de escala.
Selección inteligente de nodos para reducir la escala: El ajuste de escala automático V2 reemplaza la selección aleatoria de nodos de la versión V1 por un algoritmo inteligente que identifica los mejores nodos para reducir la escala primero. Este algoritmo considera factores como el tamaño de los datos aleatorios y el tiempo de inactividad del nodo.
Comportamiento configurable de baja gradual y migración de shuffle de Spark: La versión 2 del ajuste de escala automático te permite usar propiedades estándar de Spark para configurar la baja gradual y la migración de shuffle de Spark. Esta función puede ayudarte a mantener la compatibilidad de la migración con tus propiedades de Spark personalizadas.
Funciones de ajuste de escala automático de Serverless para Apache Spark
Función
Ajuste de escala automático de Serverless para Apache Spark, versión 1
Ajuste de escala automático de Serverless para Apache Spark, versión 2
Reducción de la escala del nodo
Síncrona
Asíncrono
Selección de nodos para la reducción de escala
Aleatorio
Inteligente
Retiro de servicio ordenado de Spark y migración de Shuffle
Indica si se debe usar la asignación dinámica de recursos, que aumenta o disminuye la cantidad de ejecutores según la carga de trabajo.
Si se establece el valor en false, se inhabilita el ajuste de escala automático para la carga de trabajo. Predeterminado: true.
true
spark.dynamicAllocation.initialExecutors
Es la cantidad inicial de ejecutores asignados a la carga de trabajo. Después de que se inicia la carga de trabajo, el ajuste de escala automático puede cambiar la cantidad de ejecutores activos.
El valor mínimo es 2 y el valor máximo es 2000.
2
spark.dynamicAllocation.minExecutors
Es la cantidad mínima de ejecutores a la que se puede reducir la carga de trabajo.
El valor mínimo es 2.
2
spark.dynamicAllocation.maxExecutors
Es la cantidad máxima de ejecutores a la que se puede escalar la carga de trabajo.
El valor máximo es 2000.
1000
spark.dynamicAllocation.executorAllocationRatio
Personaliza el aumento de la escala de la carga de trabajo de Spark. Acepta un valor de 0 a 1. Un valor de 1.0 proporciona la máxima capacidad de aumento y ayuda a lograr el máximo paralelismo. Un valor de 0.5 establece la capacidad de ampliación y el paralelismo en la mitad del valor máximo.
0.3
spark.reducer.fetchMigratedShuffle.enabled
Cuando se configura como true, permite recuperar la ubicación de salida de la reorganización desde el controlador de Spark después de que falla una recuperación desde un ejecutor que se dio de baja debido a la asignación dinámica de Spark. Esto reduce los errores de ExecutorDeadException causados por la migración de bloques de aleatorización de ejecutores retirados a ejecutores activos, y reduce los reintentos de etapas causados por errores de FetchFailedException (consulta FetchFailedException causada por ExecutorDeadException).
Esta propiedad está disponible en las versiones de tiempo de ejecución de Spark1.1.12 y posteriores, y 2.0.20 y posteriores de Serverless para Apache Spark.
false
Métricas de asignación dinámica de Spark
Las cargas de trabajo por lotes de Spark generan las siguientes métricas relacionadas con la asignación dinámica de recursos de Spark (para obtener información adicional sobre las métricas de Spark, consulta Supervisión e instrumentación).
Métrica
Descripción
maximum-needed
Es la cantidad máxima de ejecutores necesarios con la carga actual para satisfacer todas las tareas pendientes y en ejecución.
running
Es la cantidad de ejecutores en ejecución que ejecutan tareas.
Problemas y soluciones de la asignación dinámica de Spark
FetchFailedException causada por ExecutorDeadException
Causa: Cuando la asignación dinámica de Spark reduce la cantidad de ejecutores, el archivo de intercambio se migra a los ejecutores activos. Sin embargo, dado que la tarea de reducción de Spark en un ejecutor recupera la salida de la reorganización de la ubicación establecida por el controlador de Spark cuando se inició la tarea de reducción, si se migra un archivo de reorganización, el reductor puede seguir intentando recuperar la salida de la reorganización de un ejecutor retirado, lo que provoca errores de ExecutorDeadException y FetchFailedException.
Solución: Habilita la recuperación de la ubicación de la reorganización estableciendo spark.reducer.fetchMigratedShuffle.enabled en true cuando ejecutes tu carga de trabajo por lotes de Serverless para Apache Spark (consulta Cómo establecer propiedades de la carga de trabajo por lotes de Spark).
Cuando esta propiedad está habilitada, la tarea del reductor vuelve a recuperar la ubicación de salida de la reorganización del controlador después de que falla una recuperación de un ejecutor retirado.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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."]]
