Partager via

Apache Spark dans Azure Synapse Analytics - Concepts clés

  • Article

Apache Spark est un framework de traitement parallèle qui prend en charge le traitement en mémoire pour améliorer les performances des applications d’analytique du Big Data. Apache Spark dans Azure Synapse Analytics est l’une des implémentations par Microsoft d’Apache Spark dans le cloud.

Azure Synapse vous permet de créer et de configurer facilement des fonctionnalités Spark dans Azure. Azure Synapse fournit une implémentation différente de ces fonctionnalités Spark qui sont documentées ici.

Spark pools

Un pool Apache Spark serverless est créé dans le portail Azure. Il s’agit de la définition d’un pool Spark qui, quand il est instancié, est utilisé pour créer une instance Spark qui traite des données. Quand un pool Spark est créé, il existe uniquement en tant que métadonnées, et aucune ressource n’est consommée, exécutée ou facturée. Un pool Spark possède une série de propriétés qui contrôlent les caractéristiques d’une instance Spark. Ces caractéristiques incluent entre autres le nom, la taille, le comportement de mise à l’échelle et la durée de vie.

Comme aucun coût en euro ou en ressource n’est associé à la création des pools Spark, vous pouvez en créer autant que vous voulez avec autant de configurations différentes que vous le souhaitez. Vous pouvez aussi appliquer des autorisations aux pools Spark, ce qui permet aux utilisateurs d’avoir uniquement accès à certains d’entre eux.

Une bonne pratique consiste à créer de petits pools Spark qui peuvent être utilisés pour le développement et le débogage, puis de plus grands pour l’exécution des charges de travail de production.

Pour découvrir comment créer un pool Spark et afficher toutes ses propriétés, consultez Bien démarrer avec les pools Spark dans Azure Synapse Analytics.

Instances Spark

Des instances Spark sont créées quand vous vous connectez à un pool Spark, créez une session et exécutez un travail. Étant donné que plusieurs utilisateurs peuvent avoir accès à un même pool Spark, une nouvelle instance Spark est créée pour chaque utilisateur qui se connecte.

Lorsque vous soumettez un deuxième travail, s’il y a la capacité dans le pool, l’instance Spark existante dispose également de la capacité. Ensuite, l’instance existante traite la tâche. Sinon, si la capacité est disponible au niveau du pool, une instance Spark est créée.

La facturation des instances s’enclenche au démarrage de la ou des machines virtuelles Azure. La facturation des instances de pool Spark prend fin lorsque les instances de pool terminent. Si vous voulez en savoir plus sur le démarrage et la désallocation des machines virtuelles Azure, consultez États et statuts de facturation des machines virtuelles Azure.

Exemples

Exemple 1

  • Vous créez un pool Spark appelé SP1. Il a une taille de cluster fixe de 20 nœuds moyens
  • Vous soumettez un travail de notebook, J1, qui utilise 10 nœuds. Une instance Spark, SI1, est créée pour traiter le travail
  • Vous soumettez à présent un autre travail, J2, qui utilise 10 nœuds. Comme il y a encore une capacité dans le pool, l’instance J2 est traitée par SI1
  • Si J2 avait demandé 11 nœuds, la capacité aurait été insuffisante dans SP1 ou SI1. Dans ce cas, si J2 provient d’un notebook, la tâche sera rejetée, et si J2 provient d’un programme de traitement par lots, il est mis en file d’attente.
  • La facturation commence dès la soumission du travail de notebook J1.
    • Le pool Spark est instancié avec 20 nœuds moyens, avec chacun 8 vCores, et nécessite généralement environ 3 minutes pour démarrer. 20 x 8 = 160 vCores.
    • En fonction de l’heure de démarrage exacte du pool Spark, du délai d’inactivité et du runtime des deux travaux de notebook, le pool est susceptible de s’exécuter pendant 18 à 20 minutes (temps d’instanciation du pool Spark + runtime du travail du notebook + délai d’inactivité).
    • En supposant un runtime de 20 minutes, 160 x 0,3 heures = 48 heures de vCore.
    • Remarque : les heures de vCore sont facturées à la minute et la tarification de vCore varie selon la région Azure. Pour plus d'informations, consultez Tarification d'Azure Synapse

Exemple 2

  • Vous créez un appel de pool Spark SP2. Sa mise à l’échelle automatique est activée avec minimum 10 et maximum 20 nœuds moyens
  • Vous soumettez un travail de notebook, J1, qui utilise 10 nœuds, et une instance Spark SI1 est créée pour traiter le travail
  • Vous soumettez maintenant un autre travail, J2, qui utilise 10 nœuds. Comme il y a encore une capacité dans le pool, l’instance effectue une mise à l’échelle automatique à 20 nœuds et traite J2.
  • La facturation commence dès la soumission du travail de notebook J1.
    • Le pool Spark est instancié avec 10 nœuds moyens, avec chacun 8 vCores, et nécessite généralement environ 3 minutes pour démarrer. 10 x 8, 80 vCores.
    • Lors de la soumission de J2, le pool effectue une mise à l’échelle automatique en ajoutant 10 autres nœuds moyens, et sa mise à l’échelle automatique nécessite généralement 4 minutes. Ajout de 10 x 8, 80 vCores pour un total de 160 vCores.
    • En fonction de l’heure de démarrage du pool Spark (exécution du premier travail de notebook J1), du temps de montée en puissance du pool, de l’exécution du deuxième notebook et enfin du délai d’inactivité, l’exécution du pool peut prendre entre 22 et 24 minutes (temps d’instanciation du pool Spark + runtime du travail de notebook J1 à 80 vCores) + (temps de mise à l’échelle automatique du pool Spark + runtime du travail de notebook J2 + délai d’inactivité à 160 vCores).
    • 80 vCores pendant 4 minutes + 160 vCores pendant 20 minutes = 58,67 heures de vCore.
    • Remarque : les heures de vCore sont facturées à la minute et la tarification de vCore varie selon la région Azure. Pour plus d'informations, consultez Tarification d'Azure Synapse

Exemple 3

  • Vous créez un pool Spark appelé SP1 ; Il a une taille de cluster fixe de 20 nœuds.
  • Vous soumettez un travail de notebook, J1, qui utilise 10 nœuds. Une instance Spark, SI1, est créée pour traiter le travail.
  • Un autre utilisateur, U2, soumet un travail, J3, qui utilise 10 nœuds. Une nouvelle instance Spark, SI2, est créée pour traiter le travail.
  • Vous soumettez à présent un autre travail, J2, qui utilise 10 nœuds, car il y a encore de la capacité dans le pool, et l’instance J2 est traitée par SI1.
  • La facturation commence dès la soumission du travail de notebook J1.
    • Le pool Spark SI1 est instancié avec 20 nœuds moyens, avec chacun 8 vCores, et nécessite généralement environ 3 minutes pour démarrer. 20 x 8, 160 vCores.
    • En fonction de l’heure de démarrage exacte du pool Spark, le délai d’inactivité et le runtime du premier et deuxième travail de notebook, le pool SI1 est susceptible de s’exécuter pendant 18 à 20 minutes (temps d’instanciation du pool Spark + runtime du travail du notebook + délai d’inactivité).
    • Un autre pool Spark SI2 est instancié avec 20 nœuds moyens, avec chacun 8 vCores, et nécessite généralement environ 3 minutes pour démarrer. 20 x 8, 160 vCores
    • En fonction de l’heure de démarrage exacte du pool Spark, le délai d’inactivité et le runtime du premier travail de notebook, le pool SI2 est susceptible de s’exécuter pendant 18 à 20 minutes (temps d’instanciation du pool Spark + runtime du travail du notebook + délai d’inactivité).
    • En supposant que les deux pools s’exécutent pendant 20 minutes chacun, 160 x 0,3 x 2 = 96 heures de vCore.
    • Remarque : les heures de vCore sont facturées à la minute et la tarification de vCore varie selon la région Azure. Pour plus d'informations, consultez Tarification d'Azure Synapse

Quotas et contraintes de ressources dans Apache Spark pour Azure Synapse

Niveau Espace de travail

Chaque espace de travail Azure Synapse est fourni avec un quota par défaut de vCores qui peuvent être utilisés pour Spark. Le quota est divisé entre le quota « utilisateur » et le quota « flux de données » : aucun modèle d’utilisation n’utilise donc tous les vCores dans l’espace de travail. Le quota est différent selon le type de votre abonnement, mais il est symétrique entre « utilisateur » et « flux de données ». Cependant, si vous demandez plus de vCores que ceux qui restent dans l’espace de travail, vous obtenez l’erreur suivante :

Failed to start session: [User] MAXIMUM_WORKSPACE_CAPACITY_EXCEEDED
Your Spark job requested 480 vCores.
However, the workspace only has xxx vCores available out of quota of yyy vCores.
Try reducing the numbers of vCores requested or increasing your vCore quota. Click here for more information - https://go.microsoft.com/fwlink/?linkid=213499

Le lien présent dans le message pointe vers cet article.

L’article suivant décrit comment demander une augmentation du quota de vCores de l’espace de travail.

  • Sélectionnez « Azure Synapse Analytics » comme type de service.
  • Dans la fenêtre Détails du quota, sélectionnez Apache Spark (vCore) par espace de travail.

Demander une augmentation de capacité via le portail Azure

Niveau Pool Spark

Quand vous définissez un pool Spark, vous définissez en fait un quota par utilisateur pour ce pool : si vous exécutez plusieurs notebooks ou plusieurs travaux, ou une combinaison des deux, il est possible que le quota du pool soit épuisé. Dans ce cas, un message d’erreur est généré

Failed to start session: Your Spark job requested xx vCores.
However, the pool is consuming yy vCores out of available zz vCores.Try ending the running job(s) in the pool, reducing the numbers of vCores requested, increasing the pool maximum size or using another pool

Pour résoudre ce problème, vous devrez réduire l’utilisation des ressources du pool avant de soumettre une nouvelle demande de ressource en exécutant un notebook ou un travail.

Étapes suivantes