Lire en anglais

Partager via

Réservation d’exécuteurs dans le cadre de l’allocation dynamique dans les pools Synapse Spark

  • Article

Les utilisateurs créent des pools Spark dans Azure Synapse Analytics et les dimensionnent en fonction de leurs besoins en matière de charge de travail d’analytique. Il est courant pour les équipes d’entreprise d’utiliser des pools Spark pour plusieurs processus d’ingénierie des données, et l’utilisation des pools peut varier en fonction des taux d’ingestion des données, du volume de données et d’autres facteurs. Un pool Spark peut être utilisé pour la transformation de données intensive en calcul et également pour effectuer des processus exploratoires de données. Dans ce cas, les utilisateurs peuvent activer l’option de mise à l’échelle automatique et spécifier un nombre minimal et maximal de nœuds et la plateforme gère la mise à l’échelle du nombre de nœuds actifs dans ces limites en fonction de la demande.

Aller plus loin en examinant les exigences de l’exécuteur au niveau de l’application, les utilisateurs ont du mal à régler les configurations de l’exécuteur, car elles sont très différentes selon les différentes étapes d’un processus d’exécution de travail Spark, qui dépendent également du volume de données traitées qui change de temps à autre. Les utilisateurs peuvent activer l’option Allocation dynamique des exécuteurs dans le cadre de la configuration du pool, ce qui permet l’allocation automatique des exécuteurs à l’application Spark en fonction des nœuds disponibles dans le pool Spark.

Lorsque l’option Allocation dynamique est activée, pour chaque application Spark envoyée, le système réserve des exécuteurs pendant l’étape d’envoi du travail en fonction des nœuds max spécifiés par l’utilisateur pour prendre en charge les scénarios de mise à l’échelle automatique réussis.

Notes

Cette approche conservatrice permet à la plateforme d’activer la mise à l’échelle de 3 à 10 nœuds sans manquer de capacité, offrant ainsi aux utilisateurs une plus grande fiabilité pour l’exécution des travaux.

Allocation dynamique dans les pools Synapse Spark

Que signifie la réservation d’exécuteurs ?

Dans les scénarios où l’option d’allocation dynamique est activée dans un pool Synapse Spark, la plateforme réserve le nombre d’exécuteurs en fonction de la limite maximale spécifiée par l’utilisateur pour toute application Spark envoyée. Un nouveau travail soumis par l’utilisateur n’est accepté que lorsqu’il y a des exécuteurs disponibles > au nombre maximal d’exécuteurs réservés.

Important

Toutefois, cette activité de réservation n’a pas d’impact sur la facturation où les utilisateurs sont facturés uniquement pour les cœurs utilisés et non pour le nombre de cœurs dans l’état réservé.

Fonctionnement de cette allocation dynamique lorsque plusieurs travaux sont envoyés sur un pool Spark

Examinons un exemple de scénario d’un seul utilisateur qui crée un pool Spark A avec la mise à l’échelle automatique activée avec un minimum de 5 à 50 nœuds maximum. Étant donné que l’utilisateur n’est pas sûr de la quantité de calcul nécessaire au travail Spark, il active l’allocation dynamique pour permettre aux exécuteurs de mettre à l’échelle.

  • L’utilisateur commence par soumettre l’application App1, qui commence par trois exécuteurs, et peut passer de 3 à 10 exécuteurs.
  • Le nombre maximal de nœuds alloués au pool Spark est de 50. Avec la soumission d’App1 entraînant la réservation de 10 exécuteurs, le nombre d’exécuteurs disponibles dans le pool Spark est réduit à 40.
  • L’utilisateur envoie une autre application Spark Application2 avec les mêmes configurations de calcul que celle d’App1, où l’application commence par 3, qui peut être mise à l’échelle jusqu’à 10 exécuteurs, ce qui permet de réserver 10 exécuteurs supplémentaires à partir du nombre total d’exécuteurs disponibles dans le pool Spark.
  • Le nombre total d’exécuteurs disponibles dans le pool Spark a été réduit à 30.
  • L’utilisateur envoie une application App3, App4 et App5 avec le même que les autres applications, pour le sixième travail serait mis en file d’attente, car, dans le cadre de l’acceptation d’App3, le nombre d’exécuteurs disponibles est réduit à 20, et de la même façon réduit à 10, puis à 0 lorsque App5 est accepté dans le cadre de la réservation de 10 exécuteurs du jeu d’exécuteurs disponible dans le pool.
  • Étant donné qu’il n’y a pas de cœurs disponibles, App6 sera dans la file d’attente jusqu’à ce que ces autres applications terminent l’exécution et sera accepté une fois que le nombre d’exécuteurs disponibles dans le pool passera de 0 à 10.

Réservation au niveau du travail des exécuteurs dans le pool Spark avec allocation dynamique

Notes

  • Même si la réservation des exécuteurs est effectuée, tous les exécuteurs ne sont pas utilisés, mais sont réservés pour prendre en charge les scénarios de mise à l’échelle automatique pour ces applications.
  • Si toutes les applications App1, App2, App3, App4 et App5 ont pu s’exécuter avec une capacité de nœud minimale, les exécuteurs consommés pour cette exécution sont de 15 exécuteurs au total, mais le reste des 35 exécuteurs ont été ajoutés dans le cadre de la mise à l’échelle de réserve de 3 exécuteurs à 10 exécuteurs dans tous les cas lors de l’exécution de ces applications.
  • Même avec les 35 exécuteurs réservés, l’utilisateur est facturé uniquement pour les 15 exécuteurs utilisés dans ce cas et non pour les 35 exécuteurs dans l’état réservé.
  • Lorsque l’allocation dynamique est désactivée : dans un scénario où l’utilisateur a désactivé l’allocation dynamique, la réservation des exécuteurs est basée sur le nombre minimal et maximal d’exécuteurs spécifiés par l’utilisateur.
  • Si l’utilisateur dans l’exemple ci-dessus a spécifié le nombre d’exécuteurs à 5, les 5 exécuteurs sont réservés pour chaque application envoyée, et l’utilisateur peut envoyer App6 et elle ne serait pas mise en file d’attente.

Scénario où des travaux simultanés sont soumis à des pools Spark dans un espace de travail Synapse

Les utilisateurs peuvent créer plusieurs pools Spark dans un espace de travail Synapse Analytics et les dimensionner en fonction de leurs besoins en matière de charge de travail d’analytique. Pour ces pools Spark créés, si les utilisateurs ont activé l’allocation dynamique, le nombre total de cœurs disponibles pour l’espace de travail donné à tout moment sera

Nombre total de cœurs disponibles pour l’espace de travail = nombre total de cœurs de tous les pools Spark - Cœurs réservés ou utilisés pour les travaux actifs exécutés dans les pools Spark

Les utilisateurs recevront une erreur de dépassement de la capacité de l’espace de travail pour les travaux envoyés lorsque le nombre total de cœurs disponibles pour l’espace de travail est de 0.

Allocation et réservation dynamiques de cœurs dans un scénario multi-utilisateur

Dans les scénarios où plusieurs utilisateurs essaient d’exécuter plusieurs travaux Spark dans un espace de travail Synapse donné, si User1 envoie des travaux à un pool Spark, qui est activé avec l’allocation dynamique, là-bas en utilisant tous les cœurs disponibles dans pool. Si User2 envoie des travaux et qu’il n’y a pas de cœurs disponibles pour le pool Spark, car certains d’entre eux sont activement utilisés dans l’exécution des travaux envoyés par User1 et que certains sont réservés pour la prise en charge de l’exécution, User2 rencontrerait une erreur de dépassement de capacité de l’espace de travail.

Conseil

Les utilisateurs peuvent augmenter le nombre de cœurs, en augmentant le nombre total de cœurs disponibles pour éviter les erreurs de dépassement de la capacité de l’espace de travail.

Étapes suivantes