Autoscaling de Serverless pour Apache Spark

Ce document fournit des informations sur Google Cloud l'autoscaling de 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 V2 de Serverless pour Apache Spark

L'autoscaling version 2 (V2) de 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 leurs performances et à réduire les coûts :

• Réduction asynchrone des nœuds : l'autoscaling V2 remplace la réduction synchrone de la V1 par une réduction asynchrone. Grâce à la réduction asynchrone, Serverless pour Apache Spark réduit les ressources de la charge de travail sans attendre que tous les nœuds aient terminé la migration du shuffle. Cela signifie que les nœuds à longue traîne qui se réduisent lentement ne bloquent pas le scaling.
• Sélection intelligente des nœuds pour la réduction : l'autoscaling V2 remplace la sélection aléatoire des nœuds de la V1 par un algorithme intelligent qui identifie les meilleurs nœuds à réduire en premier. Cet algorithme prend en compte des facteurs tels que la taille des données de shuffle du nœud et le temps d'inactivité.
• Mise hors service concertée et comportement de migration du shuffle Spark configurables: l'autoscaling V2 vous permet d'utiliser les propriétés Spark standards pour configurer la mise hors service concertée et la migration du shuffle Spark. Cette fonctionnalité peut aider à maintenir la compatibilité de la migration avec vos propriétés Spark personnalisées.

Remarque : Définissez la propriété spark.dataproc.scaling.version=2 pour activer l'autoscaling V2 de Serverless pour Apache Spark lorsque vous envoyez une charge de travail par lot Spark.

Fonctionnalités d'autoscaling de Serverless pour Apache Spark

Fonctionnalité	Autoscaling V1 de Serverless pour Apache Spark	Autoscaling V2 de Serverless pour Apache Spark
Réduction des nœuds	Synchrone	Asynchrone
Sélection des nœuds pour la réduction	Aléatoire	Intelligente
Mise hors service concertée et migration du shuffle Spark	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 (découvrez comment définir les propriétés Spark).

**Remarque** : Consultez également Propriétés Spark, qui décrit d'autres propriétés que vous pouvez définir lorsque vous envoyez une charge de travail par lot Spark Serverless pour Apache 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 V2 de Serverless pour Apache Spark).	1
spark.dynamicAllocation.enabled	Indique si l'allocation dynamique des ressources doit être utilisée, ce 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 2.	2
spark.dynamicAllocation.maxExecutors	Nombre maximal d'exécuteurs pour augmenter la charge de travail. La valeur maximale est 2000.	1000
spark.dynamicAllocation.executorAllocationRatio	Personnalise l'augmentation de la charge de travail Spark. Accepte une valeur comprise entre 0 et 1. La valeur 1.0 offre une capacité d'augmentation maximale et permet d'atteindre un parallélisme maximal. La valeur 0.5 définit la capacité d'augmentation et le parallélisme à la moitié de la valeur maximale.	0.3
spark.reducer.fetchMigratedShuffle.enabled	Lorsque la valeur est définie sur true, permet de récupérer l'emplacement de sortie du shuffle à 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 du bloc de shuffle des exécuteurs mis hors service vers les exécuteurs actifs, ainsi que les nouvelles tentatives d'étape causées par les erreurs FetchFailedException (consultez FetchFailedException causée par ExecutorDeadException). Cette propriété est disponible dans les versions d'exécution Spark Serverless pour Apache Spark Spark runtime versions 1.1.12 et ultérieures, ainsi que 2.0.20 et ultérieures.	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).

**Remarque** : Consultez Métriques Spark, qui décrit les propriétés que vous pouvez définir pour contrôler la collecte des métriques Spark.

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.

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 de l'emplacement du shuffle en définissant le 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 de la charge de travail par lot Spark). Lorsque cette propriété est activée, la tâche de réduction récupère 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.