Migration de données, ETL et chargement pour les migrations Teradata

Cet article est la partie deux d’une série de sept parties qui fournit des conseils sur la migration de Teradata vers Azure Synapse Analytics. L’objectif de cet article sont les bonnes pratiques pour la migration concernant ETL et le chargement.

Considérations relatives à la migration des données

Décisions initiales pour la migration des données à partir de Teradata

Lors de la migration d’un entrepôt de données Teradata, vous devez poser des questions de base sur les données. Par exemple :

• Les structures de table inutilisées doivent-elle être migrées ?

• Quelle est la meilleure approche de migration pour réduire les risques et l’impact utilisateur ?

• Lors de la migration de DataMarts, rester physique ou passer au virtuel ?

Les sections suivantes décrivent ces points dans le contexte de la migration à partir de Teradata.

Migrer des tables inutilisées ?

Conseil

Dans les systèmes hérités, il n’est pas rare que les tables deviennent redondantes au fil du temps. Elles n’ont pas besoin d’être migrées dans la plupart des cas.

Il est logique de migrer uniquement les tables qui sont toujours utilisées dans le système existant. Les tables qui ne sont pas actives peuvent être archivées au lieu d’être migrées afin que les données restent disponibles si nécessaire à l’avenir. Il est préférable d’utiliser les métadonnées système et les fichiers journaux plutôt que la documentation pour déterminer les tables utilisées, car la documentation peut être obsolète.

Si cette option est activée, les tables et journaux de catalogue système Teradata contiennent des informations qui peuvent déterminer quand une table donnée a été consultée pour la dernière fois, ce qui peut être utilisé pour déterminer si une table est candidate à la migration.

Voici un exemple de requête sur DBC.Tables qui fournit la date du dernier accès et la dernière modification :

SELECT TableName, CreatorName, CreateTimeStamp, LastAlterName,
LastAlterTimeStamp, AccessCount, LastAccessTimeStamp 
FROM DBC.Tables t
WHERE DataBaseName = 'databasename'

Si la journalisation est activée et que l’historique des journaux est accessible, d’autres informations, telles que le texte de requête SQL, sont disponibles dans la table DBQLogTbl et les tables de journalisation associées. Pour plus d’informations, consultez l’historique des journaux Teradata.

Quelle est la meilleure approche de migration pour réduire les risques et l’impact sur les utilisateurs ?

Cette question se pose souvent, car les entreprises cherchent à réduire l’impact des changements sur le modèle de données de l’entrepôt de données afin de gagner en agilité. Les entreprises voient souvent une opportunité de moderniser ou de transformer davantage leurs données lors d’une migration ETL. Cette approche présente un risque plus élevé, car elle modifie plusieurs facteurs simultanément, ce qui rend difficile la comparaison des résultats de l’ancien système par rapport au nouveau. L’apport de modifications de modèle de données ici peut également affecter les travaux ETL en amont ou en aval à d’autres systèmes. Face à ce risque, il est préférable de reconcevoir à cette échelle après la migration de l’entrepôt de données.

Même si un modèle de données est intentionnellement modifié dans le cadre de la migration globale, il est préférable de migrer le modèle existant tel quel vers Azure Synapse, plutôt que de procéder à une réingénierie sur la nouvelle plateforme. Cette approche minimise l’effet sur les systèmes de production existants, tout en bénéficiant des performances et de l’évolutivité élastique de la plateforme Azure pour les tâches de réingénierie ponctuelles.

Lors de la migration à partir de Teradata, envisagez de créer un environnement Teradata dans une machine virtuelle dans Azure comme un tremplin dans le processus de migration.

Conseil

Migrez le modèle existant tel quel initialement, même s’il est prévu de changer à l’avenir.

Utiliser une instance Teradata de machine virtuelle dans le cadre d’une migration

Une approche facultative de la migration à partir d’un environnement Teradata local consiste à tirer parti de l’environnement Azure pour créer une instance Teradata dans une machine virtuelle dans Azure en colocation avec l’environnement Azure Synapse cible. Cela est possible, car Azure fournit un stockage cloud économique et une scalabilité élastique.

Avec cette approche, il est possible de se servir d’utilitaires Teradata standard, tels que Teradata Parallel Data Transporter (ou d’outils de réplication de données tiers, tels qu’Attunity Replicate) pour déplacer efficacement le sous-ensemble de tables Teradata à migrer vers l’instance de machine virtuelle. Ensuite, toutes les tâches de migration peuvent avoir lieu dans l’environnement Azure. Cette approche présente plusieurs avantages :

• Après la réplication initiale des données, les tâches de migration n’ont aucun impact sur le système source.

• L’environnement Azure contient des interfaces, outils et utilitaires Teradata familiers.

• L’environnement Azure fournit la disponibilité de bande passante réseau entre le système source local et le système cible dans le cloud.

• Des outils, tels qu’Azure Data Factory, peuvent appeler efficacement des utilitaires, tels que Teradata Parallel Transporter, pour migrer des données rapidement et facilement.

• Le processus de migration est entièrement orchestré et contrôlé dans l’environnement Azure.

Lors de la migration de DataMarts, rester physique ou passer au virtuel ?

Conseil

La virtualisation des DataMarts peut économiser sur les ressources de stockage et de traitement.

Dans les environnements d’entrepôt de données Teradata hérités, il est courant de créer plusieurs DataMarts structurés pour fournir de bonnes performances en matière de requêtes et de rapports en libre-service ad hoc pour un service ou une fonction commerciale donnés au sein d’une organisation. En tant que tel, un DataMart se compose généralement d’un sous-ensemble de l’entrepôt de données et contient des versions agrégées des données sous une forme qui permet aux utilisateurs d’interroger facilement ces données avec des temps de réponse rapides via des outils de requête conviviaux, tels que Microsoft Power BI, Tableau ou MicroStrategy. Ce formulaire est généralement un modèle de données dimensionnel. Les DataMarts peuvent servir à exposer les données sous une forme utilisable, même si le modèle de données de l’entrepôt sous-jacent est différent, par exemple, un coffre de données.

Vous pouvez utiliser des DataMarts pour des unités commerciales individuelles au sein d’une organisation afin d’implémenter des régimes de sécurité des données robustes, en autorisant uniquement l’accès des utilisateurs à des DataMarts spécifiques qui les concernent, et en éliminant, en masquant ou en anonymisant les données sensibles.

Si ces DataMarts sont implémentés sous forme de tables physiques, il faut des ressources de stockage supplémentaires pour les stocker, ainsi que des opérations de traitement supplémentaires pour les créer et les actualiser régulièrement. De plus, comme les données dans les DataMarts sont celles datant de la dernière opération d’actualisation, elles ne sont pas toujours appropriées pour les tableaux de bord de données hautement volatiles.

Conseil

Les performances et la scalabilité d’Azure Synapse permettent la virtualisation sans sacrifier les performances.

Avec l’avènement des architectures MPP évolutives bon marché, comme Azure Synapse, et les caractéristiques de performances intrinsèques de ces architectures, vous pouvez envisager de fournir des fonctionnalités de DataMart sans avoir à instancier le DataMart sous forme d’ensemble de tables physiques. Cela est possible en virtualisant efficacement les DataMarts via des vues SQL sur l’entrepôt de données principal ou via une couche de virtualisation à l’aide de fonctionnalités telles que les vues dans Azure, ou les produits de visualisation de partenaires Microsoft. Cette approche simplifie ou élimine les besoins supplémentaires en stockage et en traitement des agrégations, et réduit le nombre total d’objets de base de données à migrer.

Il y a un autre avantage potentiel à cette approche. En implémentant l’agrégation et la logique de jointure dans une couche de virtualisation et en présentant des outils de création de rapports externes via une vue virtualisée, le traitement requis pour créer ces vues est envoyé dans l’entrepôt de données, qui est généralement le meilleur endroit pour exécuter des jointures, des agrégations et d’autres opérations de ce type sur de gros volumes de données.

Les principaux facteurs conduisant à choisir l’implémentation d’un DataMart virtuel par rapport à un DataMart physique sont les suivants :

• Une plus grande agilité : un DataMart virtuel est plus facile à modifier que des tables physiques et les processus ETL associés.

• Réduction du coût total de possession : une implémentation virtualisée nécessite moins de magasins et de copies de données.

• Élimination des travaux ETL pour migrer et simplifier l’architecture d’entrepôt de données dans un environnement virtualisé.

• Amélioration des performances : les DataMarts physiques étaient historiquement plus performants, mais les produits de virtualisation implémentent maintenant des techniques de mise en cache intelligentes pour l’atténuation.

Migration de données à partir de Teradata

Comprendre vos données

Une partie de la planification de la migration consiste à déterminer précisément le volume de données à migrer, car cela peut avoir un impact sur les choix de l’approche de migration. Examinez les métadonnées système pour déterminer l’espace physique pris par les « données brutes » dans les tables à migrer. Dans ce contexte, les « données brutes » correspondent à la quantité d’espace utilisé par les lignes de données d’une table, en excluant les surcharges, telles que les index et la compression. Cela est particulièrement vrai pour les tables de faits les plus volumineuses, qui concentrent généralement plus de 95 % des données.

Pour connaître avec précision le volume de données à migrer pour une table donnée, extrayez un échantillon représentatif des données (par exemple, un million de lignes) dans un fichier de données ASCII plat délimité non compressé. Basez-vous ensuite sur la taille de ce fichier pour obtenir une taille moyenne de données brutes par ligne de cette table. Pour finir, multipliez cette taille moyenne par le nombre total de lignes de la table complète pour obtenir la taille de données brutes de la table. Utilisez cette taille de données brutes dans votre planification.

Considérations relatives à la migration ETL

Décisions initiales concernant la migration ETL Teradata

Conseil

Planifiez l’approche de la migration ETL à l’avance et tirez parti des installations Azure, le cas échéant.

Pour le traitement ETL/ELT, les entrepôts de données Teradata hérités peuvent utiliser des scripts personnalisés avec des utilitaires Teradata, tels que BTEQ et Teradata Parallel Transporter (TPT), ou des outils ETL tiers, tels que Informatica ou Ab Initio. Parfois, les entrepôts de données Teradata utilisent une combinaison d’approches ETL et ELT qui évolue au fil du temps. Lors de la planification d’une migration vers Azure Synapse, vous devez déterminer la meilleure façon d’implémenter le traitement ETL/ELT requis dans le nouvel environnement tout en réduisant le coût et le risque impliqués. Pour en savoir plus sur le traitement ETL et ELT, consultez l’approche de conception ELT et ETL.

Les sections suivantes décrivent les options de migration et fournissent des recommandations pour différents cas d’usage. Cet organigramme résume une approche :

La première étape consiste toujours à créer un inventaire des processus ETL/ELT qui doivent être migrés. Comme pour d’autres étapes, il est possible que les fonctionnalités Azure intégrées standard rendent inutile la migration de certains processus existants. À des fins de planification, il est important de bien évaluer l’ampleur de la migration à effectuer.

Dans l’organigramme précédent, la décision 1 concerne une décision générale sur la migration vers un environnement totalement natif Azure. Si vous passez à un environnement totalement natif Azure, nous vous recommandons de reconcevoir le traitement ETL en utilisant des Pipelines et activités dans Azure Data Factory ou des Pipelines Azure Synapse. Si vous ne passez pas à un environnement totalement natif Azure, la décision 2 consiste à savoir si un outil ETL tiers existant est déjà utilisé.

Dans l’environnement Teradata, certains ou tous les traitements ETL peuvent être effectués par des scripts personnalisés à l’aide d’utilitaires spécifiques à Teradata, tels que BTEQ et TPT. Dans ce cas, votre approche doit consister à reconcevoir à l’aide de Data Factory.

Conseil

Tirez parti de l’investissement dans des outils tiers existants pour réduire les coûts et les risques.

Si un outil ETL tiers est déjà utilisé, en particulier s’il y a un investissement important dans les compétences, ou si plusieurs workflows et planifications existants utilisent cet outil, la décision 3 consiste à savoir si l’outil peut efficacement utiliser Azure Synapse comme environnement cible. Dans l’idéal, l’outil inclut des connecteurs natifs qui peuvent tirer parti des fonctionnalités Azure, telles que PolyBase ou COPY INTO, pour un chargement de données plus efficace. Il existe un moyen d’appeler un processus externe, comme PolyBase ou COPY INTO, et de passer les paramètres appropriés. Dans ce cas, utilisez les compétences et workflows existants avec Azure Synapse comme nouvel environnement cible.

Si vous décidez de conserver un outil ETL tiers existant, il peut y avoir des avantages à exécuter cet outil dans l’environnement Azure (plutôt que sur un serveur ETL local existant) et à laisser Azure Data Factory gérer l’orchestration globale des workflows existants. Un avantage particulier est que moins de données doivent être téléchargées à partir d’Azure, traitées, puis rechargées dans Azure. Par conséquent, la décision 4 consiste à laisser l’outil existant s’exécuter ou de le déplacer dans l’environnement Azure pour obtenir des avantages en termes de coût, de performances et de scalabilité.

Reconcevoir des scripts existants spécifiques à Teradata

Si certains ou tous les traitements ETL/ELT de l’entrepôt Teradata existants sont gérés par des scripts personnalisés qui utilisent des utilitaires spécifiques à Teradata, tels que BTEQ, MLOAD ou TPT, ces scripts doivent être recodés pour le nouvel environnement Azure Synapse. De même, si les processus ETL ont été implémentés à l’aide de procédures stockées dans Teradata, ceux-ci doivent également être recodés.

Conseil

L’inventaire des tâches ETL à migrer doit inclure des scripts et des procédures stockées.

Certains éléments du processus ETL sont faciles à migrer, par exemple, par simple chargement de données en bloc dans une table de mise en lots à partir d’un fichier externe. Il peut même être possible d’automatiser ces parties du processus, par exemple, à l’aide de PolyBase plutôt que d’une charge rapide ou de MLOAD. Si les fichiers exportés sont Parquet, vous pouvez utiliser un lecteur Parquet natif, ce qui est une option plus rapide que PolyBase. La réingénierie d’autres parties du processus qui contiennent des procédures SQL et/ou stockées arbitraires prend plus de temps.

Un moyen de tester Teradata SQL pour la compatibilité avec Azure Synapse consiste à capturer des instructions SQL représentatives dans les journaux Teradata, puis à préfixer ces requêtes avec EXPLAIN, puis, en supposant qu’un modèle de données migré semblable à celui d’Azure Synapse, à exécuter ces instructions EXPLAIN dans Azure Synapse. Tout SQL incompatible génère une erreur et les informations d’erreur peuvent déterminer la mise à l’échelle de la tâche de recodage.

Les partenaires Microsoft offrent des outils et des services pour migrer les procédures Teradata SQL et stockées vers Azure Synapse.

Utiliser des outils ETL tiers

Comme décrit dans la section précédente, dans de nombreux cas, le système d’entrepôt de données hérité existant sera déjà rempli et géré par des produits ETL tiers. Pour obtenir la liste des partenaires d’intégration de données Microsoft pour Azure Synapse, consultez les partenaires d’intégration de données.

Chargement de données à partir de Teradata

Choix disponibles lors du chargement de données à partir de Teradata

Conseil

Les outils tiers peuvent simplifier et automatiser le processus de migration et donc réduire les risques.

Quand vous êtes prêt à migrer les données d’un entrepôt de données Teradata, vous devez réfléchir à certains points importants sur le chargement des données. Vous devez décider comment les données seront déplacées physiquement de l’environnement Teradata local existant dans Azure Synapse dans le cloud, et quels outils seront utilisés pour effectuer le transfert et la charge. Tenez compte des questions suivantes, qui sont abordées dans les sections suivantes.

• Allez-vous extraire les données dans des fichiers ou les déplacer directement via une connexion réseau ?

• Allez-vous orchestrer le processus à partir du système source ou de l’environnement cible Azure ?

• Quels outils utiliserez-vous pour automatiser et gérer le processus ?

Transférer des données via des fichiers ou une connexion réseau ?

Conseil

Ayez une idée précise des volumes de données à migrer et de la bande passante réseau disponible, car ces facteurs influencent le choix de l’approche de la migration.

Une fois que les tables de base de données à migrer ont été créées dans Azure Synapse, vous pouvez déplacer les données pour remplir ces tables hors du système Teradata hérité et dans le nouvel environnement. Il y a deux approches principales :

• Extraction de fichiers : extrayez les données des tables Teradata vers des fichiers plats, normalement au format CSV, via BTEQ, Fast Export ou Teradata Parallel Transporter (TPT). Utilisez TPT dès que possible, car c’est le plus efficace en termes de débit de données.

  Cette approche nécessite de l’espace pour charger les fichiers de données extraits. L’espace peut être local dans la base de données source Teradata (si un stockage suffisant est disponible) ou distant dans Stockage Blob Azure. Les meilleures performances sont obtenues lorsqu’un fichier est écrit localement, car cela évite la surcharge réseau.

  Pour réduire les exigences de stockage et de transfert réseau, il est recommandé de compresser les fichiers de données extraits à l’aide d’un utilitaire, tel que gzip.

  Une fois extraits, les fichiers plats peuvent être déplacés dans Stockage Blob Azure (colocalisés avec l’instance Azure Synapse cible) ou chargés directement dans Azure Synapse à l’aide de PolyBase ou de COPY INTO. La méthode de déplacement physique des données du stockage local vers l’environnement cloud Azure dépend de la quantité de données et de la bande passante réseau disponible.

  Microsoft propose différentes options pour déplacer de grands volumes de données, y compris AZCopy pour déplacer des fichiers sur le réseau dans Stockage Azure, Azure ExpressRoute pour déplacer des données en bloc sur une connexion réseau privée et Azure Data Box où les fichiers sont déplacés vers un appareil de stockage physique qui est ensuite expédié vers un centre de données Azure pour le chargement. Pour plus d'informations, consultez Transfert de données.

• Extraction directe et chargement sur le réseau : l’environnement Azure cible envoie une demande d’extraction de données, normalement via une commande SQL, au système Teradata hérité pour extraire les données. Les résultats sont envoyés sur le réseau et chargés directement dans Azure Synapse, sans avoir à « déposer » les données dans des fichiers intermédiaires. Le facteur de limitation de ce scénario est normalement la bande passante de la connexion réseau entre la base de données Teradata et l’environnement Azure. Pour les volumes de données très importants, cette approche peut ne pas être pratique.

Il existe également une approche hybride qui utilise les deux méthodes. Par exemple, vous pouvez utiliser l’approche d’extraction de réseau direct pour des tables de dimension plus petites et des exemples de tables de faits plus grandes pour fournir rapidement un environnement de test dans Azure Synapse. Pour les grandes tables de faits historiques de volume, vous pouvez utiliser l’approche d’extraction et de transfert de fichier à l’aide d’Azure Data Box.

Orchestrer à partir de Teradata ou d’Azure ?

L’approche recommandée lors du déplacement vers Azure Synapse consiste à orchestrer l’extraction et le chargement des données à partir de l’environnement Azure à l’aide d’Azure Synapse Pipelines ou d’Azure Data Factory, ainsi que des utilitaires associés, tels que PolyBase ou COPY INTO, pour le chargement de données le plus efficace. Cette approche tire parti des fonctionnalités Azure et fournit une méthode simple pour créer des pipelines de chargement de données réutilisables.

D’autres avantages de cette approche incluent une réduction de l’impact sur le système Teradata pendant le processus de chargement des données, car le processus de gestion et de chargement s’exécute dans Azure, et la possibilité d’automatiser le processus à l’aide de pipelines de chargement de données pilotés par les métadonnées.

Quels outils peuvent être utilisés ?

La tâche de transformation et de déplacement des données est la fonction de base de tous les produits ETL. Si l’un de ces produits est déjà utilisé dans l’environnement Teradata existant, l’utilisation de l’outil ETL existant peut simplifier la migration des données de Teradata vers Azure Synapse. Cette approche suppose que l’outil ETL prend en charge Azure Synapse en tant qu’environnement cible. Pour plus d’informations sur les outils qui prennent en charge Azure Synapse, consultez Partenaires d’intégration de données.

Si vous utilisez un outil ETL, envisagez d’exécuter cet outil dans l’environnement Azure pour tirer parti des performances, de la scalabilité et du coût du cloud Azure, et libérer des ressources dans le centre de données Teradata. Un autre avantage est la réduction du déplacement des données entre les environnements cloud et locaux.

Résumé

Pour résumer, nos recommandations relatives à la migration des données et aux processus ETL associés de Teradata vers Azure Synapse sont les suivantes :

• Planifiez à l’avance pour garantir le succès de l’exercice de migration.

• Faites un inventaire détaillé des données et des processus à migrer le plus tôt possible.

• Appuyez-vous sur les fichiers journaux et métadonnées système pour avoir une compréhension fine de l’utilisation des données et des processus. Ne vous fiez pas entièrement à la documentation, qui peut parfois être obsolète.

• Comprenez les volumes de données à migrer, et la bande passante réseau entre le centre de données local et les environnements cloud Azure.

• Envisagez d’utiliser une instance Teradata dans une machine virtuelle Azure comme tremplin pour décharger la migration à partir de l’environnement Teradata hérité.

• Tirez parti des fonctionnalités Azure « intégrées » standard pour réduire la charge de travail de migration.

• Identifiez et comprenez les outils les plus efficaces pour l’extraction et le chargement des données dans les environnements Teradata et Azure. Utilisez les outils appropriés dans chaque phase du processus.

• Utilisez des installations Azure, telles qu’Azure Synapse Pipelines ou Azure Data Factory, pour orchestrer et automatiser le processus de migration tout en réduisant l’impact sur le système Teradata.

Étapes suivantes

Pour en savoir plus sur les opérations d’accès à la sécurité, consultez l’article suivant de cette série : Sécurité, accès et opérations pour les migrations Teradata.