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

s’applique à :✅ Warehouse dans Microsoft Fabric

Cet article détaille les méthodes de migration de l’entreposage de données dans les pools SQL dédiés Azure Synapse Analytics vers Microsoft Fabric Warehouse.

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.

Choisir une charge de travail pour la migration initiale

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

• Prouver la viabilité de la migration vers Fabric Warehouse en tirant rapidement parti des avantages du nouvel environnement. Commencer avec une petite migration simple, préparer 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.

Le volume des données migrées dans une migration initiale doit être suffisamment important pour illustrer les fonctionnalités et les avantages de l’environnement Fabric Warehouse, mais pas trop non plus pour illustrer 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 syntaxe Fabric Warehouse.
• Créer le schéma (DDL) sur Fabric Warehouse.
• Migrez les données vers Fabric Warehouse.

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

Cette méthode utilise l’Assistant Copie Data Factory pour se connecter au pool SQL dédié source, convertir la syntaxe DDL du pool SQL dédié en Fabric et copier des données dans Fabric 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.
• La copie directe de données Data Factory à partir du pool SQL dédié vers Fabric Warehouse nécessite une mise en lots. 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 seconde phase consiste à ingérer les données à partir de la mise en lots dans l’entrepôt Fabric. 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 Copie pour générer un ForEach fournit une interface utilisateur simple pour convertir le DDL et ingérer les tables sélectionnées du pool SQL dédié vers Fabric 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.

Toutefois, les lectures parallélisées accrues nécessitent un pool SQL dédié pour effectuer une mise à l’échelle vers une DWU plus élevée afin de permettre l’exécution des requêtes d’extraction. En tirant parti du partitionnement, le taux est amélioré dix fois par rapport à une option sans partition. Vous pouvez augmenter la DWU pour obtenir un débit supplémentaire par le biais de ressources de calcul, mais le pool SQL dédié autorise un maximum de 128 requêtes actives.

Pour plus d’informations sur le mappage DWU Synapse vers Fabric, consultez Blog : Mappage de pools SQL dédiés Azure Synapse au calcul de l’entrepôt de données Fabric.

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 Data Factory ou la commande COPY pour ingérer les données dans Fabric Warehouse.

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 sur votre DDL (schémas) pour les objets de table à partir de n’importe quelle base de données Azure SQL source ou pool SQL dédié. Ce pipeline effectue la migration du schéma DDL des tables du pool SQL dédié source au Fabric 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 généré à l’aide d’une expression dynamique, ce qui permet au paramètre SchemaName d’être utilisé dans une requête qui retourne la liste des 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. Référence le paramètre SchemaName pour autoriser 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 langage d’expression dynamique dans les pipelines pour construire un SELECT TOP 0 * FROM <TABLE> qui permet de migrer uniquement le schéma, sans données, vers un entrepôt Fabric.

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 magasin de données Espace de travail correspond à Data Warehouse et Data Warehouse est défini sur Fabric Warehouse.
• Le schéma et le nom de la table de destination sont définis à l’aide du contenu dynamique.
  • Le schéma référence le champ de l’itération actuelle, SchemaName avec l’extrait de code : @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 syntaxe Fabric Warehouse.
• Créer le schéma (DDL) sur Fabric 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 COPY INTO ou Data Factory pour ingérer les données dans Fabric Warehouse.

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 code source pour les entrepôts dans Microsoft Fabric, notamment les pipelines d’intégration et de déploiement Git, consultez Contrôle de code source avec Warehouse.

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 syntaxe Fabric Warehouse.
• Créer le schéma (DDL) sur Fabric 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 utilisez alors COPY INTO ou Data Factory pour ingérer les données dans Fabric Warehouse.

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 Bien démarrer avec l’extension des projets SQL Database et Générer et publier un projet.

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 nécessite que les utilisateurs créent le schéma (DDL) sur Fabric Warehouse 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 syntaxe Fabric Warehouse.
• Créer le schéma (DDL) sur Fabric 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 l’entrepôt de données Microsoft Fabric permet aux projets DBT existants qui ciblaient différentes plateformes comme des pools SQL dédiés Synapse, Snowflake, Databricks, Google Big Query ou Amazon Redshift d’être migrés vers Fabric Warehouse avec une simple modification de configuration.

Pour bien démarrer avec un projet dbt ciblant Fabric Warehouse, consultez Tutoriel : Configurer dbt pour Fabric Data Warehouse. Ce document liste également une option permettant de se déplacer entre différents entrepôts/plateformes.

Ingestion des données dans Fabric Warehouse

Pour une ingestion dans Fabric 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’existe aucune contention des ressources lors du chargement de plusieurs tables depuis ADLS vers Fabric Warehouse simultanément. 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 : Mappage de pools SQL dédiés Azure Synapse aux ressources de calcul de l’entrepôt de données Fabric
• Vue d’ensemble de la migration de Microsoft Fabric