Airflow Pipeline : Migration et Nettoyage des Données Bigtable vers Snowflake avec Airflow 2.9 sur Kubernetes

Ce document présente une mise en œuvre récente d’un pipeline de données permettant l’extraction planifiée, la validation, la transformation et le chargement de séries temporelles depuis Google Bigtable vers Snowflake, à l’aide d’Apache Airflow 2.9 déployé sur Kubernetes avec Horizontal Pod Autoscaling (HPA). L’objectif était de traiter quotidiennement de grands volumes de données par lots, avec nettoyage, tout en minimisant la charge opérationnelle.

---

Contexte

Les données sources représentaient environ 1,2 milliard d’enregistrements stockés dans Google Bigtable, avec des volumes journaliers compris entre 3 et 10 millions de lignes. Les données devaient être transférées vers Snowflake, où elles alimentaient des analyses aval et des tableaux de bord. Les contraintes identifiées étaient les suivantes :

• Évolution du schéma dans le temps
• Alignement de timestamps imbriqués (données temporelles)
• Charge multi-régions avec débit variable
• Besoin de portabilité cloud et de faible complexité opérationnelle

---

Vue d’Ensemble de l’Architecture

Le pipeline a été construit avec les composants suivants :

• Apache Airflow 2.9 avec l’exécuteur KubernetesExecutor
• EKS (Elastic Kubernetes Service) avec HPA activé par template de pod
• Cloud Functions et Pub/Sub pour les déclenchements
• Parquet et PyArrow pour les entrées/sorties
• Snowflake comme cible finale avec COPY INTO depuis un stage externe (S3)

Une pile de logs mutualisée (FluentBit → OpenSearch) permettait l’audit et la visualisation des métriques.

---

Étapes du Pipeline

1. Extraction depuis Bigtable

Chaque exécution était déclenchée par une Cloud Function via Pub/Sub, notifiant Airflow de l’arrivée d’un nouveau lot. Un client Python pour Bigtable effectuait alors des scans limités et générait des fichiers Parquet compressés dans GCS à l’aide de PyArrow.

• L’extraction était parallélisée selon des plages de clés de ligne.
• La logique de repli et de reprise était implémentée via des opérateurs Airflow personnalisés.

2. Nettoyage et Validation des Données

Chaque segment Parquet était ensuite traité dans un pod dédié avec les règles suivantes :

• Suppression des lignes avec champs requis manquants
• Normalisation des dates/heures en UTC
• Forçage des types selon un schéma JSON versionné dynamiquement
• Déduplication via des clés de hachage composites
• Ajout de métadonnées (ID de lot, timestamp de traitement)

Cette étape utilisait pandas et pyarrow, exécutée dans des pods Airflow gérés par KubernetesExecutor, dimensionnés automatiquement via HPA (CPU/mémoire).

3. Staging et Chargement dans Snowflake

Les données nettoyées étaient transférées vers un bucket S3 de staging, via des opérations gsutil rsync parallèles (multi-cloud). Le chargement final dans Snowflake était effectué via COPY INTO, déclenché par des hooks Airflow.

• Le partitionnement par date et région permettait un chargement optimisé.
• La supervision était assurée via des callbacks Airflow et des métriques Prometheus personnalisées.

---

Pourquoi Airflow 2.9 et Kubernetes HPA ?

• Airflow 2.9 apportait des améliorations importantes aux décorateurs TaskFlow, à l’exécuteur Kubernetes natif, ainsi qu’au suivi des dépendances.
• HPA permettait un traitement économique et élastique — les DAGs fonctionnaient à faible coût en heures creuses, et montaient en charge sans réservation de ressources anticipée.
• Le déploiement sur Kubernetes permettait d’isoler les pannes par pod et de mettre à jour les images d’opérateurs indépendamment.

---

Résultats

---

Résultats

• Moyenne de lignes traitées / jour : ~7 millions
• Durée moyenne d’un DAG : ~28 minutes
• Pics de pods parallèles (via HPA) : 96
• Taux d’erreur lors de la validation : < 0,04 %
• Débit vers Snowflake (ingestion) : ~9–11 millions de lignes/min

---

Enseignements Clés

• La vérification explicite des types et le versioning du schéma ont permis d’éviter des erreurs d’ingestion liées à des changements en amont.
• La structuration en TaskGroups a amélioré la lisibilité du DAG et la granularité des reprises.
• La synchronisation multi-cloud GCS → S3 s’est avérée fiable, mais nécessite une gestion des coûts d’égresse régionale.
• L’intégration de Prometheus/OpenTelemetry a facilité l’analyse du comportement d’autoscaling.

---

Conclusion

Cette mise en œuvre illustre un modèle efficace de migration de données évolutif et résilient de Google Bigtable vers Snowflake, en utilisant Airflow 2.9 sur Kubernetes. L’architecture a démontré sa capacité à gérer de gros volumes, des charges variables et des exigences élevées de qualité des données — avec un effort opérationnel contenu.

---

🔍 Besoin d’aide pour concevoir des pipelines ETL résilients sur Kubernetes ?

Nous accompagnons les équipes dans la mise en place de pipelines Airflow, Snowflake et infrastructures multi-cloud. Contactez-nous pour un audit ou une assistance technique.