Planifier la migration d’un entrepôt de données

La migration d’un entrepôt de données est un défi pour toute entreprise. Pour opérer la migration correctement et éviter les mauvaises surprises et les coûts imprévus, vous devez analyser minutieusement ce défi, réduire les risques et planifier soigneusement votre migration afin de vous assurer que vous êtes aussi prêt que possible. Dans l’ensemble, votre plan doit couvrir les principales étapes du processus de migration de l’entrepôt de données de base et toutes les tâches qu’elles impliquent. Les principales étapes du processus sont les suivantes :

• Préparation pré-migration
• Stratégie et exécution de la migration
• Post-migration

Par exemple, la préparation comprend des aspects tels que la préparation de votre équipe en charge de la migration de l’entrepôt de données en termes de compétences et de connaissance de la technologie. Elle inclut également la mise en place d’un laboratoire de preuve de concept, la compréhension de la façon dont vous allez gérer les environnements de test et de production, l’obtention de l’habilitation pour migrer vos données et un système de production en dehors du pare-feu d’entreprise, ainsi que l’installation de logiciels de migration dans votre centre de données pour permettre la migration.

Pour que la migration de l’entrepôt de données se déroule sans problème, votre plan doit refléter une parfaite compréhension des aspects suivants :

• étude de cas, incluant son moteur d’activité, ses bénéfices et ses risques ;
• rôles et responsabilités de l’équipe de migration ;
• compétences et formation requises pour une migration réussie ;
• budget alloué pour la migration complète ;
• stratégie de migration ;
• façon de prévenir les risques liés au projet de migration afin d’éviter les retards ou remaniements ;
• système d’entrepôt de données existant, incluant son architecture, son schéma, ses volumes de données, ses flux de données, sa sécurité et ses dépendances opérationnelles ;
• différences entre votre SGBD existant dans l’entrepôt de données local et Azure Synapse, telles que les types de données, les fonctions SQL, la logique et d’autres considérations ;
• éléments à migrer et priorités ;
• tâches de migration, incluant leur approche, leur ordre et leur échéance ;
• manière dont vous comptez contrôler la migration ;
• manière dont vous comptez empêcher les interruptions des utilisateurs lorsque vous entreprendrez la migration ;
• ce que vous devez faire localement pour éviter les retards et permettre la migration ;
• outils permettant d’opérer une migration sécurisée des schémas, des données et du traitement ETL vers Azure ;
• changements de conception du modèle de données requis pendant et après la migration ;
• changements de technologie pré-migration ou post-migration, et manière de minimiser les remaniements ;
• dépréciation de technologie post-migration ;
• manière dont vous comptez implémenter les tests et l’assurance qualité pour prouver la réussite ;
• points de contrôle pour évaluer la progression et permettre de prendre des décisions ;
• plan d’urgence et points de restauration en cas de problème.

Pour acquérir cette compréhension, nous devons préparer et conduire des activités spécifiques avant le début de la migration. Voyons plus précisément ce que cela implique.

Préparation pré-migration

Plusieurs points doivent être abordés avant même de commencer la migration d’un entrepôt de données.

Rôles clés dans une équipe de migration d’entrepôt de données

Dans un projet de migration, les rôles clés sont les suivants :

• propriétaire de l’entreprise ;
• chef de projet (expérimenté en méthodologie agile, telle que Scrum) ;
• coordinateur de projet ;
• ingénieur cloud ;
• administrateur de base de données (SGBD existant de l’entrepôt de données et Azure Synapse) ;
• modélisateurs de données ;
• développeurs ETL ;
• spécialiste de la virtualisation des données (peut être un administrateur de bases de données) ;
• ingénieur de test ;
• analystes d’entreprise (pour aider à tester les requêtes, rapports et analyses de l’outil BI).

En outre, l’équipe a besoin du soutien de votre équipe d’infrastructure locale.

Compétences et formation pour préparer l’équipe à la migration

En ce qui concerne les compétences, dans le cadre de la migration d’un entrepôt de données, l’expertise est importante. Par conséquent, assurez-vous que les membres de votre équipe de migration sont dûment formés dans les domaines suivants : notions fondamentales du cloud Azure, Stockage Blob Azure, Azure Data Lake Storage, Azure Data Box, ExpressRoute, gestion des identités Azure, Azure Data Factory et Azure synapse. Vos modélisateurs de données auront probablement besoin d’optimiser vos modèles de données Microsoft Azure Synapse après la migration à partir de votre entrepôt de données existant.

Évaluation de votre entrepôt de données existant

Un autre volet de la préparation de la migration est la nécessité d’une évaluation complète de votre entrepôt de données existant afin de bien en comprendre l’architecture, les magasins de données, le schéma, la logique métier, les flux de données, les fonctionnalité de SGBD utilisées, le fonctionnement et les dépendances. Plus la compréhension est approfondie, mieux c’est. Une connaissance précise du fonctionnement du système permet de communiquer et de couvrir toutes les bases.

L’objectif de l’évaluation n’est pas seulement de garantir que l’équipe de migration dispose d’une compréhension approfondie de la configuration actuelle, mais aussi de comprendre les forces et les faiblesses de celle-ci. Le résultat d’une évaluation de votre entrepôt de données actuel peut donc avoir une incidence impact sur le choix de votre stratégie de migration : migration lift-and-shift ou plus conséquente. Par exemple, si une évaluation conclut que votre entrepôt de données est en fin de vie, il est évident que la stratégie à envisager est davantage une migration des données vers un entrepôt de données nouvellement conçu sur Azure Synapse, qu’une migration lift-and-shift.

Préparation locale à la migration des données

À côté de la préparation de votre équipe de migration pour votre environnement cible et l’évaluation de votre configuration actuelle, il est important de définir des éléments déplacés localement, car les entrepôts de données de production ont tendance à être fortement contrôlés par les procédures informatiques et les processus d’approbation. Afin d’éviter les retards, assurez-vous que l’infrastructure de votre centre de données et les équipes d’exploitation sont prêtes à migrer vos données, votre schéma, vos travaux ETL et autres éléments vers le cloud Azure. La migration des données peut se produire via :

• AzCopy vers le service Stockage Blob Azure ;
• Microsoft Azure ExpressRoute pour transférer les données compressées directement vers Azure ;
• Exportation de fichier vers Azure Data Box.

Les principaux facteurs qui déterminent le choix de ces options sont le volume des données (en téraoctets) et la vitesse du réseau (en Mbits/s). Un calcul est nécessaire pour déterminer le temps nécessaire à la migration des données via le réseau, en tenant compte du fait que les données peuvent être compressées dans votre entrepôt de données, puis décompressées lors de l’exportation. Cette situation peut ralentir le transfert de données. Recompressez les données avec Gzip lors de leur déplacement à l’aide de l’une des méthodes ci-dessus. La technologie Polybase est capable de traiter directement les données compressées avec Gzip. Des données volumineuses seront probablement migrées via Azure Data Box si leur déplacement prend trop de temps.

En outre, pour qu’Azure Data Factory puisse contrôler l’exécution des exportations des données de votre entrepôt de données existant à partir d’Azure, vous devez installer le logiciel du runtime d’intégration auto-hébergé dans votre centre de données pour permettre la migration. Compte tenu de ces exigences, si une approbation formelle est requise pour cette opération, un démarrage précoce des processus d’approbation appropriés permet d’éviter les retards en aval.

Préparation d’Azure pour la migration de schéma et de données

En termes de préparation côté Azure, l’importation de données doit être gérée via Microsoft Azure ExpressRoute ou Microsoft Azure Data Box. Les pipelines Azure Data Factory constituent un moyen idéal pour charger vos données dans le stockage Blob Azure, avant de les charger dans Azure Synapse à l’aide de la technologie PolyBase. Par conséquent, une préparation est nécessaire côté Azure pour développer un tel pipeline.

L’alternative consiste à utiliser votre outil ETL existant sur Azure s’il prend en charge Azure Synapse, ce qui implique de configurer l’outil sur Azure à partir de la Place de marché Azure, et de préparer un pipeline pour importer vos données et les charger dans le service Stockage Blob Azure.

Définition d’une stratégie de migration

Objectifs de la migration

Toute stratégie doit englober un ensemble d’objectifs ou de buts à définir pour indiquer son succès. Il est ensuite possible de désigner des cibles pour atteindre ces objectifs, ainsi que les personnes chargées de les atteindre. Le tableau ci-dessous présente des exemples d’objectifs de migration et de mesures correspondantes pour définir des cibles dans un projet de migration d’entrepôt de données cloud :

Types d’objectifs et exemples de métriques :

Améliorer les performances globales

• Performances de la migration des données
• Performances ETL
• Performances du chargement des données
• Performances des requêtes complexes
• Nombre d’utilisateurs simultanés

Exécuter à moindre coût

• Coût de calcul par charge de travail, par exemple, nombre d’heures de calcul x coût horaire pour les opérations suivantes :
  • création de rapports standard ;
  • requêtes ad hoc ;
  • traitement ELT par lot.
• Coût du stockage (intermédiaire, tables de production, index, espace temporaire)

Opérer avec des niveaux supérieurs de disponibilité et de service

• Contrats de niveau de service
• Haute disponibilité

Améliorer la productivité

• Automatisation de tâches, réduction du personnel administratif

Une migration réussie d’entrepôt de données peut donc être considérée comme un entrepôt de données qui s’exécute au moins aussi rapidement et à un coût moindre que le système hérité source de la migration. La désignation de propriétaires de ces objectifs a pour effet de créer des responsabilités en lien avec la poursuite de ceux-ci. Cela garantit également que le test dans un laboratoire de preuve de concept (tel que défini dans la section de ce guide relative à la diminution des risques) sera considéré comme réussi si les tests identifient les moyens par lesquels les objectifs peuvent être atteints.

Approche de migration

Il existe différentes options stratégiques pour la migration de votre entrepôt de données existant vers Azure Synapse :

• opérer une migration lift-and-shift de votre entrepôt de données existant en l’état ;
• simplifier votre entrepôt de données existant, puis le migrer ;
• remanier entièrement votre entrepôt de données sur Azure Synapse, puis migrer vos données.

Les résultats de l’évaluation de votre entrepôt de données existant doivent influencer de manière significative votre stratégie. Un bon résultat d’évaluation peut conduire à adopter une stratégie de migration lift-and-shift. Un résultat médiocre dû à une évaluation basse de l’agilité peut indiquer qu’une simplification est nécessaire avant la migration. Un mauvais résultat peut indiquer la nécessité d’un remaniement complet.

Une migration lift-and-shift laisse votre architecture telle quelle, dans une tentative de minimiser le travail de déplacement de votre système existant. Si votre outil ETL existant prend déjà en charge Azure Synapse, vous pouvez peut-être modifier la cible avec un minimum d’effort. Néanmoins, il y aura des différences sur le plan des types de tables, des types de données, des fonctions SQL, des vues, de la logique métier de la procédure stockée, etc. Ces différences et les moyens de les contourner sont détaillés dans les documents de niveau inférieur de cette série sur la migration.

La simplification de votre entrepôt de données existant avant la migration consiste à réduire la complexité pour faciliter la migration. Elle peut inclure les opérations suivantes :

• suppression ou archivage de tables inutilisées avant la migration afin d’éviter de migrer des données non utilisées ;
• conversion de mini-Data Warehouses physiques en mini-Data Warehouses virtuels à l’aide d’un logiciel de virtualisation de données afin de réduire ce que vous devez migrer. La conversion ayant également pour effets d’améliorer l’agilité et de réduire le coût total de possession, elle peut être considérée comme une modernisation effectuée au cours de la migration.

Vous pouvez aussi commencer par simplifier avant d’effectuer une migration lift-and-shift de ce qui reste.

Étendue de la migration

Quelle que soit la stratégie choisie, vous devez définir clairement l’étendue de la migration, ce qui sera migré, et si vous allez opérer la migration de manière incrémentielle ou en une fois. Une migration incrémentielle consiste, par exemple, à migrer vos mini-Data Warehouses avant votre entrepôt de données. Cette approche vous permet de vous concentrer sur des aspects de l’activité hautement prioritaires, tout en permettant à votre équipe d’acquérir progressivement de l’expertise au gré de la migration des mini-Data Warehouses, avant la migration de l’entrepôt de données proprement dit.

Définition des éléments à migrer

Dressez un inventaire de tous les éléments à migrer : schéma, données, processus ETL (pipelines), privilèges d’autorisation, utilisateurs, couches d’accès sémantique de l’outil BI et applications analytiques. Une explication détaillée de ce qu’inclut la migration de l’inventaire est fournie dans chacun des articles de niveau inférieur de cette série sur la migration. Vous trouverez ci-dessous des liens vers ceux-ci.

• considérations relatives à la migration, à la conception et aux performances du schéma ;
• migration des données, traitement ETL et chargement ;
• opérations de sécurité d’accès et d’entrepôt de données ;
• migration de la visualisation et des rapports ;
• minimisation de l’impact des problèmes SQL ;
• outils tiers pour vous aider dans le cadre de la migration de votre entrepôt de données.

Si vous hésitez quand à la meilleure approche à adopter, effectuez des tests dans un laboratoire de preuve de concept pour identifier les techniques optimales. Pour plus d’informations, consultez la section sur la diminution des risques de votre projet de migration d’entrepôt de données.

Contrôle de la migration

La migration de l’entrepôt de données vers Azure Synapse implique des tâches à accomplir :

• localement, telles l’exportation de données ;
• sur le réseau, tel le transfert de données ;
• dans le cloud Azure, telles que la transformation, l’intégration et le chargement des données.

Le problème est que la gestion de ces tâches peut se compliquer si les scripts et les utilitaires sont tous développés, testés et exécutés de manière indépendante dans des environnements locaux et Azure. Cela ajoute de la complexité, surtout si la gestion de version, la gestion des tests et l’exécution de la migration ne sont pas coordonnés.

Il est recommandé d’éviter ces complexités et de les contrôler à partir d’un emplacement commun via un référentiel de contrôle de code source, afin de gérer les modifications, du développement à la production en passant par les tests. L’exécution de la migration implique des tâches qui doivent être effectuées localement, sur le réseau et dans Azure. Étant donné qu’Azure Synapse est l’environnement cible, le contrôle de l’exécution de la migration à partir d’Azure simplifie la gestion. Utilisez Azure Data Factory pour créer un pipeline de contrôle de la migration afin de contrôler l’exécution tant localement que sur Azure. Cela a pour effet d’introduire de l’automatisation et de minimiser les erreurs. Data Factory devient un outil d’orchestration de la migration, pas seulement un outil d’intégration de données d’entreprise.

Parmi les autres options de contrôle de la migration disponibles auprès de partenaires Microsoft opérant sur Azure figurent des outils d’automatisation d’entrepôt de données permettant de tenter d’automatiser la migration. Il s’agit, par exemple, de fournisseurs tels que WhereScape et Attunity. La plupart de ces outils d’automation sont axés sur une approche lift-and-shift de la migration. Même dans ce cas, il se peut que ces outils ne prennent pas en charge certains éléments tels que les procédures stockées. Ces produits et quelques autres sont détaillés dans un guide séparé dédié aux outils tiers destinés à vous aider à migrer vers Azure Synapse.

Test de la migration

La première chose à faire pour tester consiste à définir une série de tests et un ensemble de résultats requis pour chacun d’eux, à exécuter afin de vérifier leur réussite et d’en faire état. Il est important de s’assurer que tous les aspects de vos systèmes existants et migrés sont dûment testés et comparés, à savoir :

• schéma ;
• types de données convertis le cas échéant ;
• utilisation d’un schéma défini par l’utilisateur dans Azure Synapse pour faire la distinction entre l’entrepôt de données et les tables de mini-Data Warehouses ;
• utilisateurs ;
• rôles et attributions d’utilisateurs à ces rôles ;
• privilèges de sécurité d’accès aux données ;
• confidentialité et conformité des données ;
• privilèges régissant les fonctionnalités d’administration ;
• qualité et intégrité des données ;
• traitement ETL qui alimente Azure Synapse, tant dans l’entrepôt de données que de l’entrepôt de données vers les mini-Data Warehouses, y compris les tests ;
• exactitude de toutes les lignes dans toutes les tables, y compris l’historique ;
• traitement de dimension à variation lente ;
• processus de capture des données modifiées ;
• calculs et agrégations utilisant des fonctions pouvant varier d’un système à l’autre ;
• résultats de l’ensemble des requêtes, rapports et tableaux de bord connus ;
• performances et scalabilité ;
• fonctionnalité analytique ;
• coûts dans le nouvel environnement assorti d’un paiement à l’utilisation.

Automatisez les tests autant que possible, en rendant les rendant reproductibles et en permettant une approche cohérente de l’évaluation des résultats. Si des rapports et des tableaux de bord sont incohérents, la possibilité de comparer les lignages des métadonnées des systèmes d’origine et migrés est précieuse lors des tests de migration, car elle permet de mettre en évidence des différences et de déterminer où celles-ci se sont produites quand leur détection est difficile.

La meilleure façon de procéder en toute sécurité consiste à créer des rôles, à attribuer des privilèges d’accès à ceux-ci, puis à associer des utilisateurs à des rôles. Pour accéder à l’entrepôt de données que vous venez de migrer, configurez un processus automatisé pour créer des utilisateurs et attribuer des rôles. Procédez de la même façon pour supprimer des utilisateurs des rôles.

Informez tous les utilisateurs du basculement afin qu’ils sachent ce qui change et à quoi s’attendre.

Diminution des risques de votre projet de migration d’entrepôt de données

Un autre facteur critique dans la migration de l’entrepôt de données est la diminution des risques du projet afin de maximiser la probabilité de réussite. Il est possible de diminuer les risques liés à une migration d’entrepôt de données de plusieurs façons. Les voici :

• Établissement d’un laboratoire de preuve de concept pour permettre à votre équipe d’effectuer des essais, de conduire des tests, de comprendre les problèmes et d’identifier des correctifs et optimisations permettant de valider les approches de migration, d’améliorer les performances et de réduire les coûts. Cela permet également de mettre en place des méthodes pour automatiser des tâches, de se servir d’outils intégrés, de créer des modèles pour capturer les meilleures pratiques, d’apprendre de l’expérience et de suivre les leçons apprises. Il s’agit d’une solution inestimable pour atténuer les risques et accroître les chances de réussite. En outre, vous pouvez attribuer aux tests des propriétaires responsables d’atteindre les objectifs et cibles de la migration, tels que définis dans votre stratégie de migration.
• Introduction d’une virtualisation de données entre les outils BI et vos entrepôt de données et mini-Data Warehouses. Apportez de la transparence pour les utilisateurs en utilisant une virtualisation des données afin de réduire les risques liés à la migration d’un entrepôt de données, et de masquer la migration aux utilisateurs à l’aide d’outils BI de virtualisation des données, comme illustré dans le diagramme suivant.

L’objectif est de rompre la dépendance entre les utilisateurs en entreprise se servant d’outils BI en libre-service et le schéma physique de l’entrepôt de données sous-jacent et des mini-Data Warehouses migrés. La virtualisation des données permet de masquer aux utilisateurs les changements de schéma effectués lors de la migration de l’entrepôt de données et des mini-Data Warehouses vers Azure Synapse (par exemple, pour optimiser les performances), car les utilisateurs accèdent uniquement aux tables virtuelles de la couche de virtualisation des données. Si une modification structurelle est nécessaire, seuls les mappages entre l’entrepôt de données ou les mini-Data Warehouses et les tables virtuelles doivent être modifiés afin que les utilisateurs ne soient pas conscients de ces modifications et de la migration.

• Archivez les tables identifiées comme jamais utilisées avant la migration de l’entrepôt de données, car il y a peu de sens à migrer des tables inutilisées. L’une des méthodes possibles consiste à archiver les données inutilisées dans le stockage Blob Azure ou Azure Data Lake Storage, et à créer des tables externes dans Azure Synapse pointant vers ces données afin qu’elles soient toujours en ligne.
• Envisagez la possibilité d’introduire une machine virtuelle sur Azure avec une version développement (généralement gratuite) du SGBD de l’entrepôt de données hérité en cours d’exécution sur cette machine virtuelle. Cela vous permet de déplacer rapidement le schéma d’entrepôt de données existant vers la machine virtuelle, puis de continuer à le déplacer dans Azure Synapse tout en travaillant entièrement dans le cloud Azure.
• Définissez l’ordre de migration et les dépendances.
• Assurez-vous que vos équipes d’infrastructure et d’exploitation sont prêtes pour la migration de vos données le plus tôt possible dans le projet de migration.
• Identifiez les différences de fonctionnalité du SGBD et l’endroit où la logique métier propriétaire pourrait devenir un problème. Par exemple, il est improbable que des procédures stockées pour le traitement ELT migrent facilement, et la migration ne contiendra aucun lignage de métadonnées dans la mesure où les transformations sont enfouies dans le code.
• Envisagez une stratégie consistant à migrer d’abord les mini-Data Warehouses, puis l’entrepôt de données qui est la source de ceux-ci. Cela permet une migration incrémentielle, la rend plus gérable et offre la possibilité de hiérarchiser la migration en fonction des besoins métier.
• Envisagez la possibilité d’utiliser une virtualisation de données pour simplifier votre architecture d’entrepôt de données actuelle avant de migrer, par exemple, pour remplacer les mini-Data Warehouses physiques par des mini-Data Warehouses virtuels afin de pouvoir éliminer les magasins de données physiques et les travaux ETL pour les mini-Data Warehouses sans perdre de fonctionnalité avant la migration. Cela permet de réduire le nombre de magasins de données à migrer, de réduire les copies des données, de réduire le coût total de possession et d’améliorer l’agilité. Cela nécessite le passage de mini-Data Warehouses physiques à des mini-Data Warehouses virtuels avant la migration de votre entrepôt de données. À bien des égards, vous pouvez considérer cela comme une étape de modernisation de l’entrepôt de données avant la migration.

Étapes suivantes

Pour plus d’informations sur les migrations d’entrepôt de données, assistez à un atelier virtuel consacré à la modernisation d’entrepôt de données cloud sur Azure d’Informatica.