Runtimes Azure Synapse
Les pools Apache Spark dans Azure Synapse utilisent des runtimes pour lier des versions de composants essentiels (par exemple, des optimisations, des packages et des connecteurs Azure Synapse) à une version Apache Spark spécifique. Chaque runtime est mis à niveau régulièrement pour inclure de nouvelles améliorations, fonctionnalités et correctifs. Lorsque vous créez un pool Apache Spark serverless, sélectionnez la version d’Apache Spark correspondante. En fonction de cela, le pool est préinstallé avec les composants et packages d’exécution associés.
Ces runtimes ont les avantages suivants :
- Temps de démarrage de session plus courts
- Compatibilité testée avec des versions Apache Spark spécifiques
- Accès aux connecteurs populaires et compatibles, ainsi qu’aux packages open source
Versions du runtime Azure Synapse prises en charge
Avertissement
Notification de fin de prise en charge pour le runtime Azure Synapse pour Apache Spark 2.4 et Apache Spark 3.1.
- Depuis le 29 septembre 2023, Azure Synapse ne prend plus officiellement en charge les runtimes Spark 2.4.
- À compter du 26 janvier 2024, Azure Synapse interrompt la prise en charge officielle des runtimes Spark 3.1.
- Après ces dates, nous ne traiterons aucun ticket de support lié à Spark 2.4 ou 3.1. Aucun pipeline de mise en production n’est en place pour les correctifs de bogues ou de sécurité pour Spark 2.4 et 3.1. L’utilisation de Spark 2.4 ou 3.1 après les dates de coupure de support est entreprise à un seul risque. Nous vous déconseillons fortement de continuer à l’utiliser en raison de problèmes potentiels de sécurité et de fonctionnalités.
Conseil
Nous vous recommandons vivement de mettre à niveau de manière proactive les charges de travail vers une version ga plus récente du runtime (par exemple, Azure Synapse Runtime pour Apache Spark 3.4 (GA)). Reportez-vous au guide de migration Apache Spark.
Le tableau suivant répertorie le nom du runtime, la version Apache Spark et la date de publication des versions du runtime Azure Synapse prises en charge.
| Nom du runtime | Date de publication | Étape de publication | Date de fin de l’annonce du support | Date d’effet de fin du support |
|---|---|---|---|---|
| Runtime Azure Synapse pour Apache Spark 3.4 | 21 novembre 2023 | GA (à compter du 8 avril 2024) | ||
| Runtime Azure Synapse pour Apache Spark 3.3 | 17 novembre 2022 | Disponibilité générale (à la date du 23 février 2023) | Q2/Q3 2024 | Q1 2025 |
| Runtime Azure Synapse pour Apache Spark 3.2 | 8 juillet 2022 | Fin du support annoncé | 8 juillet 2023 | 8 juillet 2024 |
| Runtime Azure Synapse pour Apache Spark 3.1 | 26 mai 2021 | déconseillé | 26 janvier 2023 | 26 janvier 2024 |
| Runtime Azure Synapse pour Apache Spark 2.4 | 15 décembre 2020 | déconseillé | 29 juillet 2022 | 29 septembre 2023 |
Étapes de mise publication du runtime
Pour le runtime complet pour les stratégies de cycle de vie et de support Apache Spark, reportez-vous au runtime Synapse pour le cycle de vie et la prise en charge d’Apache Spark.
Mise à jour corrective du runtime
Les runtimes Azure Synapse pour les correctifs Apache Spark sont déployés tous les mois contenant des correctifs de bogue, de fonctionnalité et de sécurité sur le moteur principal Apache Spark, les environnements de langage, les connecteurs et les bibliothèques.
Remarque
- Les mises à jour de maintenance sont automatiquement appliquées aux nouvelles sessions pour un pool Apache Spark serverless donné.
- Vous devez tester vos applications et vérifier qu’elles s’exécutent correctement quand vous utilisez de nouvelles versions du runtime.
Important
Patchs de sécurité Log4j 1.2.x
La bibliothèque Log4j open source version 1.2.x a plusieurs CVE (vulnérabilités et expositions courantes) connues, comme décrit ici.
Sur tous les runtimes de pool Synapse Spark, nous avons patché les fichiers JAR Log4j 1.2.17 pour atténuer les CVE suivantes : CVE-2019-1751, CVE-2020-9488, CVE-2021-4104, CVE-2022-23302, CVE-2022-2330, CVE-2022-23307
Le patch appliqué fonctionne en supprimant les fichiers suivants utilisés pour appeler les vulnérabilités :
org/apache/log4j/net/SocketServer.classorg/apache/log4j/net/SMTPAppender.classorg/apache/log4j/net/JMSAppender.classorg/apache/log4j/net/JMSSink.classorg/apache/log4j/jdbc/JDBCAppender.classorg/apache/log4j/chainsaw/*
Bien que les classes ci-dessus n’aient pas été utilisées dans les configurations Log4j par défaut dans Synapse, certaines applications utilisateur peuvent toujours en dépendre. Si votre application doit utiliser ces classes, utilisez la gestion des bibliothèques pour ajouter une version sécurisée de Log4j au pool Spark. N’utilisez pas Log4j version 1.2.17, car il réintroduit les vulnérabilités.
La stratégie de patch diffère en fonction de l’étape de cycle de vie du runtime :
Runtime en disponibilité générale : recevez aucune mise à niveau sur les versions majeures (autrement dit, 3.x -> 4.x). Et mettra à niveau une version mineure (autrement dit, 3.x -> 3.y) tant qu’il n’y a pas d’impact sur la dépréciation ou la régression.
Runtime en préversion : aucune mise à niveau de version majeure, sauf si strictement nécessaire. Les versions mineures (3.x -> 3.y) seront mises à niveau pour ajouter les dernières fonctionnalités à un runtime.
Le runtime de support à long terme (LTS) est corrigé uniquement avec des correctifs de sécurité.
La fin du support annoncé lors de l’exécution n’aura pas de correctifs de bogues et de fonctionnalités. Les correctifs de sécurité sont rétroportés en fonction de l’évaluation des risques.
Migration entre les versions d’Apache Spark - prise en charge
Ce guide fournit une approche structurée pour les utilisateurs qui cherchent à mettre à niveau leur runtime Azure Synapse pour les charges de travail Apache Spark des versions 2.4, 3.1, 3.2 ou 3.3 vers la dernière version en disponibilité générale, par exemple 3.4. La mise à niveau vers la version la plus récente permet aux utilisateurs de tirer parti des améliorations des performances, des nouvelles fonctionnalités et des mesures de sécurité améliorées. Il est important de noter que la transition vers une version ultérieure peut nécessiter des ajustements dans votre code Spark existant en raison d’incompatibilités ou de fonctionnalités déconseillées.
Étape 1 : Évaluer et planifier
- Évaluer la compatibilité : commencez par examiner les guides de migration Apache Spark pour identifier les incompatibilités potentielles, les fonctionnalités déconseillées et les nouvelles API entre votre version Actuelle de Spark (2.4, 3.1, 3.2 ou 3.3) et la version cible (par exemple, 3.4).
- Analyser codebase : examinez soigneusement votre code Spark pour identifier l’utilisation d’API déconseillées ou modifiées. Soyez particulièrement attentif aux requêtes SQL et aux fonctions définies par l’utilisateur (UDF), qui peuvent être affectées par la mise à niveau.
Étape 2 : Créer un pool Spark à des fins de test
- Créez un pool : dans Azure Synapse, accédez à la section Pools Spark et configurez un nouveau pool Spark. Sélectionnez la version spark cible (par exemple, 3.4) et configurez-la en fonction de vos besoins en matière de performances.
- Configurer la configuration du pool Spark : vérifiez que toutes les bibliothèques et dépendances de votre nouveau pool Spark sont mises à jour ou remplacées pour être compatibles avec Spark 3.4.
Étape 3 : Migrer et tester votre code
- Migrer le code : mettez à jour votre code pour qu’il soit conforme aux API nouvelles ou révisées dans Apache Spark 3.4. Cela implique l’adressage des fonctions déconseillées et l’adoption de nouvelles fonctionnalités, comme indiqué dans la documentation officielle d’Apache Spark.
- Test dans l’environnement de développement : testez votre code mis à jour dans un environnement de développement dans Azure Synapse, et non localement. Cette étape est essentielle pour identifier et résoudre les problèmes avant de passer à la production.
- Déployer et surveiller : après un test et une validation approfondis dans l’environnement de développement, déployez votre application sur le nouveau pool Spark 3.4. Il est essentiel de surveiller l’application pour tout comportement inattendu. Utilisez les outils de surveillance disponibles dans Azure Synapse pour suivre les performances de vos applications Spark.
Question : Quelles étapes devez-vous effectuer pour migrer de la version 2.4 vers la version 3.X ?
Réponse : reportez-vous au guide de migration Apache Spark.
Question : J’ai obtenu une erreur lorsque j’ai essayé de mettre à niveau le runtime du pool Spark à l’aide de l’applet de commande PowerShell lorsqu’ils ont des bibliothèques jointes.
Réponse : n’utilisez pas l’applet de commande PowerShell si vous avez installé des bibliothèques personnalisées dans votre espace de travail Synapse. À la place, procédez comme suit :
- Recréez le pool Spark 3.3 à partir du terrain.
- Rétrogradez le pool Spark actuel 3.3 à 3.1, supprimez tous les packages attachés, puis mettez à niveau vers la version 3.3.