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

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

Cet article décrit des stratégies, des considérations et des méthodes pour migrer de Azure Synapse Analytics pools SQL dédiés à Microsoft Fabric Data Warehouse.

Conseil / Astuce

Utilisez le Fabric Assistant Migration pour Data Warehouse pour une expérience de migration automatisée depuis les pools SQL dédiés d’Azure Synapse Analytics. Cet article contient des informations stratégiques et de planification importantes.

Présentation de la migration

Microsoft Fabric est une solution d’analyse SaaS tout-en-un pour les entreprises. Elle propose une gamme complète de services, incluant Data Factory, Data Engineering, Data Warehousing, Data Science, Real-Time Intelligence et Power BI.

Cet article décrit les options pour le schéma (DDL), le code de base de données (DML) et la migration des données, et vous aide à choisir une option pour votre scénario. Il utilise la référence de l’industrie TPC-DS pour l’illustration et les tests de performance. Vos résultats peuvent varier en fonction de facteurs tels que les types de données, la largeur de la table et la latence source.

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. Considérez les limites. Quantifiez le travail nécessaire pour refactorer les éléments incompatibles et toute autre ressource nécessaire à la migration effectuée.

Un autre objectif clé de la planification est d’ajuster votre conception afin que votre solution tire pleinement parti de la performance Fabric Data Warehouse requête. 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. Examinez les consignes de performance. Bien que vous puissiez apporter quelques ajustements de conception après la migration, faire des modifications plus tôt permet d’économiser du temps et des efforts. La migration d’une technologie ou d’un environnement à un autre est toujours un effort majeur.

Le schéma suivant montre le cycle de vie de la migration et les tâches associées à ses cinq piliers : Évaluer et évaluer, Planifier et concevoir, Migrer, Surveiller et gouverner, ainsi qu’Optimiser et moderniser.

Schéma du cycle de vie de la migration, incluant Évaluer et évaluer, Planifier et Concevoir, Migrer, Surveiller et Gouverner, ainsi qu’Optimiser et Moderniser.

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écouvrez, évaluez et définissez l’état de référence de l’architecture existante.
    3. Identifier les parties prenantes et commanditaires clés.
    4. Définissez le périmètre de ce qui doit être migré.
      1. Commencez petit et simple, et préparez-vous à plusieurs petites migrations.
      2. Commencer à superviser et documenter toutes les étapes du processus.
      3. Constituez un inventaire des données et des processus pour la migration.
      4. Définissez les changements du modèle de données, s’il y en a.
      5. Installez l’espace de travail Fabric.
    5. Évaluez les compétences et les préférences de votre équipe.
      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 les méthodes et outils pour la migration afin d’accomplir les tâches suivantes :
      1. Extraction de données à partir de la source.
      2. Conversion de schéma (DDL), incluant les métadonnées pour les tables et les vues.
      3. Ingestion de données, y compris de données historiques.
        1. Si nécessaire, réingéniez le modèle de données en utilisant de nouvelles performances et évolutivités de la 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 prévoir remplacer ou modifier les processus ETL/ELT existants pour une charge incrémentale.
      1. Créer des processus ETL/ELT parallèles dans le nouvel environnement.
    5. Préparer un plan de migration détaillé.
      1. Faites correspondre l’état actuel à l’état souhaité.
  3. Émigrer
    1. Effectuer la migration de schémas, de données et de 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émentale parallèles.
    5. Adapter le plan de migration détaillé au besoin.
  4. Superviser et gouverner
    1. Exécutez en parallèle et comparez avec 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. Effectuez un benchmark et une évaluation de 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. Augmentez ou diminuez les ressources au fur et à 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. Identifiez des 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.

Soulever et déplacer ou moderniser ?

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 le cadre d’une migration de type lift-and-shift, vous migrez un modèle de données existant avec des modifications mineures vers le nouveau Fabric Data Warehouse. 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 des charges de travail optimisées pour votre environnement SQL dédié actuel Azure Synapse et ne nécessitant pas de changements majeurs dans Fabric.

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

Si un entrepôt de données hérité évolue sur une longue période, il se peut que vous deviez le réingénier pour maintenir les niveaux de performance requis.

Vous pourriez aussi vouloir repenser 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. En général, on ne migre pas d’autres éléments de base de données depuis le système source, comme les index, car ils peuvent être inutiles ou implémentés différemment dans le nouvel environnement.

Les optimisations de performance dans l’environnement source, comme les indices, indiquent où vous pourriez avoir besoin d’optimisation dans un nouvel environnement. Fabric gère ces optimisations automatiquement.

Considérations relatives à T-SQL

Il existe plusieurs différences de syntaxe selon le langage de manipulation de données (DML) à prendre en compte. Examinez la surface T-SQL dans Fabric Data Warehouse et effectuez une évaluation du code lorsque vous choisissez une méthode de migration du code de la base de données.

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

Fabric Data Warehouse présente plusieurs différences de type de données par rapport à Azure Synapse Analytics pools SQL dédiés. Pour plus d’informations, consultez Types de données dans Microsoft Fabric.

Le tableau suivant montre la correspondance des types de données pris en charge depuis Azure Synapse pools SQL dédiés vers Fabric Data Warehouse.

Pools SQL dédiés Synapse Entrepôt de données Fabric
money décimal(19,4)
smallmoney décimal(10,4)
smalldatetime datetime2
datetime datetime2
nchar char
nvarchar varchar
tinyint smallint
binary varbinary
Datetimeoffset* datetime2

* Datetime2 ne stocke pas les informations supplémentaires relatives au décalage de fuseau horaire, contrairement à datetimeoffset. Comme Fabric Data Warehouse ne prend pas actuellement en charge le type de données datetimeoffset, vous devez extraire les données de décalage de fuseau horaire dans une colonne séparée.

Conseil / Astuce

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 manuelles de migration et des détails, voir Méthodes de migration pour Azure Synapse Analytics pools SQL dédiés à Fabric Data Warehouse.

Contenu connexe

  • Last updated on