Guide de migration de Teradata vers Snowflake¶

Phase 1 : Planification et conception¶

Cette phase est la première étape cruciale d’une migration Snowflake réussie. Elle pose les bases de l’ensemble du processus de migration en définissant la portée, les objectifs et les exigences. Cette phase implique une compréhension profonde de l’environnement actuel et une vision claire de l’état futur de Snowflake.

Au cours de cette phase, les organisations identifient les indicateurs clés et les objectifs techniques pour migrer vers Snowflake en exécutant les tâches suivantes :

Phase 2 : Environnement et sécurité¶

L’une des premières étapes que nous recommandons est de configurer les environnements et les mesures de sécurité nécessaires pour commencer la migration. Il y a beaucoup d’éléments à prendre en compte, alors commençons par la sécurité. Comme pour toute plateforme cloud, Snowflake fonctionne selon un modèle de sécurité partagé entre la plateforme et les administrateurs.

Phase 3 : Conversion du code de base de données¶

SnowConvert AI comprend le code source Teradata et convertit le langage de définition des données (DDL), le langage de manipulation de données (DML), et les fonctions dans le code source en SQL correspondant dans la cible : Snowflake. SnowConvert AI peut migrer le code source vers l’une de ces trois extensions .sql, .dml, ddl

Cette phase consiste à extraire le code directement du catalogue de la base de données des systèmes sources, tels que les définitions de table, les vues, les procédures stockées et les fonctions. Une fois extrait, vous migrez l’ensemble de ce code vers desDDLs (Langages de définition des données) équivalents dans Snowflake. Cette étape comprend également la migration des scripts DML (Language de manipulation de données), qui peuvent être utilisés par les analystes commerciaux pour créer des rapports ou des tableaux de bord.

Consultez nos scripts d’extraction recommandés ici

Le DDL Teradata comprend généralement des références aux index principaux, plan de secours, ou partitionnement. Dans Snowflake, ces structures n’existent pas de la même manière :

• [Utilisez SnowConvert AI pour Teradata] (https://www.snowflake.com/en/migrate-to-the-cloud/snowconvert/) qui rationalise considérablement le langage de définition des données (DDL), en particulier lorsque vous traitez de nombreuses tables. Il automatise la traduction des constructions DDL spécifiques de Teradata, telles que les définitions d’index principales et les options de secours, en structures équivalentes de Snowflake. Cette automatisation réduit l’effort manuel et réduit le risque d’erreurs, permettant aux équipes de se concentrer sur une stratégie de migration et une validation de niveau supérieur. Au-delà de la conversion DDL de base, SnowConvert AI traite également les complexités comme le mappage des types de données et la réorganisation des schémas. Elle peut ajuster automatiquement les types de données pour les aligner sur les offres de Snowflake et faciliter les décisions relatives à la consolidation ou à la décomposition des schémas pour des performances et une gestion optimales. Cette approche complète garantit que la structure de base de données migrée est non seulement fonctionnelle, mais également optimisée pour l’architecture de Snowflake.

• Ajustez les types de données si nécessaire ou utilisez l’assistant AI aux migrations pour résoudre toute erreur ou tout avertissement (EWI).

• Décidez s’il faut réorganiser les schémas (par exemple, en divisant de grands schémas monolithiques en plusieurs bases de données Snowflake).

Phase 4 : Migration des données¶

Tout d’abord, il est important de faire la différence entre la migration des données historiques et l’ajout de nouvelles données. La migration des données historiques consiste à prendre un instantané des données à un moment précis et à les transférer vers Snowflake. Nous recommandons de réaliser d’abord une copie exacte des données sans transformation quelconque dans Snowflake. Cette copie initiale entraînera une certaine charge sur la plateforme héritée, par conséquent, ne le faites qu’une seule fois et stockez-la dans Snowflake.

Vos étapes pratiques :

• Exécution d’une migration des données historiques : Prenez un instantané de vos données Teradata à un moment précis et transférez-les vers Snowflake, souvent en tant que transfert en masse initial. Nous recommandons d’effectuer une copie exacte sans transformation initiale.

• Planification de la migration des données incrémentielles : Après la migration historique initiale, mettez en place des processus pour déplacer les données nouvelles ou modifiées de Teradata vers Snowflake de manière graduelle afin de maintenir votre environnement Snowflake à jour.

Phase 5 : Ingestion des données¶

La migration des pipelines vers Snowflake implique le déplacement ou la réécriture de la logique basée sur les données, comme les scripts BTEQ, les procédures stockées, les macros ou les flux ETL spécialisés. Ceci inclut une transition d’orchestration, qui remplace les scripts BTEQ ou les tâches Teradata planifiées par des flux et des tâches dans Snowflake pour des transformations incrémentielles. Cela nécessite également un réalignement entrée/sortie, qui redirige plusieurs sources de données entrantes atterrissant dans Teradata vers des modèles d’ingestion Snowflake (COPY, Snowpipe).

Au cours de la phase de conversion et d’optimisation des requêtes, le SQL Teradata est converti en SQL Snowflake, qui peut inclure le remplacement de macros par des procédures ou des vues stockées, la réécriture de la logique QUALIFY, et l’ajustement des procédures stockées et des index de jointure. SnowConvert AI pour Teradata peut automatiser une grande partie de cette traduction.

Avec les données elles-mêmes dans Snowflake, vous passez maintenant à la migration ou à la réécriture d’une logique basée sur Teradata— scripts BTEQ, procédures stockées, macros ou flux ETL spécialisés.

Phase 6 : Rapports et analyses¶

Maintenant que nous avons une base de données avec des données historiques et des pipelines dynamiques qui importent continuellement de nouvelles données, l’étape suivante consiste à extraire la valeur de ces données par le biais de la Business Intelligence (BI). Les rapports peuvent être effectués à l’aide des outils BI standard ou de requêtes personnalisées. Dans les deux cas, le SQL envoyé à la base de données peut devoir être ajusté pour répondre aux exigences de Snowflake. Ces ajustements peuvent aller de simples changements de nom (qui sont courants pendant la migration) à des différences de syntaxe et à des différences sémantiques plus complexes. Tous ces éléments doivent être identifiés et traités.

Comme pour le processus d’ingestion, il est crucial d’examiner toute utilisation de la plateforme héritée et d’intégrer ces résultats dans le plan de migration. Il existe généralement deux types de rapports à prendre en compte : rapports de l’IT et rapports appartenant à des entreprises. Il est généralement plus facile de suivre les rapports de l’IT, mais les rapports appartenant à l’entreprise et les requêtes complexes créées par des utilisateurs professionnels nécessitent une approche différente.

Les utilisateurs professionnels sont un acteur clé dans le processus de migration et doivent être inclus dans la matrice RACI pendant la phase de planification. Ils doivent être formés au fonctionnement de Snowflake et doivent comprendre clairement les différences entre les plateformes. Cela leur permettra de modifier leurs requêtes et rapports personnalisés selon leurs besoins. Nous recommandons généralement une formation parallèle pour les utilisateurs professionnels, suivie d”heures de bureau avec des experts en migration qui peuvent aider à traiter les différences entre les plateformes et guider les utilisateurs à propos des ajustements qu’ils doivent effectuer.

Les utilisateurs professionnels sont finalement ceux qui « acceptent » la migration. Vous avez peut-être terminé la migration technique du point de vue de l’IT, mais si les utilisateurs professionnels ne sont pas impliqués, ils peuvent continuer à utiliser des milliers de rapports qui sont essentiels à la gestion de l’entreprise. Si ces rapports ne sont pas mis à jour pour fonctionner avec Snowflake, l’entreprise ne peut pas complètement quitter l’ancienne plateforme.

Le SQL Teradata possède des constructions qui ne sont pas dans Snowflake, et vice versa. Les différences principales sont les suivantes :

• Macros : Non prises en charge dans Snowflake ; généralement remplacées par des procédures stockées ou des vues.

• QUALIFY : Snowflake ne prend pas en charge QUALIFY directement ; réécrire la logique en utilisant une sous-requête ou unSELECT externe.

• Procédures stockées : Teradata SP vs. Snowflake SP (basé sur SQL ou JavaScript). La langue procédurale diffère.

• Index de jointure : Pas d’équivalent direct ; s’appuient sur le nettoyage des micropartitions et les clés de clustering.

• COLLECT STATISTICS: Teradata utilise des statistiques explicites, tandis que Snowflake le fait automatiquement.

SnowConvert AI pour Teradata est recommandée pour la traduction automatique. Elle peut gérer les macros, les procédures stockées et les scripts BTEQ, produisant du code compatible avec Snowflake.

Phase 7 : Validation et test des données¶

Cela nous amène à la validation et au test des données, deux étapes souvent sous-estimées dans le processus de planification de migration. Bien sûr, l’objectif est de disposer de données aussi propres que possible avant d’entrer dans cette phase.

Chaque organisation possède ses propres méthodologies de test et ses propres exigences pour passer des données en production. Celles-ci doivent être bien comprises dès le début du projet. Quelles sont alors les stratégies utiles pour la validation des données ?

• Effectuer des tests complets dans la migration Snowflake : au cours du processus de migration Snowflake, des tests complets doivent être effectués, notamment :

  1. Des tests fonctionnels : Pour vérifier que toutes les applications et fonctionnalités migrées fonctionnent comme prévu dans le nouvel environnement, en veillant à l’intégrité et à la précision des données.

  2. Des tests de performances : Pour évaluer les performances des requêtes, la vitesse de chargement des données et la réactivité globale du système, ce qui permet d’identifier et de remédier aux goulots d’étranglement des performances.

  3. Des tests d’acceptation par l’utilisateur (UAT) : Impliquez les utilisateurs finaux dans le processus de test pour vous assurer que le système migré répond à leurs exigences et recueillir des commentaires pour les améliorations potentielles.

• Fournir une formation et une documentation pour la migration Snowflake :

  • proposez une formation complète aux utilisateurs finaux sur les fonctionnalités et les meilleures pratiques de Snowflake, en abordant des sujets tels que l’accès aux données, l’optimisation des requêtes et la sécurité.

  • Créez une documentation complète, y compris des schémas d’architecture système, des schémas de flux de données, des procédures opérationnelles, des guides d’utilisateur, des guides de dépannage et des FAQs pour des recherches simples.

Phase 8 : Déploiement¶

Lorsque vous serez prêt pour la migration, assurez-vous que toutes les parties prenantes sont d’accord et comprennent qu’à partir de là, Snowflake sera le système d’enregistrement, et non la plateforme héritée. Vous devrez obtenir des signatures finales et officielles de la part de toutes les parties prenantes avant de poursuivre. Tous les rapports qui n’ont pas été migrés sont désormais de la responsabilité des utilisateurs professionnels. C’est pourquoi il est crucial de ne pas impliquer les utilisateurs à la dernière minute : ils doivent faire partie du processus depuis le début et doivent être informés du calendrier de migration.

En outre, vérifiez que toutes les autorisations ont été correctement accordées. Par exemple, si vous utilisez des rôles basés sur Active Directory, assurez-vous qu’ils sont créés et configurés dans Snowflake.

Quelques scénarios supplémentaires sont généralement laissés à la fin, mais ils ne doivent pas être négligés :

• Clés artificielles : Si vous utilisez des clés artificielles, sachez que leur cycle de vie peut varier entre les systèmes existants et Snowflake. Ces clés doivent être synchronisées pendant la migration.

• Calendrier de la migration : Selon votre secteur d’activité, il peut y avoir des moments plus ou moins favorables au cours de l’année pour effectuer une migration. Réfléchissez bien au calendrier.

• Licences de plateforme héritée : N’oubliez pas que vous pouvez être amené à respecter des délais stricts liés à l’octroi de licences pour la plateforme héritée. Veillez à planifier votre migration en fonction de ces délais.

Phase 9 : Optimisation et exécution¶

Une fois qu’un système a été migré vers Snowflake, il entre en mode de maintenance normal. Tous les systèmes logiciels sont des organismes vivants qui nécessitent une maintenance continue. Cette phase, après la migration, est appelée optimisation et exécution, et elle ne fait pas partie de la migration elle-même.

L’optimisation et l’amélioration continue sont des processus permanents qui se produisent après la migration. À ce stade, votre équipe prend la propriété entière du système dans Snowflake. Le système continuera d’évoluer et l’optimisation sera impulsée par les modèles d’utilisation.

En général, nous notons que les tâches dans Snowflake ont tendance à s’exécuter plus rapidement que sur les plateformes d’origine. Si les performances ne répondent pas aux attentes, vous devrez peut-être exécuter des optimisations pour tirer pleinement parti de l’architecture unique de Snowflake. Snowflake fournit divers outils d’analyse de requêtes qui peuvent aider à identifier les goulots d’étranglement, ce qui vous permet d’optimiser des parties spécifiques du workflow.

Au cours de la phase d’optimisation, vous devrez peut-être revoir différents aspects du système. L’avantage est que vous bénéficiez déjà des capacités de Snowflake, et les tâches d’optimisation feront partie de votre routine de maintenance régulière.

Nous vous recommandons de vous concentrer sur le traitement des problèmes de performances critiques uniquement au cours de la phase de migration. Il est préférable de traiter l’optimisation comme un effort après la migration.

Annexe 1 : Bases de données Teradata à exclure lors de la migration vers Snowflake¶

La liste suivante des bases de données est nécessaire pour Teradata uniquement et ne doit pas être migrée vers Snowflake :

Annexe 2 : Types Teradata vers types de données Snowflake¶