Nous vous prions d'excuser notre anglicisme, car il est souvent difficile de trouver une traduction française précise de certains concepts techniques sans les dénaturer.
Airflow est un outil très populaire en data engineering. Il permet orchestrer les flux de données encore appelés data pipelines qu'il représente sous forme de DAG pour Directed Acyclic Graph. Dans cet article, nous présenterons Airflow sous une forme proche de celle recommandée pour de la mise en production.
A - Pourquoi avez-vous besoin d’un orchestrateur de pipeline de données ?
Supposons que vous mettez en place une pipeline de données basique qui fait un job d’ETL (Extract Transform Load).
Extraction de données de 02 sources externes: par exemple des données financières sur des individus provenant d’une API externe et des données socio-démographiques provenant d’une base de données MySQL interne.
Transformation de ces données grâce avec SPARK. Ici nous voudrions par exemple calculer un ensemble d’agrégats nous basant sur les données financières et les joindre aux données socio-démographiques récupérées dans l'étape d'extraction afin d’avoir une seule table de données.
Nous avons choisi l'outil SPARK pour le calcul d'aggrégats car nous partons avec l'hypothèse que les données sont volumineuses. SPARK est donc un outil qui va faciliter nos transformations de données en s'appuyant sur le paradigme de calculs distribués.
Load: cette partie consistera donc à sauvergarder cette nouvelle table dans un data warehousse par exemple BigQuery si on est sur Google Cloud Plateform.
On pourrait aussi utiliser Snowflake ou Redshift ou encore Databricks pour la partie Warehoussing.
Que ferait-on si chacune de ces tâches ETL devrait être exécutées chaque jours à 23 heures ? Que ferait-ont si chacune de ces tâches ETL échoue ? Et enfin que ferait-on si nous avions des centaines de pipelines de données ?
Airflow vient donc à la rescousse et permet de gérer automatiquement et à l’échelle l’orchestration (lancement, gestions des échecs) pour des centaines de tâches et des milliers de pipelines de données. Airflow nous fournit aussi une interface graphique permettant à toute une équipe équipe de visualiser les pipelines de données et les tâches de manière centralisée.
Plus exactement nous pouvons définir Airflow comme une plateforme open-source qui permet de créer programatiquement avec le langage Python, des pipelines de données, de programmer leur exécution et de les monitorer.
Airflow n'est cependant pas une solution de streaming (donc on ne doit pas y orchestrer des tâches qui s'exécutent chaque seconde). Il n’est pas non plus une solution de traitements de données, c’est-à-dire que le but de Airflow ce n’est pas de faire de gros traitements de données mais plutôt de déclencher les outils qui doivent traiter de la donnée. En tenir compte nous permet de ne pas avoir des problèmes de mémoire.
B - Les différentes composantes d’Airflow
Les composantes indispensables pour le bon fonctionnement d'Airflow sont:
Le Web server: Un serveur web python fait avec le framework Flask. Il vous permet d’avoir une interface graphique pour monitorer vos pipelines de données.
Scheduler: C’est un composant critique qui est en charge de scheduler (programmer l’exécution) des tâches et des pipelines de données. Il soumet les tâches à exécuter à l’Executor.
Le metabase: Il s’agit d’une base de données compatible avec le package SQLAlchemy (PostgreSQL, MySQL, SQLServer etc …) et qui est en charge de sauvergarder les métadonnées par rapport aux utilisateurs, aux tâches, aux pipelines de données etc …
Le folder dags: qui contient nos pipelines de données et qui sera lu par le “scheduler” pour savoir quelles pipeline de données ou quelles tâches doivent être exécutées à quel moment.
L’executor: Ce n’est pas un composant à part. Il fait partie du “scheduler” et n’exécute pas vraiment les tâches mais définit comment elle seront et où elles seront exécutées. Nous pouvons en guise d’exemple citer: le kubernetes executor et le celery executor. Pour le Kubernetes executor, il est constituer d’une file ou queue qui défini l’ordre d’exécution des tâches et de pods d’un cluster kubernetes qui sont les processus qui executent les tâches. Par contre pour le Celery Executor il est constitué d’une queue pour l’ordre d’exécution et de worker qui sont les machines sur lesquelles les tâches seront exécutées.
C - Le fonctionnement de Airflow
Après installation d’Airflow vous écrivez vos Dags et les mettez dans le folder Dags, ce répertoire est parcouru chaque 05 minutes par Airflow pour détecter de nouvelles pipelines de données ou chaque 30 secondes pour déterminer des changements dans les pipelines existantes.
Le scheduler exécute le DAG et crée un objet “dag run”. Il prend ensuite la première tâche de ce “dag run” en crée une instance qui est schédulée et envoyée dans la queue pour être exécutée par un pod kubernetes ou un celery worker. Le scheduler peut donc passer à la prochaine tâche.
Le scheduler communique avec le metabase où il stocke ses informations (dags runs, task instances etc …) et le web server communique avec ce même metabase pour lire les informations où y écrire les actions que nous effectuons depuis l’interface graphique d’Airflow.
Pour aller en production nous pouvons opter pour le Kubernetes Executor ou pour le Celery Executor d'Airflow. SI nous optons pour le premier, les workers Airflow sont des Pods Kubernetes. Mais si nous optons pour le second, les workers sont plutôt des celery workers. La Queue quant à elle peut être faites avec Redis ou RabbitMQ. Celle que nous utilisons dans nos docker compose comme vous le verrez lors de notre prochain article est une base de données Redis. Pareil la Metabase est PostgreSQL dans notre schéma mais vous pouvez utiliser toute base de données SQL compatible avec SQLAlchemy.
