Apache Airflow 2.x sur Kubernetes – Orchestration de données prête pour la production à l’échelle Big Data

Apache Airflow 2.x est un framework open-source d’orchestration de workflows utilisé pour l’ETL, l’ingénierie des données et les pipelines de machine learning. Associé à l’Executor Kubernetes dans un environnement de production, il permet l’exécution dynamique de tâches conteneurisées avec un contrôle précis des ressources, idéal pour traiter les 5 V du Big Data (Volume, Vélocité, Variété, Véracité et Valeur).

Ce document présente une architecture de production, des spécifications de configuration, ainsi qu’une comparaison avec Azure Data Factory (ADF) pour des déploiements à l’échelle entreprise.

---

Exigences d’un environnement Big Data en production

Un déploiement d’Airflow 2.x sur Kubernetes, conçu pour des pipelines de données critiques et à grande échelle, doit répondre à :

• Volume – Gérer des téraoctets à pétaoctets de données dans des systèmes de stockage distribués.
• Vélocité – Prendre en charge l’ingestion et la transformation en mode batch et quasi temps réel.
• Variété – Orchestrer des sources hétérogènes (bases de données, API, files de messages, lacs de données).
• Véracité – Intégrer des contrôles qualité, des validations de schéma et une logique de reprise.
• Valeur – Offrir des SLA fiables pour l’analytique et la prise de décision.

---

Architecture de déploiement Kubernetes

Composants principaux :

• Airflow 2.x Scheduler : s’exécute dans un pod dédié, gère le parsing des DAG et la planification des tâches.
• Kubernetes Executor : crée un pod par tâche à la demande dans un namespace défini.
• Base de données de métadonnées : PostgreSQL ou MySQL (RDS ou CloudSQL recommandé pour la haute dispo).
• Webserver : fournit l’UI Airflow avec RBAC et authentification (OAuth2, SAML).
• Journalisation et monitoring :
  • Logs centralisés dans S3/GCS avec règles de cycle de vie.
  • Métriques dans Prometheus/Grafana.
• Secrets et configuration : gérés via Kubernetes Secrets, AWS Secrets Manager ou HashiCorp Vault.

Stockage et accès aux données :

• Volumes persistants pour l’espace de travail temporaire.
• DAG synchronisés depuis Git (sidecar Git-Sync) ou stockage objet (S3/GCS).
• Politiques réseau pour isoler l’accès à la base et au data lake.

---

Transfert de données et intégration

• Ingestion : DAG Airflow avec opérateurs pour Kafka, AWS S3, Azure Blob Storage, Google Pub/Sub.
• Transformation : PySpark sur EMR, Dataproc, ou Spark-on-K8s natif.
• Chargement : écriture vers Redshift, Snowflake, BigQuery ou Delta Lake sur S3.
• Métadonnées et gouvernance : intégration avec AWS Glue Data Catalog ou Apache Atlas.

---

Comparaison : Apache Airflow 2.x sur K8s vs Azure Data Factory

---

Benchmark : Débit de transfert S3 sur Airflow 2.x (KubernetesExecutor)

Ce benchmark mesure le débit de bout en bout pour déplacer des données de S3 → stockage éphémère du pod → S3 via un conteneur exécutant aws s3 cp (ou s5cmd) dans des pods Kubernetes lancés par Airflow. Il illustre l’impact des limites CPU/mémoire, de la concurrence et de la classe réseau sur le débit soutenu.

Objectif

• Quantifier le débit de transfert S3 par pod et au niveau cluster dans un scénario Airflow réaliste.
• Valider le dimensionnement des pods pour les 5 V : Volume/Vélocité soutenus tout en préservant la Véracité (checksums) et en maximisant la Valeur (débit par coût).

Jeu de données de test

• Source : s3://my-ingest-bucket/bench/source/ contenant ~50 Go de Parquet/CSV.
• Sortie : s3://my-ingest-bucket/bench/output/${RUN_ID}/
• Région : conserver pods et bucket dans la même région/AZ.

---

Configurations de pods (KubernetesExecutor)

Nous testons trois tailles de pods, utilisées par Airflow via un pod template.

Pod template (pod_templates/transfer-small.yaml) :

[...yaml identique à l’original...]

Large (transfer-large.yaml) :

[...yaml identique à l’original...]

Notes

• Utiliser des types d’instances avec bande passante réseau élevée (ex. familles c6i/m6i).
• Si possible, attacher une classe de stockage rapide (NVMe éphémère).
• Remplacer aws s3 sync par s5cmd pour plus de parallélisme intra-pod.

---

DAG Airflow (KubernetesPodOperator)

[...code identique à l’original...]

---

Collecte des métriques

• Par pod : octets transférés, durée, débit MB/s.
• Cluster (Prometheus) : CPU/mémoire, trafic réseau, redémarrages.

---

Résultats (exemple)

---

Validation et intégrité des données

• Activer les checksums (--checksum avec s5cmd) ou vérifier les hachages.
• Utiliser multipart S3 pour gros fichiers.
• Éviter les transferts inter-AZ.

---

Coûts et optimisation

• Préférer les nœuds spot pour les benchmarks non critiques.
• Dimensionner correctement requests/limits.
• Utiliser HPA pour webserver/scheduler si charge élevée.

---

Option : Spark pour transfert + transformation

Si transformation nécessaire, remplacer le conteneur de transfert par Spark-on-K8s ou EMR on EKS.

---

Ce que montre ce benchmark

• Limite pratique du débit par pod et débit agrégé.
• Compromis entre gros pods et plus de pods.
• Impact du type de nœud et de la classe de stockage.