Utiliser Apache Spark dans Azure Machine Learning

Article
04/11/2024

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. Ses utilisateurs peuvent éviter d’avoir à créer un espace de travail Azure Synapse et un pool Synapse Spark.

Les utilisateurs peuvent définir des ressources, notamment le type d’instance et la version du runtime Apache Spark. Ces ressources permettent alors d’accéder à une capacité de calcul Spark serverless dans des notebooks Azure Machine Learning pour :

É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, les utilisateurs doivent prendre en compte les avantages et les 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 :

Il manque un metastore Hive persistant. Le calcul Spark serverless prend uniquement en charge Spark SQL en mémoire.
Aucune table ou base de données disponible.
Il manque l’intégration 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. L’approvisionnement de calcul Spark serverless automatisé, soutenu par Azure Synapse, provoque ce retard. Après l’approvisionnement du calcul Spark serverless et le démarrage d’une session Apache Spark, les exécutions de code suivantes (démarrage à chaud) ne subissent pas ce retard.

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 dans les 10 minutes suivantes, les ressources approvisionnées pour le calcul Spark serverless sont détruites.

Une fois la ressource de calcul Spark serverless détruite, la soumission du travail suivant nécessite un démarrage à froid. La visualisation suivante montre des scénarios de période d’inactivité de session et de retrait du 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 expirera si l’installation des packages Conda définis dans le fichier YAML prend plus de quinze minutes. Il est important de vérifier en premier lieu si un package nécessaire est déjà disponible dans l’image de base Azure Synapse. Pour ce faire, les utilisateurs doivent suivre le lien pour déterminer quels sont packages disponibles dans l’image de base pour la version d’Apache Spark utilisée :

Important

Azure Synapse Runtime pour Apache Spark : annonces

Runtime Azure Synapse pour Apache Spark 3.2 :
- Date d'annonce EOLA : 8 juillet 2023
- Date de fin de support : 8 juillet 2024. Après cette date, le runtime sera désactivé.
Pour bénéficier d’un support continu et de performances optimales, nous vous conseillons de migrer vers

Remarque

Pour un package Conda au niveau de la session :

Le Démarrage à froid nécessitera environ dix à quinze minutes.
Le Démarrage à chaud à l’aide du même package Conda nécessitera une minute environ.
Le Démarrage à chaud avec un autre package Conda nécessitera également environ dix à quinze minutes.
Si le package que vous installez est volumineux ou a besoin d’une longue durée d’installation, cela peut avoir un impact sur l’heure de démarrage de l’instance Spark.
La modification de la version de 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

Vous pouvez améliorer l’heure de démarrage à froid de la session Spark en définissant la variable de configuration spark.hadoop.aml.enable_cache sur true. Le démarrage à froid de la session avec les packages Conda au niveau 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é

Un pool Spark créé dans un espace de travail Azure Synapse devient disponible dans l’espace de travail Azure Machine Learning avec le pool Synapse Spark attaché. Cette option peut convenir aux utilisateurs qui souhaitent réutiliser un pool Synapse Spark existant.

L’attachement d’un pool Synapse Spark à un espace de travail Azure Machine Learning nécessite d’autres étapes avant que vous puissiez utiliser le pool dans Azure Machine Learning pour :

Un pool Synapse Spark attaché permet d’accéder aux fonctionnalités d’Azure Synapse natives. L’utilisateur est 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 des travaux Spark Azure Machine Learning, vous pouvez définir la taille du cluster Spark avec trois valeurs de paramètres :

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

Vous devez considérer un exécuteur Apache Spark Azure Machine Learning comme équivalent de nœuds Worker Azure Spark. Un exemple peut expliquer ces paramètres. Supposons que vous avez défini le nombre d’exécuteurs sur 6 (équivalent à six nœuds Worker), le nombre de cœurs exécuteurs sur 4 et une mémoire d’exécuteur de 28 Go. Votre travail Spark a ainsi accès à un cluster avec 24 cœurs en tout 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.

Notes

Pour garantir l’exécution réussie du travail Spark, attribuez les rôles Contributeur et Contributeur aux données d’objets blob de stockage (sur le compte de stockage Azure utilisé pour l’entrée et la sortie des données) à l’identité utilisée pour soumettre le travail Spark.
Si un pool Synapse Spark attaché pointe vers un pool Synapse Spark dans un espace de travail Azure Synapse, et que cet espace de travail est un réseau virtuel managé, configurez un point de terminaison privé managé vers un compte de stockage. Cette configuration permet de garantir l’accès aux données.