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 digital. Le besoin d'un Data Warehouse est venu de l'augmentation du volume et de la complexité des données. Au début, j'ai constaté que le regroupement de données provenant de différentes sources dans Tableau (blending) entraînait 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 l'Infrastructure as Code (IaC). Avec le fournisseur sélectionné, la seule décision à 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.

Source : https://medium.com/nerd-for-tech/export-oracle-database-to-postgresql-using-aws-glue-551860965c58

Extraction (ETL)

Glue est, en essence, un cluster Spark géré. Selon la terminologie AWS, puisque vous ne pouvez configurer aucun détail autre que le nombre de nœuds, il est ‘sans serveur.’ Glue Studio permet de créer des flux ETL sans code, mais je vais en parler plus en détail. Comme décrit dans les articles précédents, la première étape de l'ETL est l'Extraction. C'est là que les premiers problèmes sont apparus, et Glue a malheureusement montré qu'il n'était encore qu'à ses débuts.

Dans l'environnement Glue, il existe ce qu'on appelle des crawlers qui peuvent scanner les bases de données pour répertorier toutes les tables et leurs métadonnées respectives. Ensuite, vous pouvez 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. Cela n'était pas un gros problème ; nous avons pu travailler avec les tables brutes.

Source : https://aws.amazon.com/blogs/big-data/migrating-data-from-google-bigquery-to-amazon-s3-using-aws-glue-custom-connectors/

Le deuxième problème concernait la connexion à BigQuery. Par défaut, ce connecteur n'est pas disponible dès le départ. Vous devez le télécharger depuis le marché Amazon. Cela a deux conséquences. Premièrement, vous ne pouvez pas crawler les bases de données de Google, vous devez donc connaître les noms des tables et les schémas de base de données. Nous avons résolu cela en copiant les tables souhaitées vers des buckets S3 et en les scannant. Deuxièmement, vous ne pourrez pas recréer ce connecteur avec des outils IaC, par exemple, tel que Terraform. Cela signifie que le déploiement d'une infrastructure entièrement automatisée est impossible. Un opérateur humain est nécessaire.

Transformation (ETL)

Glue utilise un dialecte PySpark. Au lieu de frames de données, vous avez des frames dynamiques qui acceptent le type de colonne sous forme de liste. De plus, théoriquement, il existe une interface UI conçue pour vous permettre de réaliser de l'ETL sans code. D'après mon expérience, le nombre de transformations fournies par AWS est minime. Vous avez des jointures, des agrégations de base, sélectionner, et un filtre limité. Par exemple, il n'est pas possible de créer des champs calculés. Vous avez un bloc de code personnalisé, mais son utilisation est très laborieuse puisque vous ne pouvez pas déboguer/visualiser vos frames 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 faites-vous ? 100% code! Tout d'abord, vous devez créer ce qu'on appelle des points de développement. C'est une activité en deux étapes, prenant environ 20 minutes à chaque fois. Ils vous facturent même pour le temps de lancement ! À partir de points de développement, vous créez un notebook Sagemaker (concept similaire aux Notebooks Jupyter ou Google Colab), et ce n'est que là que vous pouvez faire quelque chose de productif. Un excellent moyen d'y parvenir est de générer du code standard avec toutes les importations et la création de contextes Glue et Spark. Le notebook est convivial et vous permet de déboguer votre code et de visualiser les variables et les frames 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. Tout comme la dernière fois, la tâche consistait à placer plusieurs tables de dimension et de fait stockées au format parquet dans le data warehouse, une autre base de données PostgreSQL. Comme avec la solution Azure, nous ne pouvons pas définir d'options de chargement importantes telles que tronquer/supprimer/surcharger des tables. Cela nous a amenés à appliquer manuellement les scripts Pyspark de chargement avec un driver JDBC.

Résumé

Tant Azure Data Factory que AWS Glue se sont révélés être des solutions limitées offrant des outils ETL sans code. Peut-être que ce sera possible un jour, mais en début 2022, ce n'est pas une option. Dans le monde de l'ETL, vous devrez mettre la main à la pâte avec le codage !