Utiliser Apache Spark dans Azure Machine Learning

L’intégration d’Azure Machine Learning avec Azure Synapse Analytics offre un accès facile aux ressources du calcul distribué via l’infrastructure Apache Spark. Cette intégration offre les expériences de calcul Apache Spark suivantes :

Calcul Spark serverless
Pool Spark Synapse attaché

Calcul Spark serverless

Avec l’infrastructure Apache Spark, le calcul Spark serverless Azure Machine Learning est le moyen le plus simple d’accomplir des tâches de calcul distribué dans l’environnement Azure Machine Learning. Azure Machine Learning propose un cluster de calcul Apache Spark entièrement managé, serverless et à la demande. Vous n’avez pas besoin de créer à la fois un espace de travail Azure Synapse et un pool Synapse Spark.

Vous pouvez définir des ressources, notamment le type d’instance et la version du runtime Apache Spark. Utilisez ces ressources pour accéder à la puissance de calcul Spark sans serveur dans les notebooks Azure Machine Learning.

Éléments à prendre en considération

Le calcul Spark serverless fonctionne bien pour la plupart des scénarios utilisateur qui nécessitent un accès rapide aux ressources de calcul distribuées à l’aide d’Apache Spark. Toutefois, pour prendre une décision éclairée, tenez compte des avantages et des inconvénients de cette approche.

Avantages :

Aucune dépendance vis-à-vis de la création d’autres ressources Azure pour Apache Spark (l’infrastructure Azure Synapse opère en coulisses).
Aucune autorisation d’abonnement requise pour créer des ressources liées à Azure Synapse.
Aucun quota de pool SQL n’est nécessaire.

Inconvénients :

Aucun metastore Hive persistant. Le calcul Spark serverless prend uniquement en charge Spark SQL en mémoire.
Aucune table ou base de données disponible.
Aucune intégration d’Azure Purview.
Aucun service lié disponible.
Moins de sources de données et de connecteurs.
Aucune configuration au niveau du pool.
Aucune gestion de bibliothèque au niveau du pool.
Prise en charge partielle uniquement pour mssparkutils.

Configuration réseau

Pour utiliser l’isolation réseau avec Azure Machine Learning et le calcul Spark serverless, utilisez un réseau virtuel managé.

Périodes d’inactivité et mécanisme de destruction

Lors de son premier lancement, une ressource de calcul Spark serverless (démarrage à froid) peut avoir besoin de trois à cinq minutes pour démarrer la session Spark proprement dite. Ce délai se produit parce que la ressource de calcul Spark serverless automatisée, sauvegardée par Azure Synapse, a besoin de temps pour provisionner. Une fois le calcul Spark serverless approvisionné et qu’une session Apache Spark démarre, les exécutions de code suivantes (démarrage chaud) ne connaissent pas ce délai.

La configuration de session Spark offre une option qui définit un délai d’expiration de session (en minutes). La session Spark se termine après une période d’inactivité qui dépasse le délai d’expiration défini par l’utilisateur. Si une autre session Spark ne démarre pas au cours des 10 minutes suivantes, le système supprime les ressources approvisionnées pour le calcul Spark serverless.

Une fois que le système a détruit la ressource de calcul Spark serverless, l’envoi du travail suivant nécessite un démarrage à froid. La visualisation suivante montre certaines périodes d’inactivité de session et des scénarios de démontage de cluster.

Packages Conda au niveau de la session

Un fichier YAML de dépendance Conda permet de définir de nombreux packages Conda au niveau de la session dans la configuration d’une session. La session expire si l’installation des packages Conda définis dans le fichier YAML prend plus de 15 minutes. Vérifiez si un package requis est déjà disponible dans l’image de base Azure Synapse. Pour ce faire, consultez ces ressources pour déterminer les packages disponibles dans l’image de base pour la version Apache Spark en cours d’utilisation :

Remarque

Pour un package Conda au niveau de la session :

Le démarrage froid a besoin d’environ 10 à 15 minutes.
Le démarrage chaud, à l’aide du même package Conda, a besoin d’environ une minute.
Le démarrage chaud, avec un autre package Conda, a besoin d’environ 10 à 15 minutes.
Si vous installez un package volumineux ou un package qui a besoin d’une longue durée d’installation, cela peut avoir un impact sur le temps de démarrage de l’instance Spark.
La modification de la version PySpark, Python, Scala/Java, .NET ou Spark n’est pas prise en charge.
Les images Docker ne sont pas prises en charge.

Amélioration de l’heure de démarrage à froid de la session lors de l’utilisation des packages Conda au niveau de la session

Définissez la spark.hadoop.aml.enable_cache variable de configuration pour true améliorer l’heure de démarrage à froid de la session Spark. Avec les packages Conda au niveau de la session, le démarrage à froid de la session prend généralement 10 à 15 minutes lorsque la session démarre pour la première fois. Toutefois, les démarrages à froid de la session suivants prennent généralement trois à cinq minutes. Définissez une variable de configuration dans l’interface utilisateur Configurer la session, sous Paramètres de configuration.

Pool Spark Synapse attaché

Lorsque vous créez un pool Spark dans un espace de travail Azure Synapse, vous pouvez y accéder dans l’espace de travail Azure Machine Learning avec le pool Synapse Spark attaché. Cette option est adaptée aux utilisateurs qui souhaitent réutiliser un pool Synapse Spark existant.

Pour attacher un pool Synapse Spark à un espace de travail Azure Machine Learning, vous devez effectuer d’autres étapes avant de pouvoir utiliser le pool dans Azure Machine Learning pour :

Un pool Synapse Spark attaché permet d’accéder aux fonctionnalités d’Azure Synapse natives. Vous êtes responsable de l’approvisionnement, de l’attachement, de la configuration et de la gestion du pool Synapse Spark.

La configuration de session Spark pour un pool Synapse Spark attaché offre également une option permettant de définir un délai d’expiration de session (en minutes). Le comportement du délai d’expiration de la session ressemble à la description de la section précédente, sauf que les ressources associées ne sont jamais détruites après le délai d’expiration de la session.

Définition de la taille du cluster Spark

Dans les travaux Spark Azure Machine Learning, vous pouvez définir la taille du cluster Spark avec trois valeurs de paramètre :

Nombre d’exécuteurs
Cœurs de l’exécuteur
Mémoire de l’exécuteur

Considérez un exécuteur Apache Spark Azure Machine Learning comme équivalent aux nœuds de travail Azure Spark. Un exemple peut expliquer ces paramètres. Si vous définissez le nombre d’exécuteurs comme 6 (équivalent à six nœuds Worker), le nombre de cœurs d’exécuteur en tant que 4 et la mémoire de l’exécuteur comme 28 Go, votre travail Spark a accès à un cluster avec 24 cœurs au total et 168 Go de mémoire.

Garantir l’accès aux ressources pour les travaux Spark

Les travaux Spark peuvent utiliser la transmission directe d’identité utilisateur ou une identité managée pour l’accès aux données et à d’autres ressources. Ce tableau récapitule les mécanismes utilisés par les travaux Spark pour accéder aux ressources.

Pool Spark	Identités prises en charge	Identité par défaut
Calcul Spark serverless	Identité utilisateur, identité managée affectée par l’utilisateur attachée à l’espace de travail	Identité de l’utilisateur
Pool Spark Synapse attaché	Identité utilisateur, identité managée affectée par l’utilisateur attachée au pool Synapse Spark attaché, identité managée affectée par le système du pool Synapse Spark attaché	Identité managée affectée par le système du pool Spark Synapse attaché

Cet article décrit l’accès aux ressources pour les travaux Spark. Dans une session notebook, le calcul Spark serverless et le pool Synapse Spark attaché utilisent le passthrough d’identité utilisateur pour l’accès aux données pendant le data wrangling interactif.