Planification de la migration : migration des pools SQL dédiés d'Azure Synapse Analytics vers le Data Warehouse Fabric.

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’entreposage de données dans des pools SQL dédiés Azure Synapse Analytics vers Microsoft Fabric Data Warehouse.

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 benchmark industriel TPC-DS pour l'illustration et les tests de performance. 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 commencer et assurez-vous que votre schéma, votre code et vos données sont compatibles avec Fabric Data 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 est d’ajuster votre conception pour vous assurer que votre solution tire pleinement parti des performances de requête élevées que Fabric Data Warehouse est conçu pour fournir. 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 en matière de performances, car bien que certains ajustements de conception puissent être effectués après la migration, les modifications apportées plus tôt dans le processus vous permettront de gagner 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.

Guide d'opérations pour la migration

Tenez compte des activités suivantes en tant que runbook de planification pour votre migration à partir de pools SQL dédiés Synapse vers Fabric Data Warehouse.

1. É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.
2. 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. Faire correspondre l’état actuel à l’état souhaité.
3. 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, augmentez temporairement les ressources des pools SQL dédiés pour faciliter la migration.
   3. Appliquer la sécurité et les autorisations.
   4. Migrer les processus existants d'ETL/ELT pour une 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.
4. 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. Repère et évaluation de la gouvernance.
5. 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 de données 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 avec un petit nombre d’entrepôts à 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 subissez une pression temporelle et financière pour passer à Fabric Data Warehouse.

En résumé, cette approche fonctionne bien pour les charges de travail optimisées avec votre environnement de pools SQL dédiés Azure Synapse actuel, et 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 Data Warehouse

Tenez compte des différences d’entreposage de données Azure Synapse et Microsoft Fabric suivantes, en comparant les pools SQL dédiés à Fabric Data 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 à la surface T-SQL dans Fabric Data Warehouse. 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 type de données dans Fabric Data Warehouse. Pour plus d’informations, consultez Types de données dans Microsoft Fabric.

Le tableau suivant fournit le mappage des types de données pris en charge à partir de pools SQL dédiés Synapse à Fabric Data Warehouse.

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

Contenu connexe

• Créer un entrepôt dans Microsoft Fabric
• Instructions sur les performances de l’entrepôt de données Fabric
• Sécurité pour l'entreposage de données dans Microsoft Fabric
• Blog : Cartographie des pools SQL dédiés Azure Synapse vers le calcul du Fabric Data Warehouse
• Vue d’ensemble de la migration de Microsoft Fabric