Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Ce document fournit des informations sur l'autoscaling de Google Cloud Serverless pour Apache Spark.
Lorsque vous envoyez votre charge de travail Spark, Serverless pour Apache Spark peut effectuer un scaling dynamique des ressources de la charge de travail, telles que le nombre d'exécuteurs, de façon à l'exécuter efficacement. L'autoscaling de Serverless pour Apache Spark est le comportement par défaut. Il utilise l'allocation dynamique des ressources Spark pour déterminer si, comment et quand effectuer le scaling de votre charge de travail.
Autoscaling Serverless pour Apache Spark V2
La version 2 (V2) du scaling automatique Serverless pour Apache Spark ajoute des fonctionnalités et des améliorations à la version 1 (V1) par défaut pour vous aider à gérer les charges de travail Serverless pour Apache Spark, à améliorer les performances des charges de travail et à réduire les coûts :
Réduction asynchrone de la taille des nœuds : Autoscaling V2 remplace la réduction synchrone de la taille des nœuds de V1 par une réduction asynchrone. En utilisant le scaling à la baisse asynchrone, Serverless pour Apache Spark réduit les ressources de charge de travail sans attendre que tous les nœuds aient terminé la migration du shuffle. Cela signifie que les nœuds de longue traîne qui diminuent lentement ne bloqueront pas la mise à l'échelle.
Sélection intelligente des nœuds pour le scaling à la baisse : Autoscaling V2 remplace la sélection aléatoire des nœuds de V1 par un algorithme intelligent qui identifie les meilleurs nœuds à réduire en premier. Cet algorithme tient compte de facteurs tels que la taille des données de lecture aléatoire et le temps d'inactivité du nœud.
Comportement configurable de la migration du shuffle et de la mise hors service progressive de Spark : Autoscaling V2 vous permet d'utiliser des propriétés Spark standards pour configurer la mise hors service progressive de Spark et la migration du shuffle. Cette fonctionnalité peut vous aider à maintenir la compatibilité de la migration avec vos propriétés Spark personnalisées.
Fonctionnalités d'autoscaling Serverless pour Apache Spark
Fonctionnalité
Autoscaling sans serveur pour Apache Spark V1
Autoscaling V2 pour Apache Spark sans serveur
Réduction de la taille des nœuds
Synchrone
Asynchrone
Sélection de nœuds pour le scaling à la baisse
Aléatoire
Intelligent
Mise hors service concertée de Spark et migration du shuffle
Non configurable
Configurable
Propriétés d'allocation dynamique Spark
Le tableau suivant répertorie les propriétés d'allocation dynamique Spark que vous pouvez définir lorsque vous envoyez une charge de travail par lot pour contrôler l'autoscaling (consultez Définir les propriétés Spark).
Indique s'il faut utiliser l'allocation dynamique des ressources, qui augmente et diminue le nombre d'exécuteurs en fonction de la charge de travail.
Si vous définissez la valeur sur false, l'autoscaling est désactivé pour la charge de travail. Valeur par défaut : true.
true
spark.dynamicAllocation.initialExecutors
Nombre initial d'exécuteurs alloués à la charge de travail. Une fois la charge de travail démarrée, l'autoscaling peut modifier le nombre d'exécuteurs actifs.
La valeur minimale est 2 et la valeur maximale est 2000.
2
spark.dynamicAllocation.minExecutors
Nombre minimal d'exécuteurs pour réduire la charge de travail.
La valeur minimale est de 2.
2
spark.dynamicAllocation.maxExecutors
Nombre maximal d'exécuteurs jusqu'auquel la charge de travail peut être augmentée.
La valeur maximale est de 2000.
1000
spark.dynamicAllocation.executorAllocationRatio
Personnalise le scaling de la charge de travail Spark. Accepte une valeur comprise entre 0 et 1. Une valeur de 1.0 offre une capacité de scaling-up maximale et permet d'atteindre un parallélisme maximal. Une valeur de 0.5 définit la capacité de scaling et le parallélisme à la moitié de la valeur maximale.
0.3
spark.reducer.fetchMigratedShuffle.enabled
Lorsque la valeur est définie sur true, l'emplacement de sortie du shuffle peut être récupéré à partir du pilote Spark après l'échec d'une récupération à partir d'un exécuteur mis hors service en raison de l'allocation dynamique Spark. Cela réduit les erreurs ExecutorDeadException causées par la migration des blocs de lecture aléatoire des exécuteurs mis hors service vers les exécuteurs actifs, ainsi que les nouvelles tentatives d'étape causées par les erreurs FetchFailedException (voir FetchFailedException causée par ExecutorDeadException).
Cette propriété est disponible dans les versions du moteur d'exécution Spark1.1.12 et ultérieures, et 2.0.20 et ultérieures de Serverless pour Apache Spark.
false
Métriques d'allocation dynamique Spark
Les charges de travail par lot Spark génèrent les métriques suivantes liées à l'allocation dynamique des ressources Spark (pour en savoir plus sur les métriques Spark, consultez Surveillance et instrumentation).
Métrique
Description
maximum-needed
Nombre maximal d'exécuteurs nécessaires sous la charge actuelle pour satisfaire toutes les tâches en cours et en attente.
running
Nombre d'exécuteurs en cours d'exécution des tâches.
Problèmes et solutions liés à l'allocation dynamique Spark
FetchFailedException causée par ExecutorDeadException
Cause : Lorsque l'allocation dynamique Spark réduit un exécuteur, le fichier de shuffle est migré vers des exécuteurs actifs. Toutefois, étant donné que la tâche de réduction Spark sur un exécuteur récupère la sortie du shuffle à partir de l'emplacement défini par le pilote Spark au démarrage de la tâche de réduction, si un fichier de shuffle est migré, le réducteur peut continuer à tenter de récupérer la sortie du shuffle à partir d'un exécuteur mis hors service, ce qui entraîne des erreurs ExecutorDeadException et FetchFailedException.
Solution : Activez la récupération des emplacements de réorganisation en définissant spark.reducer.fetchMigratedShuffle.enabled sur true lorsque vous exécutez votre charge de travail par lot Serverless pour Apache Spark (consultez Définir les propriétés des charges de travail par lot Spark).
Lorsque cette propriété est activée, la tâche de réduction récupère à nouveau l'emplacement de sortie du shuffle à partir du pilote après l'échec d'une récupération à partir d'un exécuteur mis hors service.
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/09/09 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Difficile à comprendre","hardToUnderstand","thumb-down"],["Informations ou exemple de code incorrects","incorrectInformationOrSampleCode","thumb-down"],["Il n'y a pas l'information/les exemples dont j'ai besoin","missingTheInformationSamplesINeed","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 2025/09/09 (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."]]
