Phase 2 : Migration de charge de travail Spark

Cet article est la phase 2 sur 4 de la série de bonnes pratiques de migration d'Azure Synapse Spark vers Microsoft Fabric.

Utilisez cet article pour migrer vos charges de travail Spark de Azure Synapse vers Microsoft Fabric. Cet article décrit l'exécution des Assistant Migration, la refactorisation des modèles de code qui ne peuvent pas être convertis automatiquement et la migration des configurations de pool Spark, des environnements et des bibliothèques.

Dans cet article, vous allez apprendre à :

  • Comprendre le processus de migration pour les espaces de travail Synapse standard (non-Git) et compatibles Git.
  • Utilisez le Assistant Migration Spark pour migrer des notebooks, des définitions de travaux Spark et des pools.
  • Refactoriser des modèles de code spécifiques à Synapse pour la compatibilité Fabric.
  • Migrez les paramètres, les environnements et les bibliothèques du pool Spark.
  • Identifiez et résolvez les écarts de compatibilité des bibliothèques entre Synapse et Fabric.

Migrer avec le Assistant Migration

Le Assistant Migration Spark automatise la migration de notebooks, de définitions de travaux Spark, de pools et de métadonnées de base de données lake de Synapse vers Fabric. L’Assistant copie et transforme vos éléments, mais ne termine pas la migration. Vous devez toujours refactoriser le code, rapprocher les lacunes de configuration et valider les résultats.

Pour obtenir des instructions pas à pas sur l’exécution de l’Assistant, consultez Spark Synapse pour Fabric Spark Assistant Migration (Aperçu).

L’Assistant migre les éléments suivants :

  • Les pools Spark sont migrés vers Fabric pools et les artefacts d’environnement correspondants.
  • Les notebooks et leurs environnements associés sont migrés.
  • Les définitions de travaux Spark sont migrées avec des environnements associés.
  • Les bases de données Lake sont mappées aux schémas Fabric ; les tables Delta gérées sont migrées via les raccourcis du catalogue OneLake.

Important

Les configurations Spark, les bibliothèques personnalisées et les paramètres d’exécuteur personnalisés ne sont pas migrés par l’Assistant. Vous devez les configurer manuellement dans les environnements Fabric. Les espaces de travail Synapse sous un réseau virtuel ne peuvent pas être migrés avec l'assistant.

Migration de l’espace de travail standard (non Git)

Pour les espaces de travail où les notebooks et les disques SSD sont stockés directement dans Synapse (et non dans un référentiel Git) :

  1. Exécutez le Assistant Migration Spark à partir de votre espace de travail Fabric (Migrate>Data engineering items). Sélectionnez l’espace de travail Synapse source et migrez tous les éléments Spark.

  2. Valider les dépendances : vérifiez que la même version spark est utilisée. Si les blocs-notes référencent d’autres blocs-notes via mssparkutils.notebook.run(), vérifiez qu’ils ont également été migrés. Le Assistant Migration conserve la structure des dossiers (Fabric prend en charge jusqu’à 10 niveaux d’imbrication).

  3. Refactoriser le code : remplacez mssparkutils par notebookutils, remplacez les références de service lié par des Connexions Fabric et mettez à jour les chemins de fichiers. Pour plus d’informations, consultez la section Refactoriser le code Spark .

Migration de l’espace de travail avec Git

Pour les espaces de travail où les notebooks et les SJD sont stockés dans un référentiel Azure DevOps ou GitHub, notez que Synapse et Fabric utilisent différents formats de sérialisation Git. Synapse stocke les notebooks au format JSON ; Fabric utilise le format source .py/.scala ou .ipynb. Vous ne pouvez pas diriger directement un espace de travail Fabric vers la même branche Git Synapse.

  1. Migrez les éléments. Utilisez le Assistant Migration Spark pour migrer des notebooks et des SJD de l’espace de travail Synapse vers un espace de travail Fabric. Cela convertit les éléments en format compatible Fabric.

  2. Refactoriser le code. Appliquez la même refactorisation du code que le scénario standard : remplacez mssparkutils, mettez à jour les chemins de fichier, remplacez les services liés. Pour plus d’informations, consultez la section Refactoriser le code Spark .

  3. Connectez Fabric espace de travail à Git. Connectez votre espace de travail Fabric à une nouvelle branche ou dossier dans votre référentiel (Workspace Settings>Source Control>Git Integration). Utilisez une branche ou un dossier distinct de votre contenu Synapse pour éviter les conflits. Validez le contenu de l’espace de travail Fabric pour remplir la nouvelle branche.

  4. Configurer des pipelines de déploiement (facultatif). Configurez les pipelines de déploiement Fabric (Dev → Test → Prod) pour le CI/CD continu. Fabric prend en charge la liaison automatique pour les lakehouses par défaut et les environnements attachés lors du déploiement à plusieurs étapes.

Conseil / Astuce

Conservez votre branche Git Synapse intacte en tant que référence historique. Créez une nouvelle branche ou un nouveau dossier pour le contenu Fabric. Fabric stocke les blocs-notes en tant que fichiers sources (.py pour PySpark) plutôt que JSON, qui fournit des différences Git plus propres pour la révision du code.

Refactoriser le code Spark

Après avoir migré vos blocs-notes et définitions de travaux Spark, vous devez corriger les modèles de code que les Assistant Migration ne peuvent pas convertir automatiquement. Cette section vous guide tout au long du remplacement des API spécifiques à Synapse, la mise à jour des chemins d’accès aux fichiers et la modification des modèles d’informations d’identification pour qu’elles fonctionnent avec Fabric.

Audit de pré-refactorisation

Avant de traiter des modèles de refactorisation individuels, exécutez une recherche à l’échelle du code dans tous les notebooks pour identifier le code spécifique à Synapse qui a besoin de modifications.

Modèle de recherche Catégorie Action nécessaire
spark.synapse.linkedService Services liés Supprimer ; remplacer par l'authentification directe par point de terminaison ou les secrets de Key Vault.
getSecretWithLS Credentials Remplacer par getSecret(vaultUrl, secretName)
TokenLibrary Jeton/Authentification Retirer; utiliser la configuration directe d'OAuth ou *notebookutils*
synapsesql Connecteur SQL Remplacer spark.read.synapsesql() par les lectures au format Delta
mssparkutils Spark Utils Remplacer par notebookutils (la plupart des API identiques)
spark.catalog.listDatabases API de catalogue Remplacer par spark.sql("SHOW DATABASES")
spark.catalog.currentDatabase API de catalogue Remplacer par spark.sql("SELECT CURRENT_DATABASE()")
spark.catalog.getDatabase API de catalogue Remplacer par spark.sql("DESCRIBE DATABASE ...")
spark.catalog.listFunctions API de catalogue Non pris en charge dans Fabric — supprimer
spark.catalog.registerFunction API de catalogue Non pris en charge : utiliser spark.udf.register() à la place
spark.catalog.functionExists API de catalogue Non pris en charge dans Fabric — supprimer
LinkedServiceBasedTokenProvider Fournisseur d’authentification Remplacer par ClientCredsTokenProvider
getPropertiesAsMap Services liés Retirer; configurer directement le compte de stockage
spark.storage.synapse Services liés Supprimer : non pris en charge dans Fabric
/user/trusted-service-user/ Chemins d’accès aux fichiers Remplacer par le chemin d’accès OneLake ou le chemin de raccourci
cosmos.oltp Cosmos DB Mise à jour pour utiliser Key Vault pour les secrets au lieu du service lié
kusto.spark.synapse Kusto/ADX Remplacer l’authentification du service lié par accessToken via getToken()

Conseil / Astuce

Exécutez ces recherches dans l’ensemble de votre référentiel de notebooks avant la migration. Les blocs-notes sans aucune correspondance peuvent être migrés tels quels. Les blocs-notes correspondant aux critères doivent être prioritaires pour la refactorisation du code en utilisant les directives détaillées des sections suivantes.

Utilisation du chemin d’accès aux fichiers

Mettez à jour les notebooks Synapse qui utilisent des chemins d’accès relatifs ou des chemins de stockage gérés par Synapse pour utiliser des chemins d’accès directs abfss:// ou des chemins OneLake dans Fabric.

Avant (Synapse) After (Fabric)
"abfss://...@<synapse_storage>.dfs.core.windows.net/user/trusted-service-user/deltalake" "abfss://<workspace_id>@onelake.dfs.fabric.microsoft.com/<lakehouse_id>/Tables/deltalake"
spark.read.synapsesql("<pool>.<schema>.<table>") spark.read.format("delta").load("abfss://.../<lakehouse>/Tables/<table>")

Conseil / Astuce

Remplacez tous les chemins de stockage gérés par Synapse par des chemins OneLake (abfss://<workspace_id>@onelake.dfs.fabric.microsoft.com/<item_id>/...). Pour les données ADLS Gen2, créez des raccourcis OneLake et référencez plutôt les chemins de raccourci.

API de catalogue Spark

Fabric ne prend pas en charge plusieurs méthodes spark.catalog. Remplacez-les par des équivalents Spark SQL.

Avant (Synapse) After (Fabric)
spark.catalog.listDatabases() spark.sql("SHOW DATABASES").show()
spark.catalog.currentDatabase() spark.sql("SELECT CURRENT_DATABASE()").first()["current_database()"]
spark.catalog.getDatabase(db_name) spark.sql(f"DESCRIBE DATABASE {db_name}").show()
spark.catalog.listFunctions() Non pris en charge dans Fabric : supprimer ou ignorer
spark.catalog.registerFunction(name, fn) Non pris en charge dans Fabric : utilisez spark.udf.register() à la place
spark.catalog.functionExists(name) Non pris en charge dans Fabric : supprimer ou ignorer

Note

spark.catalog méthodes de table telles que createTable(), tableExists() et listTables() fonctionnent normalement dans Fabric. Seules les méthodes de catalogue au niveau de la base de données et au niveau de la fonction nécessitent une refactorisation.

MSSparkUtils et NotebookUtils

Remplacez les appels mssparkutils par les équivalents de Fabric notebookutils. Les modifications les plus courantes liées aux informations d’identification sont les suivantes :

Avant (Synapse) After (Fabric)
mssparkutils.credentials.getSecretWithLS("sampleLS", secretKey) notebookutils.credentials.getSecret("https://<vault>.vault.azure.net/", secretKey)
TokenLibrary.getSecret("foo", "bar") notebookutils.credentials.getSecret("https://foo.vault.azure.net/", "bar")

Dans Fabric, la récupération de secrets basée sur un service lié (getSecretWithLS) n'est pas prise en charge. Au lieu de cela, référencez directement l’URL Key Vault à l’aide de notebookutils.credentials.getSecret(vaultUrl, secretName). Le modèle identique s’applique aux TokenLibrary.getSecret() appels.

Note

La plupart des méthodes mssparkutils.fs (par exemple, ls, cp, mv, rm, mkdirs, head) fonctionnent de la même façon que notebookutils.fs dans Fabric. Les modifications principales concernent les méthodes d'identifiants et secrètes, ainsi que les références de chemin d'accès notebook.run().

connecteur Azure Data Explorer (Kusto)

Les notebooks Synapse qui se connectent à Azure Data Explorer (Kusto) via des services liés doivent être refactorisés pour utiliser l’authentification directe du point d'accès direct.

Avant (Synapse) After (Fabric)
.option("spark.synapse.linkedService", "AzureDataExplorer1") Supprimer la référence du service lié
Lire avec l'option de service lié activée .option("accessToken", notebookutils.credentials.getToken("https://<cluster>.kusto.windows.net"))

Remplacez l’option de service lié par une option accessToken. Utilisez notebookutils.credentials.getToken() pour obtenir un jeton pour votre point de terminaison de cluster Kusto. Les autres options de requête (kustoDatabase, kustoQuery) restent inchangées.

Connecteur Cosmos DB

Mettez à jour les connexions Cosmos DB dans Synapse qui utilisent des services liés ou getSecretWithLS.

Avant (Synapse) After (Fabric)
.option("spark.synapse.linkedService", "CosmosDbLS") Supprimer la référence du service lié
mssparkutils.credentials.getSecretWithLS("cosmosKeyLS", "cosmosKey") notebookutils.credentials.getSecret("https://<vault>.vault.azure.net/", "cosmosKey")

Remplacez la référence au service lié par une configuration directe de l'endpoint Cosmos DB. Stockez la clé de compte Cosmos DB dans Azure Key Vault et récupérez-la à l’aide de notebookutils.credentials.getSecret(vaultUrl, secretName) au lieu de getSecretWithLS().

Références de service lié

Remplacez toutes les références de service lié à Synapse dans Fabric.

Avant (Synapse) After (Fabric)
spark.conf.set("spark.storage.synapse.linkedServiceName", ls_name) Supprimer : non pris en charge dans Fabric
spark.conf.set("fs.azure.account.oauth.provider.type", "com.microsoft.azure.synapse.tokenlibrary.LinkedServiceBasedTokenProvider") spark.conf.set("fs.azure.account.oauth.provider.type", "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider")
TokenLibrary.getPropertiesAsMap(linked_service_cfg) Supprimer : utiliser une configuration directe de chaîne de connexion ou de principal de service

Dans Fabric, il n’existe aucun service lié. Remplacez le fournisseur de jetons Synapse par les informations d’identification du client OAuth standard (principal de service). Configurez fs.azure.account.auth.type, oauth.provider.type, client.id, client.secret, et client.endpoint directement à l’aide de spark.conf.set().

Bibliothèque de jetons

Le TokenLibrary de Synapse pour obtenir des jetons et lire les propriétés du service associé n'est pas disponible dans Fabric. Remplacez-le par des modèles équivalents.

Avant (Synapse) After (Fabric)
TokenLibrary.getPropertiesAsMap(serviceConnection) Supprimer : configurer directement le compte de stockage
val my_account = conexion("Endpoint").toString.substring(8) val my_account = "<storage_account_name>" // Hardcode or retrieve via notebookutils
mssparkutils.fs.head(internalPath, Int.MaxValue) notebookutils.fs.head(internalPath, Int.MaxValue)

Pour l'accès à ADLS Gen2 basé sur OAuth, configurez directement les informations d'identification du principal de service en utilisant spark.conf.set() avec les clés spécifiques au compte de stockage (par exemple, fs.azure.account.auth.type.<account>.dfs.core.windows.net) au lieu de compter sur des fournisseurs de jetons de service liés.

Important

Passez en revue tous les notebooks pour les références de services liés avant le changement. Les appels spark.synapse.linkedService restants, TokenLibrary ou getSecretWithLS échouent lors de l’exécution dans Fabric.

Migration de définition de tâche Spark

Les définitions de travaux Spark (SJD) sont des configurations de travaux par lots qui référencent un fichier exécutable principal (.pyou .jar.R), des bibliothèques de référence facultatives, des arguments de ligne de commande et un contexte lakehouse. Bien que le Assistant Migration Spark gère automatiquement la migration SJD, les différences importantes entre Synapse et Fabric SJD nécessitent une attention particulière.

Principales différences entre Synapse et Fabric SJD

  • Cadre Lakehouse requis. Dans Fabric, chaque SJD doit avoir au moins un lac associé à celui-ci. Ce lakehouse sert de système de fichiers par défaut pour le runtime Spark. Tout code qui utilise des chemins d’accès relatifs lit et écrit à partir du lakehouse par défaut. Dans Synapse, les SJD utilisent le stockage par défaut de l’espace de travail (ADLS Gen2) comme système de fichiers par défaut.

  • Langues prises en charge. Fabric prend en charge PySpark (Python), Spark (Scala/Java) et SparkR. .NET pour Spark (C#/F#) n'est pas pris en charge dans Fabric. Vous devez réécrire ces charges de travail dans Python ou Scala avant la migration.

  • Réessayez les stratégies. Fabric SJDs prennent en charge les stratégies de réessai intégrées, telles que le nombre maximal de tentatives et l'intervalle entre celles-ci. Cette fonctionnalité est utile pour les travaux Spark Structured Streaming qui doivent s’exécuter indéfiniment.

  • Liaison avec l'environnement. Dans Synapse, les SJDs sont associés à un cluster Spark. Dans Fabric, les SJDs sont liés à un environnement, qui contient la configuration du pool, les bibliothèques et les propriétés Spark. Le Assistant Migration mappe automatiquement les références de pool Synapse aux environnements Fabric.

  • Planification. Fabric SJD ont une planification intégrée (Settings>Schedule) sans nécessiter de pipeline distinct. Dans Synapse, la planification SJD nécessite un pipeline avec une activité de tâche Spark. Si vous avez des pipelines Synapse qui déclenchent uniquement des SJD, envisagez d'utiliser la planification SJD intégrée de Fabric au lieu de migrer les pipelines.

  • Importer/exporter. Synapse prend en charge l’importation et l’exportation JSON basées sur l’interface utilisateur pour les disques SSD. Fabric ne prend pas en charge l'importation ou l'exportation de l'interface utilisateur. Utilisez l'Assistant de migration Spark ou l'API REST Fabric pour créer ou mettre à jour des SJDs de manière programmatique.

Refactoriser le code SJD

Les mêmes modèles de refactorisation de code dans cet article s’appliquent aux fichiers principaux SJD. Les modifications se répartissent en deux catégories.

Modifications du code source (à l'intérieur du fichier principal .py, .jar, ou .R) :

  • Remplacez mssparkutils par notebookutils pour les opérations d’identification et de système de fichiers.
  • Mettez à jour les chemins de fichiers codés en dur dans le code vers les chemins d’accès OneLake abfss:// ou les chemins de raccourci, le cas échéant. Les SJDs qui utilisent uniquement des chemins relatifs dans le lakehouse par défaut pourraient ne pas nécessiter de modifications.
  • Remplacez les références de service lié dans le code par des secrets de Key Vault ou des connexions de Fabric.

Note

Les connexions DMTS ne sont pas encore prises en charge dans les définitions de travaux Spark de Fabric (uniquement prises en charge dans les notebooks). Si votre code SJD utilise DMTS, refactorisez pour utiliser l’authentification directe du point de terminaison.

Modifications de la configuration SJD (dans les paramètres de l'élément SJD de Fabric) :

  • Vérifiez que les chemins ADLS Gen2 référencés par les fichiers de définition principaux sont toujours accessibles à partir de l’espace de travail Fabric. Si des fichiers ont été stockés dans le stockage interne de l’espace de travail Synapse, chargez-les à nouveau dans le Fabric SJD ou déplacez-les vers un emplacement ADLS Gen2 accessible.
  • Vérifiez que tous les fichiers de référence (.py, .R, .jar) sont accessibles après la migration. Chargez à nouveau tous les fichiers stockés dans le stockage interne de l’espace de travail Synapse.
  • Si les arguments de ligne de commande contiennent des chemins d’accès ou des chaînes de connexion spécifiques à Synapse, mettez-les à jour avec leurs équivalents pour Fabric.

Migrer des pools, des environnements et des bibliothèques

Une fois vos blocs-notes et définitions de travaux Spark migrés, vous devez décider de la stratégie de pool et d’environnement. Cette section explique quand vous pouvez utiliser Fabric pools de démarrage (au lieu de migrer), quand créer des environnements personnalisés et comment identifier et résoudre les lacunes de compatibilité des bibliothèques.

Migration de pool Spark

Pools de démarrage Fabric

Les pools de démarrage Fabric permettent un démarrage de session Spark en quelques secondes, une amélioration significative par rapport aux pools Synapse Spark, qui nécessitent des démarrages à froid durant plusieurs minutes pour démarrer les clusters. Les pools de démarrage sont prêts à être utilisés à partir de la plateforme et ne nécessitent aucune configuration.

Conseil / Astuce

Si votre pool Synapse Spark n’a pas de configurations personnalisées, aucune bibliothèque personnalisée et aucune exigence de taille de nœud spécifique au-delà de Moyenne, ne migrez pas le pool. Au lieu de cela, laissez vos blocs-notes et définitions de travaux Spark utiliser les paramètres du pool de démarrage par défaut de l’espace de travail Fabric. Cette approche vous offre les temps de démarrage les plus rapides et la surcharge de gestion de pool zéro. Créez uniquement un pool personnalisé ou un environnement lorsque vous avez un besoin spécifique.

Quand créer un pool ou un environnement personnalisé

Créez un Fabric pool personnalisé et/ou un environnement uniquement lorsque votre charge de travail nécessite :

  • Une taille de nœud spécifique (Small, Large, XLarge, XXLarge) différente de la taille moyenne par défaut.
  • Bibliothèques personnalisées (packages pip, packages conda, JAR, roues) qui ne sont pas dans le runtime intégré Fabric.
  • Propriétés Spark personnalisées (par exemple, spark.sql.shuffle.partitions, spark.executor.memory) au-delà des valeurs par défaut.
  • Points de terminaison privés managés pour accéder aux sources de données privées (nécessite des pools personnalisés).
  • Une version spécifique du runtime Spark différente de la valeur par défaut de l’espace de travail.

Migration de la configuration et de la bibliothèque

Migrez les configurations et bibliothèques Spark vers des environnements Fabric.

Pour obtenir des instructions détaillées sur la migration de bibliothèques vers des environnements Fabric, consultez Migrate Spark Libraries from Azure Synapse to Fabric.

  1. Exporter des configurations Spark. Dans Synapse Studio, accédez à ManageSpark Pools sélectionnez le pool < C5>Configurations + Bibliothèques télécharger en tant que .

  2. Importer dans l’environnement. Dans Fabric, créez un artefact d’environnement. Accédez à Spark Compute>Propriétés Spark>Télécharger le fichier exportéSparkproperties.yml.

  3. Migrez des bibliothèques. Pour les bibliothèques de niveau pool, téléchargez des packages (Wheel, JARs, tar) dans la section des bibliothèques de l'environnement. Pour les packages PyPI/Conda, ajoutez-les à la configuration de la bibliothèque publique de l’environnement.

Important

Les paramètres de bibliothèque au niveau de l’espace de travail dans Fabric sont déconseillés. Migrez toutes les bibliothèques vers les artefacts d’environnement. La migration supprime définitivement les configurations au niveau de l’espace de travail existantes : téléchargez tous les paramètres avant d’activer les environnements.

Compatibilité de la bibliothèque : Synapse et Fabric

Fabric Runtime 1.3 (Spark 3.5) est fourni avec 223 bibliothèques Python, 183 Java/Scala et 135 R intégrées. La plupart des bibliothèques Synapse sont disponibles dans Fabric, mais il existe des lacunes qui peuvent entraîner des défaillances d’exécution si elles ne sont pas traitées avant la migration.

Pour identifier les bibliothèques que vos notebooks utilisent réellement, exécutez ces vérifications avant d’examiner les tables d’écart :

  • Python notebooks : Rechercher des instructions import et from ... import dans tous les fichiers .py / .ipynb.
  • Java/Notebooks Scala et SJDs : Rechercher des instructions de code import et des coordonnées Maven ; rechercher des packages tels que com.azure.cosmos.spark ou com.microsoft.kusto.spark.
  • Exporter la liste complète des dépendances : Exécuter pip freeze dans un notebook Synapse, comparez-le au manifeste Fabric Runtime 1.3. Seules les bibliothèques qui apparaissent à la fois dans votre pip freeze résultat et dans les tables d’écart ci-dessous nécessitent une action.
  • Bibliothèques personnalisées au niveau du pool et de l’espace de travail : Dans Synapse Studio, accédez à Manage> Pools Sparkapache> sélectionnez le pool >Packages pour voir les bibliothèques personnalisées qui doivent être rechargées dans un environnement Fabric.

bibliothèques Python manquantes dans Fabric

Catégorie bibliothèques Action
CUDA / GPU (9 libs) libcublas, libcufft, libcufile, libcurand, libcusolver, libcusparse, libnpp, libnvfatbin, libnvjitlink, libnvjpeg Non disponible : Fabric ne prend pas en charge les pools GPU. Refactoriser les charges de travail GPU pour utiliser des alternatives basées sur le processeur ou conserver Synapse.
Clients HTTP / API httpx, httpcore, h11, google-auth, jmespath Installer via l’environnement : pip install httpx google-auth jmespath
ML / Interprétabilité interpréter, interpréter-core Installer via l’environnement : pip install interpret
Sérialisation des données marshmallow, jsonpickle, frozendict, fixedint Installez via l’environnement si nécessaire : pip install marshmallow jsonpickle
Journalisation / Télémétrie fluent-logger, humanfriendly, library-metadata-cooker, impulse-python-handler fluent-logger : installez le cas échéant. D'autres sont internes à Synapse, probablement non nécessaires.
Les internes de Jupyter jupyter-client, jupyter-core, jupyter-ui-poll, jupyterlab-widgets, ipython-pygments-lexers Fabric gère l’infrastructure Jupyter en interne. Ces bibliothèques ne sont généralement pas nécessaires dans le code utilisateur.
Bibliothèques système/C libgcc, libstdcxx, libgrpc, libabseil, libexpat, libnsl, libzlib Bibliothèques système de bas niveau. Généralement, pas importé directement. Installez uniquement si vous disposez d’extensions C qui dépendent de ces extensions.
Fichier / concurrence filelock, fsspec, knack Installez via l’environnement s’il est utilisé : pip install filelock fsspec

bibliothèques Java/Scala manquantes dans Fabric

Library Synapse Version Action
azure-cosmos-analytics-spark 2.2.5 Installez en tant que fichier JAR personnalisé dans l’environnement Fabric si vos travaux Spark utilisent le connecteur d’analytique Cosmos DB.
junit-jupiter-params 5.5.2 Bibliothèque de test uniquement. Non nécessaire dans les notebooks de production.
junit-platform-commons 1.5.2 Bibliothèque de test uniquement. Pas nécessaire dans les cahiers de production.

Bibliothèques R

Une seule différence : Synapse inclut le package lightgbm R (v4.6.0) qui n'est pas dans Fabric. Installez via l’environnement si nécessaire. Fabric ajoute FabricTelemetry (v1.0.2) qui est interne à Fabric.

Différences de version notables

68 bibliothèques Python existent sur les deux plateformes, mais avec des versions différentes. La plupart sont des différences de version mineures, mais 17 ont des sauts de version majeurs qui pourraient affecter le comportement.

Library Version du Fabric Synapse Version Impact
libxgboost 2.0.3 3.0.1 Modifications de l’API XGBoost entre v2 et v3. Tester le code d’entraînement/de prédiction du modèle.
flacon 2.2.5 3.0.3 Flask 3.x a des modifications importantes. Si vous servez des API Flask à partir de notebooks, testez soigneusement.
lxml 4.9.3 5.3.0 Modifications mineures de l’API. Testez les flux de travail d’analyse XML.
libprotobuf 3.20.3 4.25.3 Protobuf 4.x a des changements cassants pour les définitions de proto personnalisées.
markupsafe 2.1.3 3.0.2 MarkupSafe 3.x abandonne la prise en charge de Python 3.7, mais l’API reste compatible.
libpq 12.17 17.4 Bibliothèque de client PostgreSQL. Saut de version majeure : testez les connexions de base de données.
libgcc-ng / libstdcxx-ng 11.2.0 15.2.0 Environnement d'exécution de GCC. Peut affecter la compatibilité des extensions C.

Note

Synapse fournit généralement des versions plus récentes de bibliothèques au niveau du système (GCC, protobuf, libpq), tandis que Fabric fournit des versions plus récentes de bibliothèques de données/ML (plus Python packages globaux). Si vous avez besoin d'une version précise, épinglez-la dans votre configuration d'environnement Fabric.

Conseil / Astuce

Exécutez une vérification de compatibilité rapide : exportez la liste des bibliothèques de votre pool Synapse (pip freeze), comparez-les au manifeste Fabric Runtime 1.3 et préinstallez les bibliothèques manquantes dans votre environnement de Fabric avant d'exécuter des notebooks migrés. Pour obtenir une comparaison ligne par ligne de chaque bibliothèque intégrée et de chaque version intégrée entre les runtimes Fabric et Synapse Spark, consultez le référentiel microsoft/synapse-spark-runtime GitHub.

Contenu connexe

  • Last updated on