Partage via

Runtimes Azure Synapse

  • Article

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

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, qui est 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) Q2 2025 Q1 2026
Runtime Azure Synapse pour Apache Spark 3.3 17 novembre 2022 fin du support annoncé 12 juillet 2024 31/3/2025
Runtime Azure Synapse pour Apache Spark 3.2 8 juillet 2022 déconseillé et bientôt désactivé 8 juillet 2023 8 juillet 2024
Runtime Azure Synapse pour Apache Spark 3.1 26 mai 2021 déconseillé et bientôt désactivé 26 janvier 2023 26 janvier 2024
Runtime Azure Synapse pour Apache Spark 2.4 15 décembre 2020 déconseillé et bientôt désactivé 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.class
  • org/apache/log4j/net/SMTPAppender.class
  • org/apache/log4j/net/JMSAppender.class
  • org/apache/log4j/net/JMSSink.class
  • org/apache/log4j/jdbc/JDBCAppender.class
  • org/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 :

  1. Recréez le pool Spark 3.3 à partir du terrain.
  2. Rétrogradez le pool Spark actuel 3.3 à 3.1, supprimez tous les packages attachés, puis mettez à niveau vers la version 3.3.

Question : Pourquoi ne puis-je pas effectuer une mise à niveau vers la version 3.4 sans recréer un nouveau pool Spark ?

Réponse : Ce n’est pas autorisé à partir de l’expérience utilisateur, le client peut utiliser Azure PowerShell pour mettre à jour la version de Spark. Utilisez « ForceApplySetting », afin que tous les clusters existants (avec l’ancienne version) soient désactivés.

Exemple de requête :

$_target_work_space = @("workspace1", "workspace2")

Get-AzSynapseWorkspace |
    ForEach-Object {
        if ($_target_work_space -contains $_.Name) {
            $_workspace_name = $_.Name
            Write-Host "Updating workspace: $($_workspace_name)"
            Get-AzSynapseSparkPool -WorkspaceName $_workspace_name |
            ForEach-Object {
                Write-Host "Updating Spark pool: $($_.Name)"
                Write-Host "Current Spark version: $($_.SparkVersion)"
        
                Update-AzSynapseSparkPool -WorkspaceName $_workspace_name -Name $_.Name -SparkVersion 3.4 -ForceApplySetting
              }
        }
    }

Contenu connexe