Tech Talk : L'ETL dans le nuage est-il possible sans codage ? (Partie 2)
Images : https://www.agilytic.be/blog/tech-talk-etl-cloud-coding-part-2
Dans cet article, qui fait suite à la première partie, j'aimerais illustrer la mise en place d'un projet de flux ETL pour un client du secteur de l'hôtellerie. Comme l'outil frontal souhaité par le client est Power BI, nous avons proposé Microsoft comme fournisseur approprié pour la migration vers le cloud. Le portail Azure est l'interface utilisateur en nuage la plus conviviale, avec une documentation complète, c'est donc une bonne option pour commencer. Le seul inconvénient est qu'Azure est légèrement plus cher que ses concurrents.
Il n'y avait qu'une seule source de données pour cette démonstration de faisabilité, ici surlignée en violet :
Architecture des données en l'état
Extraction (ETL)
La première étape de l'ETL est l'extraction. Notre tâche consistait à extraire près de 30 tables de la base de données MySQL. Nous avons utilisé Azure Data Factory (ADF) pour cela. En effet, c'est l'une des rares activités où le codage n'est pas nécessaire. Le seul point délicat est qu'un réseau privé héberge la base de données MySQL. Cela signifie que vous devez configurer votre ADF sur une VM appartenant à ce réseau. Le processus d'installation du runtime d'intégration auto-hébergé n'est pas des plus simples. N'oubliez pas non plus de doter cette machine virtuelle d'un environnement d'exécution Java pour pouvoir extraire les tables dans des fichiers parquet. Il s'agit d'un format efficace qui contient des métadonnées. Snappy est le mode de compression par défaut, et nous le recommandons vivement.
L'ADF a la hiérarchie suivante : Data Factory > Pipelines > Activities. Une fois que vous avez relié votre ADF à toutes les ressources nécessaires (dans notre cas : base de données MySQL, stockage de données Azure et Databricks), vous pouvez commencer à extraire des données à l'aide de ce que l'on appelle les "activités de copie". L'ADF dispose de deux options : les modèles d'ingestion et les pipelines créés par l'utilisateur.
Dans le premier cas, vous pouvez analyser votre source de données et choisir les tables qui vous intéressent. Vous pouvez copier des tables entières dans le puits de votre choix.
Dans le second cas, vous devez créer une activité de copie séparée par table de base de données. Oui, c'est fastidieux, mais vous pouvez y associer une requête SQL. Cela peut vous faire gagner beaucoup d'espace de stockage si vous souhaitez supprimer des colonnes obsolètes ou filtrer certaines lignes (par exemple, sur la base de la date). Vous pouvez également vérifier si vous avez extrait correctement les colonnes de type datetime. Si ce n'est pas le cas, une conversion de type est nécessaire.
Transformation (ETL)
La deuxième étape de l'ETL est la transformation. Nous avons utilisé pour cela deux clusters Spark (l'un pour le développement et l'autre pour les jobs batch) gérés par l'environnement Databricks. Les carnets Databricks sont un moyen pratique d'écrire votre code en Python (ce dialecte est appelé Pyspark) ou de déboguer et de surveiller les travaux particuliers au sein du cluster en Scala.
Chargement (ETL)
La troisième et dernière étape est le chargement. La tâche consistait à placer plusieurs tables de dimensions et de faits stockées dans parquet dans l'entrepôt de données, qui est une base de données Azure SQL. De manière surprenante, ADF s'est avéré assez limité ici. Il n'est pas possible de charger automatiquement plusieurs fichiers parquet. Nous ne pouvons pas non plus définir des options de chargement importantes telles que la troncature, l'effacement ou l'écrasement des tables. Cela nous a conduit à placer les scripts de chargement avec un pilote JDBC dans les Databricks en utilisant le code suivant :
df_name.write \N
.format("jdbc") \n- \n- \n- \n- \n- \n- \c
.option("url", "jdbc:postgresql:dbserver") \N ----------------.
.option("dbtable", "schema.tablename") \N
.option("utilisateur", "nom d'utilisateur") \N ----------------.
.option("mot de passe", "mot de passe") \N ----------------.
.save()
Cette méthode offre de nombreuses possibilités. Elles sont décrites ici : JDBC vers d'autres bases de données - Spark 3.2.1 Documentation (apache.org)
Prochaine étape
Dans la troisième partie, je décrirai une autre histoire de cloud utilisant AWS pour aider le client à établir ses flux ETL et ses entrepôts de données.