Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Utilisez cet article comme point de départ pour migrer les charges de travail Azure Synapse Spark vers Microsoft Fabric. Il vous aide à déterminer les conseils à utiliser, ce qui peut être migré directement et où la refactorisation manuelle ou la validation est toujours nécessaire.
Fabric Data Engineering prend en charge lakehouse, notebook, environment, Spark job definition et pipeline. La plupart des migrations Synapse Spark impliquent une combinaison de migration d’éléments, de modifications d’accès aux données, de migration de métadonnées, de refactorisation de code et de validation post-migration.
Avant de migrer
Avant de commencer, vérifiez que Fabric Data Engineering est la destination appropriée pour votre charge de travail. Passez en revue le runtime Spark, le modèle de sécurité, le modèle de pool, le modèle d’environnement et les modèles d’accès aux données dont dépend votre implémentation Synapse actuelle.
Commencez par les articles suivants :
- Compare Fabric et Azure Synapse Spark : différences clés
- Phase 1 : Stratégie de migration et planification
Si vous migrez un espace de travail Synapse existant, envisagez de créer ou d'utiliser un espace de travail Fabric existant comme cible de migration. Cet article ne couvre pas la facilitation complète de l’espace de travail ni la migration des charges de travail autres que Spark.
Que pouvez-vous migrer ?
La migration synapse-à-Fabric s’étend généralement sur plusieurs flux de travail.
| Zone de migration | Étendue classique | Conseils principaux |
|---|---|---|
| Planification et évaluation | Inventaire des pools Spark, notebooks, définitions de tâches Spark, bases de données du lac, services liés et bloqueurs | Phase 1 : Stratégie de migration et planification |
| Éléments, refactorisation du code, pools, configurations et bibliothèques | Notebooks, Définitions de travaux Spark, pools Spark, mappages de bases de données lake, mssparkutilsservices liés, chemins d’accès de fichier, API de catalogue, authentification du connecteur, environnements, pools personnalisés, propriétés Spark, compatibilité des bibliothèques |
Phase 2 : Migration de charge de travail Spark |
| Métadonnées du metastore Hive et du lac | Bases de données, tables, partitions, tables gérées et tables externes | Phase 3 : Metastore Hive et migration des données |
| Accès aux données et pipelines | Raccourcis OneLake, accès ADLS Gen2, activités de copie, migration de pipeline | Migrer des données et des pipelines |
| Sécurité, validation et basculement | Rôles, connexions, gouvernance, vérification, planification de basculement | Phase 4 : Migration de la sécurité et de la gouvernance |
Choisir votre chemin de migration
Utilisez le chemin qui correspond à votre objectif.
- Vous avez besoin d’un plan de migration de bout en bout. Commencez par la série de bonnes pratiques en 4 phases. Il s’agit du meilleur point d’entrée pour la plupart des migrations de production.
- Vous souhaitez déplacer rapidement les éléments Spark pris en charge. Commencez par le Spark Assistant Migration puis utilisez les articles de refactorisation et de validation pour combler les lacunes.
- Vous n’avez besoin d’aide que pour une seule zone. Utilisez les articles spécifiques aux tâches pour les notebooks, les définitions de travaux Spark, les pools, les bibliothèques, les métadonnées du metastore Hive ou la migration de données/pipeline.
Ordre de lecture recommandé
Pour la plupart des équipes, le moyen le plus rapide d’aborder une migration Synapse Spark est :
- Passez en revue Compare Fabric et Azure Synapse Spark : différences clés.
- Lire la phase 1 : Stratégie de migration et planification.
- Exécutez le Spark Synapse pour Fabric Spark Assistant Migration lorsque cela est applicable.
- Refactoriser des notebooks, des tâches Spark, des pools et des bibliothèques en utilisant la phase 2 : migration des charges de travail Spark.
- Validez l’accès aux données, les métadonnées, la sécurité et la préparation du basculement à l’aide des articles restants sur les meilleures pratiques.
La migration de Synapse Spark vers Fabric est généralement un processus de copie et d’adaptation plutôt qu’un déplacement direct sur place. Vous pouvez migrer rapidement de nombreuses ressources, mais vous devez toujours vous attendre à valider le comportement d’exécution, à remplacer les intégrations spécifiques à Synapse et à aligner la sécurité, les métadonnées et les modèles opérationnels avec Fabric.
Série de bonnes pratiques
Utilisez la série de bonnes pratiques pour un chemin de migration structuré et de bout en bout :
- Phase 1 : Stratégie de migration et planification
- Phase 2 : Migration de charge de travail Spark
- Phase 3 : Metastore Hive et migration des données
- Phase 4 : Migration de la sécurité et de la gouvernance
Articles de migration spécifiques aux tâches
Si vous avez besoin de conseils ciblés pour une tâche de migration spécifique, utilisez ces articles :
- Assistant de Migration de Spark Synapse vers Fabric Spark
- Migration des notebooks Azure Synapse vers Fabric
- Migrate Spark Job Definitions from Azure Synapse to Fabric
- Migrer les pools Spark depuis Azure Synapse vers Fabric
- Migrer les configurations Spark d'Azure Synapse à Fabric
- Migrate Spark Libraries from Azure Synapse to Fabric
- Migrer les métadonnées du metastore Hive
- Migrer des données et des pipelines
Contenu connexe
- Compare Fabric et Azure Synapse Spark : différences clés
- Phase 1 : Stratégie de migration et planification
- Assistant de Migration de Spark Synapse vers Fabric Spark
- En savoir plus sur les options de migration pour les pools Spark, les configurations, les bibliothèques, les notebooks et la définition de travail Spark
- Migrer des données et des pipelines
- Migrer les métadonnées du metastore Hive