Tech Talk : L'ETL dans le nuage est-il possible sans codage ? (Partie 3)
Dans cette dernière partie de mon Tech Talk(Partie 1 et Partie 2 ici), j'aimerais décrire l'expérience d'AWS avec un projet ETL pour un client dans l'industrie du marketing numérique. Le besoin d'un entrepôt de données est né de l'augmentation du volume et de la complexité des données. Au début, j'ai constaté que l'assemblage de données provenant de différentes sources dans Tableau (blending) donnait des tableaux de bord très lents à réagir. Nous devions mettre en place une autre solution.
Il y avait deux sources de données pour les cas d'utilisation sur lesquels nous avons travaillé : une base de données PostgreSQL hébergée dans le cloud AWS et Google BigQuery contenant des données analytiques. Le client a de l'expérience avec le cloud et maîtrise certaines bonnes pratiques DevOps comme Infrastructure as Code (IaC). Une fois le fournisseur sélectionné, la seule décision que nous devions prendre concernait l'outil ETL. Les deux options que nous avons envisagées étaient : AWS Glue ou les fonctions Lambda écrites en Python déclenchées par Step. Tentés par la fonctionnalité de catalogue de données, nous avons choisi Glue.
Extraction (ETL)
Glue est, par essence, un cluster Spark géré. Selon la terminologie d'AWS, puisque vous n'avez pas à configurer d'autres détails que le nombre de nœuds, il s'agit d'un cluster "sans serveur". Glue Studio permet de créer des flux ETL sans code, mais j'y reviendrai plus tard. Comme décrit dans les articles précédents, la première étape de l'ETL est l'extraction. C'est dans cette partie que les premiers problèmes sont apparus, et Glue a malheureusement prouvé qu'il n'en était qu'à ses balbutiements.
Dans l'environnement Glue, il existe des "crawlers" qui peuvent analyser les bases de données pour répertorier toutes les tables et les métadonnées correspondantes. Vous pouvez ensuite extraire les tables souhaitées. Malheureusement, les crawlers ne peuvent reconnaître que les tables et non les vues matérialisées, qui contiennent certains filtres et sont répandues dans la configuration PostgreSQL du client. Ce n'était pas un problème majeur ; nous pouvions travailler avec les tables brutes.
Le deuxième problème concernait la connexion BigQuery. Par défaut, ce connecteur n'est pas disponible. Vous devez le télécharger depuis la place de marché d'Amazon. Cela a deux conséquences. Premièrement, vous ne pouvez pas crawler les bases de données à partir de Google, vous devez donc connaître les noms des tables et les schémas des bases de données. Nous avons résolu ce problème en copiant les tables souhaitées sur des buckets S3 et en exécutant le crawler dessus. Deuxièmement, vous ne pourrez pas recréer ce connecteur avec des outils IaC, tels que Terraform. Cela signifie que le déploiement entièrement automatisé de l'infrastructure est impossible. Un opérateur humain est nécessaire.
Transformation (ETL)
Glue utilise un dialecte PySpark. Au lieu de cadres de données, vous avez des cadres dynamiques qui acceptent le type de colonne comme une liste. En outre, en théorie, il existe une interface utilisateur conçue pour vous permettre d'effectuer l'ETL sans code. D'après mon expérience, le nombre de transformations fournies par AWS est minime. Vous disposez de jointures, d'agrégations de base, de sélections et d'un filtre limité. Par exemple, il n'est pas possible de créer des champs calculés. Vous disposez d'un bloc de code personnalisé, mais son utilisation est très fastidieuse car vous ne pouvez pas déboguer/visualiser vos cadres de données (dynamiques). J'ai perdu quelques jours avant de réaliser que je ne pouvais rien développer avec cet outil.
Alors, comment faire ? En codant à 100 % ! Tout d'abord, vous devez créer ce que l'on appelle des points de terminaison de développement. Il s'agit d'une activité en deux étapes, qui prend environ 20 minutes à chaque fois. Ils vous facturent même le temps de lancement ! Sur la base des points de terminaison de développement, vous créez un carnet Sagemaker (concept similaire aux carnets Jupyter ou à Google Colab), et ce n'est qu'à partir de là que vous pouvez faire quelque chose de productif. Une excellente façon de procéder est de générer du code boilerplate avec toutes les importations et la création des contextes Glue et Spark. Le notebook est convivial et vous permet de déboguer votre code en visualisant les variables et les cadres de données. Si vous avez travaillé avec Databricks, vous savez de quoi je parle.
Chargement (ETL)
La troisième et dernière étape est le chargement. Comme la dernière fois, il s'agissait de placer plusieurs tables de dimensions et de faits stockées au format parquet dans l'entrepôt de données, une autre base de données PostgreSQL. Comme avec la solution Azure, nous ne pouvons pas définir des options de chargement importantes telles que la troncature, l'effacement ou l'écrasement des tables. Cela nous a amené à appliquer manuellement les scripts de chargement Pyspark avec un pilote JDBC.
Résumé
Azure Data Factory et AWS Glue se sont révélés être des solutions limitées fournissant des outils ETL sans code. Cela sera peut-être possible un jour, mais au début de l'année 2022, ce n'est pas une option. Dans le monde de l'ETL, il faudra se salir les mains avec le codage !
