Méthodes de migration pour les pools SQL dédiés Azure Synapse Analytics vers le Fabric Data Warehouse

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

Cet article décrit les méthodes pour migrer le data warehousing dans Azure Synapse Analytics pools SQL dédiés vers Microsoft Fabric Data Warehouse.

Conseil / Astuce

Pour plus d'informations sur la stratégie et la planification de votre migration, consultez La planification de Migration : Pools SQL dédiés Azure Synapse Analytics à Fabric Data Warehouse.

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. Le reste de cet article contient davantage d’étapes de migration manuelle.

Ce tableau récapitule les informations liées au schéma de données (DDL), au code de base de données (DML) et aux méthodes de migration de données. Nous développons plus en détail chaque scénario inclus dans cet article. Le lien correspondant figure dans la colonne Option.

Numéro d’option	Choix	Ce qu'il fait	Compétence/Préférence	Scénario
1	Usine de données	Conversion de schéma (DDL) Extraction de données Ingestion des données	ADF/Pipeline	Migration tout-en-un simplifiée d’un seul schéma (DDL) et de données. Recommandé pour les tables de dimension.
2	Usine de données avec partition	Conversion de schéma (DDL) Extraction de données Ingestion des données	ADF/Pipeline	Utilisation d'options de partitionnement pour augmenter le parallélisme de lecture/écriture offrant un débit dix fois supérieur à celui de l'option 1, recommandée pour les tables de faits.
3	Data Factory avec code accéléré	Conversion de schéma (DDL)	ADF/Pipeline	Convertissez et migrez d’abord le schéma (DDL), puis utilisez CETAS pour extraire et COPY/Data Factory pour ingérer des données afin d’obtenir des performances d’ingestion globales optimales.
4	Code accéléré de procédures stockées	Conversion de schéma (DDL) Extraction de données Évaluation du code	T-SQL	Utilisateur SQL qui se sert de l’IDE avec un contrôle plus précis sur les tâches sur lesquelles il souhaite travailler. Utilisez COPY/Data Factory pour ingérer des données.
5	Extension de projet SQL Database pour Visual Studio Code	Conversion de schéma (DDL) Extraction de données Évaluation du code	Projet SQL	Projet SQL Database pour le déploiement avec intégration de l’option 4. Utilisez COPY ou Data Factory pour ingérer des données.
6	CRÉER UNE TABLE EXTERNE EN SÉLECTIONNANT (CETAS)	Extraction de données	T-SQL	Extraction de données rentable et hautement performante dans Azure Data Lake Storage (ADLS) Gen2. Utilisez COPY/Data Factory pour ingérer des données.
7	Migrer à l’aide de dbt	Conversion de schéma (DDL) Conversion de code de base de données (DML)	dbt	Les utilisateurs dbt existants peuvent utiliser l’adaptateur Fabric dbt pour convertir leurs DDL et DML. Vous devez ensuite migrer des données à l’aide d’autres options figurant dans ce tableau.

Choisir une charge de travail pour la migration initiale

Lorsque vous décidez par où commencer le pool SQL dédié Synapse pour Fabric Data Warehouse projet de migration, choisissez une zone de charge de travail où vous pouvez :

• Prouver la viabilité de la migration vers Fabric Data Warehouse en apportant rapidement les bénéfices du nouvel environnement. Commencez petit et simple, et préparez-vous à plusieurs petites migrations.
• Laisser à votre personnel technique interne le temps d’acquérir une expérience suffisante avec les processus et outils qu’il utilisera pour migrer vers d’autres zones.
• Créer un modèle pour les migrations futures spécifiques à l'environnement source Synapse et aux outils et processus en place pour aider.

Conseil / Astuce

Créer un inventaire des objets qui ont besoin d’être migrés et documenter le processus de migration du début à la fin pour qu’il puisse être répété pour d’autres charges de travail ou pools SQL dédiés.

Le volume de données migrées lors d’une migration initiale doit être suffisamment important pour démontrer les capacités et les avantages de l’environnement Fabric Data Warehouse, mais pas trop important pour démontrer rapidement la valeur. La valeur typique se situe dans la plage de 1 à 10 téraoctets.

Migration avec Fabric Data Factory

Dans cette section, nous décrivons les options en utilisant Data Factory destiné aux personnes qui travaillent avec peu de code/sans code et qui connaissent Azure Data Factory et Synapse Pipeline. Cette option d’interface utilisateur par glisser-déposer fournit une étape simple pour convertir le DDL et migrer les données.

Fabric Data Factory peut effectuer les tâches suivantes :

• Convertir le schéma (DDL) en Fabric Data Warehouse syntaxe.
• Créez le schéma (DDL) sur Fabric Data Warehouse.
• Migrez les données vers Fabric Data Warehouse.

Option numéro 1. Migration de schéma/données – Assistant Copy et activité Copy ForEach

Cette méthode utilise l’assistant Data Factory Copy pour se connecter au pool SQL dédié source, convertir la syntaxe DDL du pool dédié SQL en Fabric, et copier les données en Fabric Data Warehouse. Vous pouvez sélectionner une ou plusieurs tables cibles (pour le jeu de données TPC-DS, il y a 22 tables). Cela génère l’activité ForEach qui permet de parcourir en boucle la liste des tables sélectionnées dans l’interface utilisateur et de générer 22 threads d’activité Copy parallèles.

• 22 requêtes SELECT (une pour chaque table sélectionnée) ont été générées et exécutées dans le pool SQL dédié.
• Vérifiez que vous disposez de la classe de ressource et de la DWU appropriées pour permettre l’exécution des requêtes générées. Dans ce cas, vous avez besoin d’un minimum de DWU1000 avec staticrc10 pour permettre à un maximum de 32 requêtes de gérer 22 requêtes envoyées.
• Data Factory copie directement les données du pool SQL dédié vers Fabric Data Warehouse nécessite un staging. Le processus d’ingestion se compose de deux phases.
  • La première phase consiste à extraire les données du pool SQL dédié dans ADLS. Elle est appelée mise en lots.
  • La deuxième phase intègre les données issues de l’étape dans Fabric Data Warehouse. La plupart du temps dédié à l’ingestion des données a trait à la phase de mise en lots. En résumé, la mise en lots a un impact considérable sur le niveau de performance de l’ingestion.

Utilisation recommandée

L’utilisation de l’assistant de copie pour générer un ForEach offre une interface utilisateur simple pour convertir DDL et ingérer les tables sélectionnées du pool SQL dédié en Fabric Data Warehouse en une seule étape.

Toutefois, cette méthode n’est pas optimale avec le débit global. L’obligation d’utiliser une mise en lots, le besoin de paralléliser la lecture et l’écriture pour l’étape « Source vers mise en lots » constituent les principaux facteurs de la latence des performances. Il est recommandé d’utiliser cette option uniquement pour les tables de dimension.

Option 2. Migration DDL/Données - Pipeline utilisant l'option de partitionnement

Pour améliorer le débit pour charger des tables de faits plus volumineuses à l’aide du pipeline Fabric, il est recommandé d’utiliser l’activité de copie pour chaque table de faits avec l’option de partition. Celle-ci donne les meilleurs niveaux de performance avec l’activité Copy.

Vous avez la possibilité d’utiliser le partitionnement physique de la table source, le cas échéant. Si la table n'a pas de partitionnement physique, vous devez spécifier la colonne de partition et fournir des valeurs min/max pour utiliser le partitionnement dynamique. Dans la capture d’écran suivante, les options source du pipeline spécifient une plage dynamique de partitions basée sur la ws_sold_date_sk colonne.

Bien que l’utilisation de la partition puisse augmenter le débit lors de la phase de mise en scène, il existe des facteurs à considérer pour apporter les ajustements appropriés.

• Selon votre plage de partitions, tous les emplacements d’accès concurrentiel risquent d’être utilisés, car plus de 128 requêtes peuvent être générées sur le pool SQL dédié.
• Vous devez effectuer une mise à l’échelle vers DWU6000 au minimum pour permettre à toutes les requêtes d’être exécutées.
• Par exemple, pour la table web_sales TPC-DS, 163 requêtes ont été soumises au pool SQL dédié. Pour DWU6000, 128 requêtes ont été exécutées alors que 35 requêtes ont été mises en file d’attente.
• La partition dynamique sélectionne automatiquement une partition par intervalles. Dans ce cas, il s’agit d’une plage de 11 jours pour chaque requête SELECT envoyée au pool SQL dédié. Par exemple:

  WHERE [ws_sold_date_sk] > '2451069' AND [ws_sold_date_sk] <= '2451080')
  ...
  WHERE [ws_sold_date_sk] > '2451333' AND [ws_sold_date_sk] <= '2451344')
  

Utilisation recommandée

Pour des tables de faits, nous vous recommandons d’utiliser Data Factory avec l’option de partitionnement afin d’augmenter le débit.

Cependant, l’augmentation des lectures parallélisées nécessite que le pool SQL dédié soit mis à l’échelle vers des DWU plus élevés afin de permettre l’exécution des requêtes d’extraction. En tirant parti du partitionnement, le taux s’améliore dix fois par rapport à une option sans partition. Vous pouvez augmenter le DWU pour obtenir un débit supplémentaire via les ressources de calcul, mais le pool SQL dédié autorise un maximum de 128 requêtes actives.

Pour plus d'informations sur le mappage de DWU Synapse vers le calculateur Fabric, consultez Blog : Mappage des pools SQL dédiés d'Azure Synapse vers le calculateur Fabric Data Warehouse.

Option 3. Migration DDL – Activité Copy ForEach de l’Assistant Copie

Les deux options de migration des données précédentes sont intéressantes pour les bases de données plus petites. Si vous avez besoin d’un débit plus élevé, nous vous recommandons d’utiliser une autre option :

1. Extrayez les données du pool SQL dédié vers Azure Data Lake Storage (ADLS), ce qui atténue la surcharge de performance de l'étape.
2. Utilisez soit Data Factory, soit la commande COPY pour ingérer les données dans votre entrepôt.

Utilisation recommandée

Vous pouvez continuer à utiliser Data Factory pour convertir votre schéma (DDL). À l’aide de l’Assistant Copie, vous pouvez sélectionner la table spécifique ou Toutes les tables. Par nature, le schéma et les données sont migrées en une seule étape, en extrayant le schéma sans aucune ligne, à l’aide d’une condition false, TOP 0 dans l’instruction de requête.

L’exemple de code suivant couvre la migration de schéma (DDL) avec Data Factory.

Exemple de code : Migration de schéma (DDL) avec Data Factory

Vous pouvez utiliser Fabric Pipelines pour migrer facilement vos DDL (schémas) pour des objets de table depuis n’importe quelle source Azure SQL Database ou pool SQL dédié. Ce pipeline migre le schéma (DDL) des tables de pool SQL dédiées à la source vers Fabric Data Warehouse.

Conception de pipeline : paramètres

Ce pipeline accepte un paramètre SchemaName, qui vous permet de spécifier les schémas à migrer. Le schéma dbo est celui par défaut.

Dans le champ valeur par défaut, entrez la liste séparée par des virgules des schémas de table indiquant les schémas à migrer : 'dbo','tpch' pour fournir deux schémas, dbo et tpch.

Conception de pipeline : activité Recherche

Créez une activité LookUp et définissez la connexion pour qu’elle pointe vers votre base de données source.

Sous l’onglet Paramètres :

• Réglez Type de stockage de données sur Externe.

• Connection est votre pool SQL dédié à Azure Synapse. Le type de connexion correspond à Azure Synapse Analytics.

• Le paramètre Utiliser la requête est défini sur Requête.

• Le champ Requête doit être construit à l’aide d’une expression dynamique, permettant d’utiliser le paramètre SchemaName dans une requête qui renvoie une liste de tables sources cibles. Sélectionnez Requête, puis Ajouter du contenu dynamique.

  Cette expression au sein de l’activité LookUp génère une instruction SQL pour interroger les vues système afin de récupérer la liste des schémas et tables. Il fait référence au SchemaName paramètre permettant le filtrage sur les schémas SQL. La sortie correspondante est un tableau de schémas et tables SQL qui seront utilisés comme entrée dans l’activité ForEach.

  Utilisez le code suivant pour retourner la liste de toutes les tables utilisateur avec leur nom de schéma.

  @concat('
  SELECT s.name AS SchemaName,
  t.name  AS TableName
  FROM sys.tables AS t
  INNER JOIN sys.schemas AS s
  ON t.type = ''U''
  AND s.schema_id = t.schema_id
  AND s.name in (',coalesce(pipeline().parameters.SchemaName, 'dbo'),')
  ')
  

Conception de pipeline : boucle ForEach

Pour la boucle ForEach, configurez les options suivantes sous l’onglet Paramètres :

• Désactivez Séquentiel pour permettre l’exécution simultanée de plusieurs itérations.
• Définissez le paramètre Nombre de lots sur 50, en limitant le nombre maximal d’itérations simultanées.
• Le champ Éléments a besoin d’utiliser du contenu dynamique pour référencer la sortie de l’activité LookUp. Utilisez l’extrait de code suivant : @activity('Get List of Source Objects').output.value

Conception de pipeline : activité Copy au sein de la boucle ForEach

Au sein de l’activité ForEach, ajoutez une activité Copy. Cette méthode utilise le Dynamic Expression Language dans les pipelines pour construire un SELECT TOP 0 * FROM <TABLE> afin de migrer uniquement le schéma sans données dans un entrepôt.

Sous l’onglet Source :

• Réglez Type de stockage de données sur Externe.
• Connection est votre pool SQL dédié à Azure Synapse. Le type de connexion correspond à Azure Synapse Analytics.
• Définissez Utiliser la requête sur Requête.
• Dans le champ Requête, collez la requête de contenu dynamique et utilisez cette expression qui retourne zéro ligne, uniquement le schéma de table : @concat('SELECT TOP 0 * FROM ',item().SchemaName,'.',item().TableName)

Sous l’onglet Destination :

• Définissez Type de magasin de données sur Espace de travail.
• Le type de stockage de données Workspace est Data Warehouse et le Data Warehouse est défini comme l’entrepôt.
• Le schéma et le nom de la table de destination sont définis à l’aide du contenu dynamique.
  • Schéma fait référence au champ de l’itération en cours, SchemaName avec le extrait : @item().SchemaName
  • Table référençant TableName avec l’extrait de code : @item().TableName

Conception de pipeline : Récepteur

Pour Récepteur, pointez vers votre entrepôt et référencez le nom du schéma source et de la table.

Une fois ce pipeline exécuté, vous voyez votre entrepôt de données rempli avec chaque table de votre source, avec le schéma approprié.

Migration à l’aide de procédures stockées dans un pool SQL dédié Synapse

Cette option utilise des procédures stockées pour effectuer la migration Fabric.

Vous pouvez obtenir les exemples de code sur microsoft/fabric-migration sur GitHub.com. Ce code est partagé en open source. N’hésitez donc pas à apporter votre contribution pour soutenir la communauté.

Ce que peuvent faire les procédures stockées de migration :

• Convertir le schéma (DDL) en Fabric Data Warehouse syntaxe.
• Créez le schéma (DDL) sur Fabric Data Warehouse.
• Extraire des données du pool SQL dédié Synapse vers ADLS.
• Marquer la syntaxe Fabric non prise en charge pour les codes T-SQL (procédures stockées, fonctions, vues).

Utilisation recommandée

Il s’agit d’une excellente option pour ceux qui :

• connaissent bien T-SQL ;
• veulent utiliser un environnement de développement intégré comme SQL Server Management Studio (SSMS) ;
• veulent un contrôle plus précis sur les tâches sur lesquelles ils souhaitent travailler.

Vous pouvez exécuter la procédure stockée propre à la conversion de schéma (DDL), l’extraction de données ou l’évaluation de code T-SQL.

Pour la migration des données, vous devez utiliser soit COPY INTO Fabric Data Factory pour ingérer les données dans votre entrepôt.

Migration à l’aide de projets SQL Database

Microsoft Fabric Data Warehouse est pris en charge dans l’extension Projets SQL Database disponible dans Visual Studio Code.

Cette extension est disponible dans Visual Studio Code. Cette fonctionnalité permet des capacités de contrôle de source, de test de base de données et de validation de schéma.

Pour plus d’informations sur le contrôle de sources, voir Aperçu du développement et du déploiement.

Utilisation recommandée

Il s’agit d’une excellente option pour ceux qui préfèrent utiliser un projet SQL Database pour leur déploiement. Cette option intégrait essentiellement les procédures stockées de migration Fabric dans le projet SQL Database pour offrir une expérience de migration fluide.

Un projet SQL Database permet de :

• Convertir le schéma (DDL) en Fabric Data Warehouse syntaxe.
• Créez le schéma (DDL) sur Fabric Data Warehouse.
• Extraire des données du pool SQL dédié Synapse vers ADLS.
• Marquer la syntaxe non prise en charge pour les codes T-SQL (procédures stockées, fonctions, vues).

Pour la migration des données, vous utiliserez ensuite soit COPY INTO Data Factory pour ingérer les données dans votre entrepôt.

L’équipe CAT Microsoft Fabric a fourni un ensemble de scripts PowerShell pour gérer l’extraction, la création et le déploiement de schémas (DDL) et de code de base de données (DML) via un projet SQL Database. Pour obtenir une procédure pas à pas de l’utilisation du projet SQL Database avec nos scripts PowerShell, consultez microsoft/fabric-migration sur GitHub.com.

Pour plus d’informations sur les projets SQL Database, consultez Prise en main de l’extension Projets SQL Database et Génération d’un projet de base de données à partir de la ligne de commande.

Migration de données avec CETAS

La commande T-SQL CREATE EXTERNAL TABLE AS SELECT (CETAS) offre la méthode optimale la plus rentable pour extraire des données de pools SQL dédiés Synapse vers Azure Data Lake Storage (ADLS) Gen2.

Ce que la commande CETAS peut faire :

• Extraire des données dans ADLS.
  • Cette option exige que les utilisateurs créent le schéma (DDL) dans votre entrepôt avant d’ingérer les données. Considérez les options décrites dans cet article pour migrer le schéma (DDL).

Les avantages de cette option sont les suivants :

• Une seule requête par table est envoyée sur le pool SQL dédié Synapse source. Ainsi, tous les emplacements d’accès concurrentiel ne sont pas utilisés, ce qui ne bloque pas les ETL/requêtes de production du client simultanés.
• Aucune mise à l’échelle vers DWU6000 n’est nécessaire, car un seul emplacement d’accès concurrentiel est utilisé pour chaque table, si bien que les clients peuvent utiliser des DWU inférieures.
• L’extraction est exécutée en parallèle sur tous les nœuds de calcul, ce qui est essentiel pour l’amélioration des performances.

Utilisation recommandée

Utilisez CETAS pour extraire les données dans ADLS sous forme de fichiers Parquet. Les fichiers Parquet offrent l’avantage d’un stockage de données efficace avec une compression en colonnes qui nécessite moins de bande passante pour parcourir le réseau. De plus, étant donné que Fabric a stocké les données au format parquet Delta, l’ingestion de données sera 2,5 fois plus rapide que le format de fichier texte, en l’absence de surcharge due à la conversion au format Delta pendant l’ingestion.

Pour augmenter le débit CETAS :

• Ajoutez des opérations CETAS parallèles, ce qui augmente l’utilisation des emplacements d’accès concurrentiel, mais autorise un débit plus élevé.
• Mettez à l’échelle la DWU sur le pool SQL dédié Synapse.

Migration par le biais de dbt

Dans cette section, nous décrivons l’option dbt pour les clients qui utilisent déjà dbt dans leur environnement de pools SQL dédiés Synapse actuel.

Ce que peut faire dbt :

• Convertir le schéma (DDL) en Fabric Data Warehouse syntaxe.
• Créez le schéma (DDL) sur Fabric Data Warehouse.
• Convertir le code de base de données (DML) en syntaxe Fabric.

Le framework dbt génère les DDL et DML (scripts SQL) à la volée à chaque exécution. Avec des fichiers de modèle exprimés dans des instructions SELECT, les DDL/DML peuvent être traduits instantanément en n’importe quelle plateforme cible en modifiant le profil (chaîne de connexion) et le type d’adaptateur.

Utilisation recommandée

Le framework dbt est une approche de type « code first ». Les données doivent être migrées à l’aide des options listées dans ce document, comme CETAS ou COPY/Data Factory.

L’adaptateur DBT pour Microsoft Fabric Data Warehouse permet de migrer vers un entrepôt les projets DBT existants qui ciblaient différentes plateformes telles que les pools SQL dédiés Synapse, Snowflake, Databricks, Google Big Query ou Amazon Redshift vers un entrepôt avec un simple changement de configuration.

Pour débuter avec un projet dbt ciblant Fabric Data Warehouse, consultez le tutoriel : Configurez la dbt pour Fabric Data Warehouse. Ce document liste également une option permettant de se déplacer entre différents entrepôts/plateformes.

Ingestion de données dans Fabric Data Warehouse

Pour l’ingestion dans Fabric Data Warehouse, utilisez COPY INTO ou Fabric Data Factory, selon vos préférences. Les deux méthodes correspondent aux options recommandées les plus performantes, car leur débit est équivalent, compte tenu du prérequis qui implique que les fichiers sont déjà extraits dans Azure Data Lake Storage (ADLS) Gen2.

Plusieurs facteurs sont à prendre en compte pour pouvoir concevoir votre processus en vue de performances maximales :

• Avec Fabric, il n'y a aucune contention de ressources lors du chargement simultané de plusieurs tables d'ADLS vers Fabric Data Warehouse. Par conséquent, il n’y a aucune dégradation des performances lors du chargement de threads parallèles. Le débit d’ingestion maximal sera uniquement limité par la puissance de calcul de votre capacité Fabric.
• La gestion des charges de travail Fabric assure la séparation des ressources allouées à la charge et à la requête. Il n’existe aucune contention des ressources pendant l’exécution simultanée des requêtes et du chargement des données.

Contenu connexe

• Assistant de migration Fabric pour l'entrepôt de données
• 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