Migration planification : Pools SQL dédiés Azure Synapse Analytics vers Fabric Data Warehouse

2025-04-04

S'applique à :✅ Entrepôt dans Microsoft Fabric

Cet article détaille la stratégie, les considérations et les méthodes de migration de l’entrepôt de données dans des pools SQL dédiés Azure Synapse Analytics vers Microsoft Fabric Warehouse.

Conseil

Une expérience automatisée pour la migration à partir de pools SQL dédiés Azure Synapse Analytics est disponible à l’aide de l’assistant de migration Fabric pour Data Warehouse. Cet article contient des informations stratégiques et de planification importantes.

Présentation de la migration

Microsoft a présenté Microsoft Fabric, une solution d’analyse SaaS tout-en-un pour les entreprises, qui offre une suite complète de services : Fabrique de données, Ingénieurs de données, Entrepôt de données, Sciences des données, Informations en temps réel et Power BI.

Cet article se concentre sur les options de migration de schéma (DDL), de migration de code de base de données (DML) et de migration des données. Microsoft propose plusieurs options et, ici, nous abordons chacune d’elles dans le détail afin de vous donner des conseils sur celles que vous avez intérêt à considérer pour votre scénario. Cet article utilise le point de référence du secteur TPC-DS pour les tests d’illustration et de performances. Votre résultat réel peut varier en fonction de nombreux facteurs, notamment du ou des types de données, de la largeur des tables, de la latence de la source de données, etc.

Préparation de la migration

Planifiez soigneusement votre projet de migration avant de démarrer et vérifiez que votre schéma, votre code et vos données sont compatibles avec Fabric Warehouse. Il existe certaines limitations à prendre en compte. Quantifiez le travail de refactorisation des éléments incompatibles, ainsi que toutes les autres ressources nécessaires avant toute livraison de la migration.

Un autre objectif clé de la planification consiste à ajuster votre conception pour vérifier que votre solution tire pleinement parti des performances de requêtes élevées offertes par Fabric Warehouse. Le développement d’entrepôts de données prenant en charge la mise à l’échelle introduit des modèles uniques de conception, ce qui signifie que les approches traditionnelles ne sont pas toujours les mieux indiquées. Passez en revue les recommandations sur les performances de Fabric Warehouse, car même si certains ajustements de la conception peuvent s’effectuer après la migration, l’apport de modifications à un stade plus précoce du processus vous économisera du temps et des efforts. La migration d’une technologie/d’un environnement vers une/un autre constitue toujours un effort majeur.

Le diagramme suivant illustre le cycle de vie de la migration en listant ses principaux piliers, à savoir Évaluer, Planifier et concevoir, Migrer, Superviser et gouverner, Optimiser et moderniser, ainsi que les tâches associées à chaque pilier afin de planifier et préparer une migration fluide.

Runbook pour la migration

Considérez les activités suivantes comme un runbook de planification pour votre migration depuis des pools SQL dédiés Synapse vers Fabric Warehouse.

Évaluer
1. Identifier les objectifs et les motivations. Établir les résultats précis souhaités.
2. Découvrir, évaluer l’architecture existante et en définir la base de référence.
3. Identifier les parties prenantes et commanditaires clés.
4. Définir l’étendue de ce qui doit être migré.
  1. Commencer avec une petite migration simple, préparer plusieurs petites migrations.
  2. Commencer à superviser et documenter toutes les étapes du processus.
  3. Créez un inventaire des données et processus pour la migration.
  4. Définissez les modifications de modèle de données (le cas échéant).
  5. Configurer l’espace de travail Fabric.
5. Quel est votre ensemble de compétences/Quelles sont vos préférences ?
  1. Automatisez autant que possible.
  2. Utiliser des outils et fonctionnalités Azure intégrés pour réduire l’effort de migration.
6. Formez le personnel à un stade précoce sur la nouvelle plateforme.
  1. Identifier les besoins de mise à jour des compétences et les ressources de formation, comme Microsoft Learn.
Planifier et concevoir
1. Définir l’architecture souhaitée.
2. Sélectionnez la méthode/les outils de migration pour effectuer les tâches suivantes :
  1. Extraction de données à partir de la source.
  2. Conversion de schéma (DDL), y compris de métadonnées pour les tables et les vues.
  3. Ingestion de données, y compris de données historiques.
    1. Si nécessaire, remanier le modèle de données, en exploitant les performances et la scalabilité de la nouvelle plateforme.
  4. Migration de code de base de données (DML).
    1. Migrez ou refactorisez les procédures stockées et les processus métier.
3. Dresser l’inventaire des fonctionnalités de sécurité et des autorisations d’objet, puis les extraire de la source.
4. Concevoir et envisager de remplacer/modifier les processus ETL/ELT existants pour la charge incrémentielle.
  1. Créer des processus ETL/ELT parallèles dans le nouvel environnement.
5. Préparer un plan de migration détaillé.
  1. Mapper l’état actuel au nouvel état souhaité.
Migrer
1. Effectuer la migration du schéma, des données et du code.
  1. Extraction de données à partir de la source.
  2. Conversion de schéma (DDL)
  3. Ingestion des données
  4. Migration de code de base de données (DML).
2. Si nécessaire, mettez temporairement à l’échelle les ressources de pools SQL dédiés pour faciliter la migration.
3. Appliquer la sécurité et les autorisations.
4. Migrer les processus ETL/ELT existants pour la charge incrémentielle.
  1. Migrer ou refactoriser les processus de charge incrémentielle ETL/ELT
  2. Tester et comparer les processus de charge incrémentielle parallèle.
5. Adapter le plan de migration détaillé si nécessaire.
Superviser et gouverner
1. Exécuter en parallèle, comparer à votre environnement source.
  1. Tester des applications, des plateformes décisionnelles et des outils de requête.
  2. Évaluez et optimisez les performances des requêtes.
  3. Superviser et gérer les coûts, la sécurité et les performances.
2. Évaluation de benchmark et de gouvernance.
Optimiser et moderniser
1. Une fois que l’entreprise est prête, passer des applications et des plateformes de création de rapports principales à Fabric.
  1. Effectuer un scale-up/down des ressources à mesure que la charge de travail passe d’Azure Synapse Analytics à Microsoft Fabric.
  2. Créer un modèle reproductible à partir de l’expérience acquise pour les migrations futures. Itérer.
  3. Identifier les opportunités d’optimisation des coûts, de sécurité, de scalabilité et d’excellence opérationnelle
  4. Identifier les opportunités de modernisation de votre patrimoine de données à l’aide des dernières fonctionnalités Fabric.

« Lift-and-shift » ou modernisation ?

En règle générale, il existe deux types de scénarios de migration, quel que soit l’objectif et l’étendue de la migration planifiée : le lift-and-shift en l’état ou une approche par phases qui incorpore les modifications d’architecture et de code.

Opération lift-and-shift

Dans une migration lift-and-shift, un modèle de données existant est migré avec des modifications mineures apportées au nouvel entrepôt Fabric. Cette approche réduit les risques et la durée de la migration en diminuant le nouveau travail nécessaire pour profiter pleinement des avantages de la migration.

La migration lift-and-shift est adaptée à ces scénarios :

Vous avez un environnement existant qui compte un petit nombre de datamarts à migrer.
Vous avez un environnement existant avec des données qui se trouvent déjà dans un schéma en étoile ou en flocon bien conçu.
Vous avez des contraintes de délai et de coût pour passer à Fabric Warehouse.

En résumé, cette approche fonctionne bien pour les charges de travail optimisées avec votre environnement de pools SQL dédiés Synapse actuel et elle ne nécessite donc pas de modifications majeures dans Fabric.

Moderniser dans le cadre d’une approche par phases avec des modifications architecturales

Si un entrepôt de données hérité a évolué sur une longue période, vous devrez peut-être le reconcevoir pour maintenir les niveaux de performances requis.

Vous pouvez également avoir envie de reconcevoir l’architecture pour tirer parti des nouveaux moteurs et fonctionnalités disponibles dans l’espace de travail Fabric.

Différences de conception : pools SQL dédiés Synapse et Fabric Warehouse

Tenez compte des différences suivantes entre l’entrepôt de données Azure Synapse et Microsoft Fabric, en comparant les pools SQL dédiés à Fabric Warehouse.

Considérations relatives aux tables

Lorsque vous migrez des tables entre différents environnements, seules les données brutes et les métadonnées sont généralement migrées physiquement. Les autres éléments de base de données du système source, tels que les index, ne sont généralement pas migrés, car ils peuvent être inutiles ou implémentés différemment dans le nouvel environnement.

Les optimisations des performances dans l’environnement source, comme les index, indiquent où vous pouvez ajouter une optimisation des performances dans un nouvel environnement, mais maintenant Fabric gère tout cela automatiquement.

Considérations relatives à T-SQL

Il existe plusieurs différences de syntaxe du langage de manipulation de données (DML) à connaître. Reportez-vous à Surface d’exposition T-SQL dans Microsoft Fabric. Envisagez également d’effectuer une évaluation de code lors du choix des méthodes de migration pour le code de base de données (DML).

Selon les différences de parité au moment de la migration, vous devrez peut-être réécrire certaines parties de votre code DML T-SQL.

Différences de mappage des types de données

Il existe plusieurs différences de types de données dans Fabric Warehouse. Pour plus d’informations, consultez Types de données dans Microsoft Fabric.

Le tableau suivant indique le mappage des types de données pris en charge entre des pools SQL dédiés Synapse et Fabric Warehouse.

Pools SQL dédiés Synapse	Fabric Warehouse
`money`	`decimal(19,4)`
`smallmoney`	`decimal(10,4)`
`smalldatetime`	`datetime2`
`datetime`	`datetime2`
`nchar`	`char`
`nvarchar`	`varchar`
`tinyint`	`smallint`
`binary`	`varbinary`
`datetimeoffset`*	`datetime2`

* Datetime2 ne stocke pas les informations de décalage de fuseau horaire supplémentaires qui sont stockées dans. Étant donné que le type de données datetimeoffset n'est actuellement pas pris en charge dans Fabric Warehouse, les données de décalage de fuseau horaire doivent être extraites dans une colonne distincte.

Conseil

Prêt à migrer ?

Pour démarrer une expérience de migration automatisée, consultez Assistant de migration Fabric pour Data Warehouse.

Pour plus d'étapes et de détails sur la migration manuelle, consultez Les méthodes de Migration pourPools SQL dédiés Azure Synapse Analytics à Fabric Data Warehouse.