Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
S’applique à :✅Entrepôt dans Microsoft Fabric
Cet article détaille la stratégie, les considérations et les méthodes pour migrer les entrepôts de données de SQL Server vers Microsoft Fabric Data Warehouse.
Conseil / Astuce
Une expérience automatisée de migration depuis SQL Server est disponible en utilisant le Fabric Assistant Migration pour Data Warehouse. 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 qui propose une suite 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 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. Examinez les consignes de performance. Bien que certains ajustements de conception puissent être faits après la migration, faire des modifications plus tôt dans le processus vous fera gagner du temps et des efforts. La migration d’une technologie ou d’un environnement à un autre est toujours un effort majeur.
Le diagramme suivant illustre le cycle de vie de la migration. Il énumère les piliers majeurs comprenant : Évaluer et évaluer, Planifier et concevoir, Migrer, Surveiller et Gouverner, ainsi qu’Optimiser et Moderniser, avec les tâches associées dans chaque pilier pour planifier et préparer une migration fluide.
Guide d'opérations pour la migration
Considérez les activités suivantes comme guide de planification pour votre migration de SQL Server à Fabric Data Warehouse.
-
Évaluer
- Identifier les objectifs et les motivations. Établir les résultats précis souhaités.
- Découvrez, évaluez et définissez l’état de référence de l’architecture existante.
- Identifier les parties prenantes et commanditaires clés.
- Définissez le périmètre de ce qui doit être migré.
- Commencez petit et simple, et préparez-vous à plusieurs petites migrations.
- Commencer à superviser et documenter toutes les étapes du processus.
- Constituez un inventaire des données et des processus pour la migration.
- Définissez les changements du modèle de données, s’il y en a.
- Installez l’espace de travail Fabric.
- Évaluez les compétences et les préférences de votre équipe.
- Automatisez autant que possible.
- Utilisez des outils et fonctionnalités intégrés pour réduire l’effort de migration.
- Formez le personnel à un stade précoce sur la nouvelle plateforme.
- Identifier les besoins de mise à jour des compétences et les ressources de formation, comme Microsoft Learn.
-
Planifier et concevoir
- Définir l’architecture souhaitée.
- Sélectionnez les méthodes et outils pour la migration afin d’accomplir les tâches suivantes :
- Extraire les données de la source.
- Convertir le schéma (DDL), y compris les métadonnées pour les tables et les vues.
- Ingérer les données, y compris les données historiques.
- Si nécessaire, réingéniez le modèle de données en utilisant les performances et la scalabilité de la nouvelle plateforme.
- Migrer le code de la base de données (DML).
- Migrez ou refactorisez les procédures stockées et les processus métier.
- Dresser l’inventaire des fonctionnalités de sécurité et des autorisations d’objet, puis les extraire de la source.
- Concevoir et prévoir remplacer ou modifier les processus ETL ou ELT existants pour des charges incrémentales.
- Créez des processus ETL ou ELT parallèles dans le nouvel environnement.
- Préparer un plan de migration détaillé.
- Mappe l’état actuel avec le nouvel état désiré.
-
Émigrer
- Migrez le schéma, les données et le code.
- Extraire les données de la source.
- Convertir le schéma (DDL).
- Ingérer des données.
- Migrer le code de la base de données (DML).
- Si nécessaire, mettez temporairement à l’échelle les ressources de SQL Server pour augmenter la vitesse de migration.
- Appliquer la sécurité et les autorisations.
- Migrer les processus ETL ou ELT existants vers un chargement incrémental.
- Migrer ou refactoriser les processus de charge incrémentale ETL ou ELT.
- Tester et comparer les processus de charge incrémentale parallèles.
- Adapter le plan de migration détaillé au besoin.
- Migrez le schéma, les données et le code.
-
Superviser et gouverner
- Exécutez en parallèle et comparez avec votre environnement source.
- Tester des applications, des plateformes décisionnelles et des outils de requête.
- Évaluez et optimisez les performances des requêtes.
- Superviser et gérer les coûts, la sécurité et les performances.
- Effectuez un benchmark et une évaluation de gouvernance.
- Exécutez en parallèle et comparez avec votre environnement source.
-
Optimiser et moderniser
- Une fois que l’entreprise est prête, passer des applications et des plateformes de création de rapports principales à Fabric.
- Adaptez les ressources à mesure que la charge de travail est transférée de SQL Server vers Microsoft Fabric.
- Créer un modèle reproductible à partir de l’expérience acquise pour les migrations futures. Itérer.
- Identifiez des opportunités d’optimisation des coûts, de sécurité, de scalabilité et d’excellence opérationnelle.
- Identifier les opportunités de modernisation de votre patrimoine de données à l’aide des dernières fonctionnalités Fabric.
- Une fois que l’entreprise est prête, passer des applications et des plateformes de création de rapports principales à 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 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 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 Server actuel et qui ne nécessitent donc 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 entre SQL Server et Fabric Data Warehouse
Considérez les différences suivantes entre SQL Server et 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 ajouter de l’optimisation de performance dans un nouvel environnement, mais Fabric s’en occupe automatiquement pour vous.
Considérations relatives à T-SQL
Soyez conscient de plusieurs différences de syntaxe avec le langage de manipulation de données (DML). Reportez-vous à la surface T-SQL dans Fabric Data Warehouse. Considérez également une évaluation du code lors du choix des méthodes de migration pour le code de la 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
Fabric Data Warehouse présente plusieurs différences de type de données par rapport aux autres plateformes Microsoft SQL. 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 du Moteur de base de données SQL vers Fabric Data Warehouse.
| SQL Server | Entrepôt de données Fabric |
|---|---|
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 relatives au décalage de fuseau horaire que datetimeoffset stocke. Comme ce datetimeoffset type de données n'est pas actuellement pris en charge dans Fabric Data Warehouse, extrais les données de décalage 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 de détails, voir Méthodes de migration pour SQL Server vers Fabric Data Warehouse.