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 Serverless 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).
| Propriété | Description | Par défaut |
|---|---|---|
spark.dataproc.scaling.version |
Version d'autoscaling Spark de Serverless pour Apache Spark. Spécifiez la version 1 ou 2 (consultez Autoscaling Serverless pour Apache Spark V2). |
1 |
spark.dynamicAllocation.enabled |
Indique s'il faut utiliser l'allocation dynamique des ressources, qui augmente ou 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 mise à l'échelle.
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'étapes causées par les erreurs FetchFailedException (voir FetchFailedException causée par ExecutorDeadException).
Cette propriété est disponible dans les versions du runtime Spark
1.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
ExecutorDeadExceptionetFetchFailedException.Solution : Activez la récupération des emplacements de réorganisation en définissant
spark.reducer.fetchMigratedShuffle.enabledsurtruelorsque 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.