Apache Airflow¶
Version 3.3.1 — image dérivée de apache/airflow:3.3.1-python3.12.
Architecture¶
Airflow 3 a scindé l'ancien webserver. Quatre processus tournent :
| Service | Rôle |
|---|---|
airflow-apiserver |
Interface web et API d'exécution |
airflow-scheduler |
Planification et exécution des tâches (LocalExecutor) |
airflow-dag-processor |
Analyse des fichiers de DAG, processus séparé |
airflow-triggerer |
Tâches différées (deferrable operators) |
LocalExecutor plutôt que CeleryExecutor : la configuration de référence
embarque Redis et des workers, utiles pour répartir sur plusieurs machines.
Inutile ici, et deux services de plus à maintenir.
Image personnalisée¶
Deux ajouts seulement :
- dbt dans un virtualenv isolé (
/opt/dbt) — leurs dépendances entrent en conflit ; - Faker, pour le générateur synthétique.
Les connecteurs PostgreSQL et FAB ainsi que pandas sont déjà fournis par l'image officielle : les réinstaller casserait les versions validées.
Danger
Ne jamais ajouter /opt/dbt/bin au PATH. Voir
Dépannage.
Connexion à l'entrepôt¶
Injectée par variable d'environnement, sans passer par l'interface :
Planification par asset¶
Airflow 3 permet de déclencher un DAG sur la mise à jour de données plutôt que sur un horaire :
# Le producteur déclare ce qu'il produit
@task(outlets=[BRONZE_ECO2MIX])
def ingerer(): ...
# Le consommateur déclare ce qu'il attend
@dag(schedule=BRONZE_DEMO | BRONZE_ECO2MIX)
def transform_dbt(): ...
La transformation part quand la donnée arrive réellement, et non « une heure après, en espérant ». Les deux DAGs ne se connaissent pas.
ET contre OU
Une liste (schedule=[A, B]) signifie ET : tous les assets doivent
avoir bougé. Le | signifie OU. Se tromper produit un DAG qui ne
démarre plus jamais, sans lever d'erreur.
Accès¶
http://localhost:8080 par tunnel uniquement. AIRFLOW__API__BASE_URL vaut
http://localhost:8080 : y mettre un domaine public ferait rediriger
l'utilisateur vers une URL exposée.