| Passer de Teradata à BigQuery ? Automatiser le process ! |
|
|
|
|
|
La sortie de Teradata - un défi technique Teradata, c'est une « Appliance » choisie par d'innombrables acteurs. La spécialisation de Teradata dans le Datawarehousing / l’Analytics a permis la mise en œuvre de solutions avec des capacités de calcul hors norme, et une forte scalabilité. Mais la plupart des utilisateurs historiques de Teradata sont maintenant dans une logique de bascule vers le Cloud.
Un de nos clients a décidé de basculer son patrimoine Teradata vers Google Cloud Platform (BigQuery), ainsi que de migrer un certain nombre de technologies de data visualisation (SAP BO, Power BI).
Nous vous partageons la méthodologie mise en oeuvre dans le cadre de cette migration. |
Quelques indicateurs clefs concernant la plateforme à migrer |
|
|
|
|
|
| Données assets : - 400,000 "conteneurs" de données ;
- 270,000 tables ;
- 11,000 fichiers.
|
|
|
|
|
|
| Scripts assets : - 122,000 vues ;
- 1,200 macros ;
- 500 processus d’injection BTEQ ;
- 600 univers BO ;
- 100,000 rapports webi ;
- 30,000 processus de manipulation de données répartis dans 450 projets ETL Stambia.
|
|
|
|
|
|
| Statistiques sur les usages*: - 30 % des données utilisées ;
- 30 % des tables/vues/fichiers utilisés ;
- 50 % des transformations utilisées.
*qui mènent à un rapport décisionnel ou à une utilisation applicative |
|
|
|
|
|
Processing : - 1,500,000 requêtes par jour,
- 880,000 insert / update / merge
.... |
|
| |
|
|
|
3 enjeux majeurs ont été identifiés pour réussir cette migration |
- Il fallait pouvoir définir en temps continu l'existant sur la plateforme source, avec toutes ses dépendances ;
- Il fallait être en capacité de faire un inventaire permanent de l’avancement de la migration : ce qui est migré, ce qui doit l'être ;
- Il fallait partager à tous le process de migration, pour éviter les incompréhensions.
L'automatisation de ces tâches était un incontournable. |
|
|
|
|
|
Etape #1 Maîtriser la plateforme source en la cartographiant |
|
| |
|
|
|
| {openAudit} a permis de maîtriser les processus internes via un data lineage physique, au champ, dans Bteq, mais aussi dans les ETL/ELT, les Vues, les Macros, les autres scripts associés à l'alimentation des flux. |
|
|
|
|
|
| {openAudit} a contribué à identifier les usages de l'information, via une analyse des logs des bases d'audit, pour la consommation et l’injection des données. |
|
|
|
|
|
| {openAudit} a analysé l'ordonnancement des tâches et l'a lié au data lineage, ainsi qu'aux usages des données. |
|
|
|
|
|
| {openAudit} a mis en lumière les impacts dans les outils de data visualisation qui sont associés à Teradata (ex : Power BI, SAP BO...), pour entrevoir la complexité afférente (règles de gestion) et pour pouvoir faire du data lineage réellement de bout en bout. |
|
|
|
|
|
| Etape #2 Automatiser la migration |
|
|
|
|
|
Par une série de mécanismes, {openAudit} a reproduit l’essentiel des traitements dans BigQuery : parsing, puis production d’un SQL standard enrichi. A noter que certaines encapsulations (Shell, autres) sont susceptibles de dégrader l’output. A noter aussi que l’existence d’un ETL/ELT dans le système en source nécessite une transposition des traitements. Pour certains d’entre eux, {openAudit} permet d’accélérer le projet. |
|
|
|
|
|
Etape #3 Maîtriser le déploiement dans GCP grâce à la cartographie |
|
| |
|
|
|
| {openAudit} a opéré un parsing dynamique de BigQuery, des requêtes schedulées, des scripts des vues et des fichiers de chargement type Json, CSV, pour permettre la construction intelligente des flux. |
|
|
|
|
|
| {openAudit} a analysé les logs dans Google Cloud’s Operations (Stackdriver), pour d'emblée connaître les usages de l'information. |
|
|
|
|
|
| {openAudit} a défini l'ordonnancement des tâches, pour le lier au data lineage et aux usages des données. |
|
|
|
|
|
| {openAudit} a introspecté certaines technologies de data visualisation "cibles" qui reposent sur GCP (Looker, Data Studio, BO Cloud, Power BI ...), pour pouvoir y reconstruire l’intelligence en comparant les réponses. |
|
|
|
|
|
Par ailleurs, les connecteurs ont pu être migrés vers BigQuery (cas des connecteurs avec une détérioration des performances via le middleware hyper-Q de datometry). |
Conclusion Nous ne pensons pas qu'une migration d'une telle ambition puisse s'organiser à coup de "kick off", et de "deadlines", mais dans un processus intelligent qui repose sur une véritable maîtrise de la plateforme source / et de la plateforme cible, via une introspection technique continue des processus et des usages, ainsi qu'une représentation graphique "des" Systèmes d'Information, que chacun pourra comprendre et exploiter. L’automatisation de la migration aura une valeur ajoutée indéniable dans ce contexte. |
|
|
|
|
|
|
Commentaires
Enregistrer un commentaire