Phase 1 : Stratégie de migration et planification

Cet article est la première étape d'une série en quatre phases concernant les meilleures pratiques de migration d'Azure Synapse Spark vers Microsoft Fabric.

Commencez ici avant de migrer des blocs-notes, des définitions de travaux Spark, des pools ou des métadonnées de lac. Cet article vous aide à évaluer l’étendue de votre environnement Synapse Spark, à choisir une approche de migration qui correspond à votre tolérance au risque et à votre calendrier de livraison, et à comprendre les différences de Fabric qui affectent la planification.

À la fin de cette étape, vous devez savoir ce qui doit être déplacé, quel modèle de migration utiliser, où sont les principaux risques de compatibilité et quelles contraintes de restauration ou d’exécution parallèle vous devez prendre en compte.

Dans cet article, vous allez apprendre à :

• Évaluez votre empreinte Synapse Spark.
• Choisissez entre lift-and-shift, modernisation par phases et mise en œuvre parallèle.
• Prenez en compte les contraintes de retour en arrière et de synchronisation.
• Passez en revue les principales différences de fonctionnalité et d’architecture entre Synapse Spark et Fabric Spark.

Évaluez l'empreinte de votre Synapse Spark

Azure Synapse Analytics englobe plusieurs types de charges de travail. Ce guide se concentre sur la migration de pools Spark, de notebooks, de définitions de travaux Spark, de bases de données de lac et de métadonnées Hive vers Microsoft Fabric. Pour obtenir des conseils sur la migration de pool SQL dédié, de pipeline, de Data Explorer et de sécurité, reportez-vous aux guides associés.

Exécuter l’outil d’évaluation Fabric

Avant de planifier votre migration, exécutez l’outil d’évaluation Fabric pour générer un rapport complet de votre espace de travail source Synapse. L’outil analyse votre espace de travail et agrège un résumé de tous les objets ( pools Spark, notebooks, définitions de travaux Spark, bases de données lake, services liés et leurs configurations) ce qui vous donne une image claire de l’étendue de migration.

1. Téléchargez l’outil. L’outil d’évaluation Fabric est disponible dans le référentiel GitHub de boîte à outils Microsoft fabric à microsoft/boîte à outils fabric.

2. Exécutez l’évaluation. Pointez l’outil sur votre espace de travail Azure Synapse. Il analyse tous les éléments spark et génère un rapport avec le nombre d’objets, les configurations, les dépendances et les problèmes de compatibilité potentiels.

3. Passez en revue le rapport. Utilisez la sortie d’évaluation pour comprendre l’étendue de votre migration : le nombre de notebooks, pools, SJD et bases de données à migrer, quels services liés sont en cours d’utilisation et quels bloqueurs potentiels existent (pools GPU, fonctionnalités non prises en charge, etc.).

Modèles de migration

Choisissez votre modèle de migration en fonction des contraintes organisationnelles, de la tolérance aux risques et de la chronologie.

Modèle de migration "lift-and-shift"

Migrez toutes les charges de travail Spark à la fois à l’aide du Assistant Migration avec des modifications minimales. Concentrez-vous sur faire fonctionner des blocs-notes et des tâches dans Fabric le plus rapidement possible : refactoriser uniquement ce qui cause des problèmes (services liés, chemins d’accès aux fichiers, API non prises en charge). Acceptez l’architecture actuelle as-is.

Utilisez lift-and-shift quand :

• Votre espace de travail Synapse va être décommissionné d'ici une date butoir et vous devez agir rapidement.
• Vos charges de travail Spark sont déjà bien conçues (Delta-first, code propre, peu de dépendances de service lié).
• L’empreinte de votre espace de travail est gérable pour une migration ponctuelle et votre équipe peut gérer l’effort de refactorisation dans un sprint unique.
• Les consommateurs en aval (Power BI, API) peuvent tolérer une brève fenêtre de basculement.

Modernisation par phases

Migrez les charges de travail de manière incrémentielle selon leur priorité, en réarchitecturant au fur et à mesure. Commencez par les charges de travail les plus importantes ou les plus risquées en premier. À mesure que vous migrez chaque lot, consolidez les pools Spark dans un nombre réduit d'environnements, adoptez les meilleures pratiques Lakehouse (Delta-first, V-Order pour les utilisateurs de la BI), activez NEE et remaniez pour Direct Lake.

Utilisez la modernisation par phases lorsque :

• Vous disposez d’un environnement Synapse volumineux ou complexe avec plusieurs équipes et différentes charges de travail qui ne peuvent pas être migrées en une seule fois.
• Votre architecture actuelle présente une dette technique que vous souhaitez traiter (formats non Delta, dépendances de point de montage, pools Spark étendus).
• Vous disposez d’une flexibilité sur la chronologie et souhaitez améliorer les performances et l’efficacité des coûts pendant la migration.
• Différentes charges de travail ont différents propriétaires et nécessitent des planifications de migration indépendantes.

Modèle d’exécution parallèle

Exécutez les deux environnements simultanément pendant la transition. Acheminer les nouvelles charges de travail Spark vers Fabric pendant que les charges de travail héritées continuent sur Synapse. Validez les charges de travail migrées en effectuant une comparaison directe des résultats avant le transfert. Désaffecter progressivement Synapse au fur et à mesure que la confiance se développe.

Utilisez une exécution parallèle quand :

• Vos charges de travail ont des accords SLA stricts ou des exigences réglementaires qui nécessitent une validation étendue avant la transition.
• Vous devez prouver que la performance de Fabric répond ou dépasse celle de Synapse avant que les parties prenantes n'approuvent le démantèlement.
• Vos consommateurs en aval (tableaux de bord, API, modèles ML) ne peuvent tolérer aucune différence pendant la transition.
• Vous migrez des pipelines de production où des résultats incorrects ont un effet commercial élevé (rapports financiers, conformité).

L’exécution parallèle introduit un problème de synchronisation des données que vous devez concevoir à l’avance. Choisissez l’un des modèles suivants :

• Couche de stockage partagé : Faire que Synapse et Fabric lisent et écrivent dans le même stockage ADLS Gen2, via les raccourcis OneLake. Cela conserve les deux plateformes sur les mêmes fichiers Delta, mais vous devez empêcher les conflits d’écriture en garantissant qu’une seule plateforme écrit dans une table donnée à la fois.
• Écrire une fois, lire les deux : Gardez Synapse comme principal rédacteur pendant la transition et laissez Fabric accéder aux mêmes données à travers des raccourcis. Après avoir validé les notebooks migrés dans Fabric, basculez le chemin en écriture vers Fabric et configurez Synapse comme consommateur en lecture seule jusqu’à ce que Synapse soit désactivé. Il s’agit de l’option la plus sûre pour la plupart des migrations.
• Double écriture : Évitez d’exécuter la même valeur ETL dans les deux environnements en même temps, sauf si vous disposez déjà d’outils de comparaison et de rapprochement automatisés. L’écriture double tend à créer une divergence, une duplication et une surcharge opérationnelle.

L’exécution parallèle affecte également la gestion des modifications. Bien que Synapse reste l'environnement de développement actif, tout notebook, définition de travail Spark, configuration du pool Spark ou modifications de schéma de base de données lake effectuées dans Synapse ne sont pas répercutées automatiquement dans Fabric. Vous devez migrer à nouveau les ressources affectées afin que les deux environnements restent alignés.

• Modifications du code du notebook : réexécutez l'assistant de migration Spark ou réexportez et réimportez manuellement les blocs-notes mis à jour. Réappliquez toutes les refactorisations de code spécifiques à Fabric, notamment notebookutils, les mises à jour du chemin d’accès aux fichiers et les secrets Key Vault.
• Modifications des définitions de tâche Spark : Re-migrez à travers le Assistant Migration ou recréez manuellement les définitions de tâche Spark mises à jour dans Fabric.
• Modifications de configuration de Spark pool : Mettez à jour l’environnement Fabric correspondant pour qu’il corresponde à la taille de nœud révisée, aux paramètres de mise à l’échelle automatique ainsi qu'aux bibliothèques.
• Lake database schema changes : réexécutez les notebooks d’exportation/importation HMS, ou créez ou modifiez manuellement les tables affectées dans la Fabric lakehouse.

Pour réduire la surcharge de re-migration, établissez un gel des modifications côté Synapse une fois la migration commencée. Si les modifications sont inévitables, conservez un journal des modifications pour pouvoir les relire dans Fabric avant le basculement.

Considérations de retour en arrière

La migration synapse-à-Fabric est une opération de copie : elle ne modifie pas ou ne supprime pas votre espace de travail Synapse source. Vos pools Spark, blocs-notes et données d’origine restent intacts tout au long du processus. Cela rend la réversion facile :

• Si les résultats de la migration ne sont pas satisfaisants, continuez à utiliser votre espace de travail Synapse existant. Aucune modification n’a besoin d’être rétablie.
• Supprimez les artefacts de Fabric migrés (notebooks, environnements, définitions de travaux Spark) et réessayez après avoir résolu les problèmes.
• Les raccourcis OneLake pointent vers votre stockage ADLS Gen2 existant . La suppression de raccourcis n’affecte pas les données sous-jacentes.
• Ne désaffectez pas votre espace de travail Synapse tant que toutes les charges de travail migrées ne sont pas validées dans Fabric et que les consommateurs en aval sont redirigés à nouveau.

Parité des caractéristiques et différences clés

Comprendre les différences architecturales entre Synapse et Fabric est essentiel pour la planification. Les tableaux suivants mettent en évidence les principales différences dans l’architecture de calcul et les fonctionnalités Spark.

Pour obtenir la comparaison complète, consultez Compare Fabric et Azure Synapse Spark : Différences clés.

Calcul et architecture

Spark : Synapse Spark et Fabric Spark

Contenu connexe

• 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