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. 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 :
- Développement de code Spark interactif
- Exécution de pipelines Machine Learning avec un composant Spark
- Soumissions de travaux par lots Spark
É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 la ressource 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 expire si l’installation des packages Conda définis dans le fichier YAML prend plus de 15 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 consulter ces ressources 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 Apache Spark 3.4.
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 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 de PySpark, Python, Scala/Java, .NET et 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 définir la variable de configuration spark.hadoop.aml.enable_cache
sur true
, pour améliorer le temps de démarrage à froid de la session Spark. Avec les packages Conda au niveau de la session, le démarrage à froid de 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 :
- Développement de code Spark interactif
- Soumission de travaux par lots Spark
- Exécution de pipelines Machine Learning avec un composant Spark
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.
Remarque
- Pour garantir la réussite de l’exécution 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.
Étapes suivantes
- Attachement et gestion d’un pool Spark Synapse dans Azure Machine Learning
- Data wrangling interactif avec Apache Spark dans Azure Machine Learning
- Soumettre des travaux Spark dans Azure Machine Learning
- Exemples de code pour des travaux Spark avec l’interface CLI Azure Machine Learning
- Exemples de code pour des travaux Spark avec le SDK Python Azure Machine Learning