Cloud Composer 3 est le service Apache Airflow géré de GCP. C’est une plateforme d’orchestration capable, mais son modèle de tarification front-charge les coûts d’une façon qui le rend peu adapté à de nombreux workloads dbt uniquement. Comprendre à la fois la structure des coûts et les capacités réelles vous aide à décider si vous payez pour une puissance d’orchestration que vous utilisez réellement.
La réalité des coûts
L’environnement minimum viable en production de Cloud Composer 3 tourne à environ 300-400 $/mois au ralenti, avant d’exécuter un seul DAG. Vous payez pour l’environnement Airflow géré que vous exécutiez 100 DAGs ou zéro. Augmentez la capacité pour plus de parallélisme ou des nœuds de workers plus grands, et les coûts grimpent rapidement.
Les coûts cachés s’accumulent par-dessus le prix de base. L’architecture de Composer implique plusieurs services GCP communiquant à travers les zones — le webserver Airflow, le scheduler, les workers, la base de données de métadonnées et le bucket GCS pour le stockage des DAG. Sans une configuration soigneuse, les coûts de transfert de données et de communication inter-services s’accumulent en plus de la base de calcul.
Les remises pour engagement peuvent modifier l’économie si vous êtes confiant dans votre choix de plateforme. Cloud Composer 3 offre jusqu’à 46% de réduction pour les engagements de 3 ans :
| Engagement | Minimum mensuel (approx.) | Remise |
|---|---|---|
| Pay-as-you-go | 300-400 $ | Aucune |
| Engagement 1 an | 220-290 $ | ~27% |
| Engagement 3 ans | 160-215 $ | ~46% |
Au tarif sur 3 ans, le coût mensuel minimum tombe à environ 160-215 $. Toujours substantiel comparé au coût inférieur à 5 $ de Cloud Run Jobs, mais potentiellement justifiable pour les équipes avec une vraie complexité d’orchestration. La question critique est de savoir si vous payez pour des capacités inutilisées.
Orchestration de pipelines de bout en bout
La force principale de Composer est l’orchestration de workflows qui s’étendent sur plusieurs systèmes. Lorsqu’un pipeline unique implique l’extraction de données depuis des API, la transformation dbt, la validation de la qualité des données et le reverse ETL vers des systèmes en aval, le modèle DAG d’Airflow exprime ces dépendances proprement.
Chaque étape peut utiliser l’opérateur approprié :
PythonOperatorpour les scripts d’extractionBashOperatorouKubernetesPodOperatorpour dbtBigQueryOperatorpour le post-traitement- Opérateurs personnalisés pour les poussées en aval
L’alternative — assembler plusieurs Cloud Run Jobs avec Cloud Workflows — devient difficile à gérer au-delà de trois ou quatre étapes. Le graphe de dépendances d’Airflow, la logique de réessai par tâche et le contexte partagé entre les tâches gèrent la complexité que les outils plus simples ont du mal à exprimer.
Capacités de backfill
Les backfills deviennent pertinents lorsque vous avez besoin de retraitement historique. Le mécanisme de catchup d’Airflow et la commande backfill vous permettent de réexécuter des pipelines pour des plages de dates spécifiques avec une gestion appropriée des dépendances. C’est genuinement difficile à reproduire en dehors d’Airflow.
Avec Cloud Run Jobs, implémenter un backfill signifie paramétrer votre invocation dbt et l’exécuter en boucle — gérer manuellement les plages de dates, suivre les plages qui ont réussi et gérer les échecs partiels. Pour les équipes qui ont besoin de retraiter des mois de données historiques après des changements de schéma ou des corrections de bugs, le backfill intégré d’Airflow vaut la prime.
La pertinence s’échelonne avec le volume de données et la fréquence des corrections. Si vous avez rarement besoin de retraitement historique, cette capacité est gaspillée. Si votre pipeline de données nécessite régulièrement des corrections rétroactives (courant dans les données publicitaires, la réconciliation financière ou tout domaine avec des corrections à arrivée tardive), le support de backfill devient essentiel.
Monitoring d’entreprise
L’interface utilisateur native d’Airflow fournit une visibilité opérationnelle que Cloud Logging n’a pas :
- Historique d’exécution par tâche. Voir chaque exécution de chaque tâche, avec des durées, des statuts et des logs accessibles depuis une seule interface.
- Graphiques de Gantt. Visualiser le parallélisme et identifier les goulots d’étranglement. Lorsque votre pipeline prend plus de temps que prévu, la vue Gantt montre quelles tâches sont sur le chemin critique.
- Visualisation des dépendances. La vue graphique DAG rend les pipelines complexes lisibles. Les nouveaux membres de l’équipe peuvent comprendre la structure du workflow d’un coup d’œil.
- Débogage des échecs. Cliquez sur une tâche échouée pour voir sa sortie de log, la réessayer individuellement ou la marquer comme réussie pour continuer le traitement en aval.
Pour les exigences de conformité mandatant des logs d’audit détaillés au niveau des tâches, la base de données de métadonnées d’Airflow capture les métadonnées d’exécution qui satisfont les auditeurs. Analyser les informations équivalentes depuis Cloud Logging est possible mais fastidieux et fragile. Si votre organisation a des exigences de conformité SOC 2, HIPAA ou similaires pour l’audit des pipelines, la piste d’audit intégrée de Composer simplifie la conversation avec les auditeurs.
KubernetesPodOperator
Le KubernetesPodOperator mérite une mention spécifique comme pattern qui justifie Composer même lorsque la logique d’orchestration est simple. Cet opérateur exécute dbt conteneurisé dans des pods Kubernetes isolés, fournissant :
- Isolation de sécurité. Le conteneur dbt ne peut pas accéder aux propres ressources de Composer. Chaque tâche s’exécute avec son propre compte de service et sa propre politique réseau.
- Flexibilité des ressources. Spécifiez le CPU et la mémoire par tâche. Un rafraîchissement de modèle léger obtient de petits pods ; un full-refresh lourd obtient de grands pods. Pas de sur-provisionnement de l’environnement de base pour les charges de pointe.
- Isolation des dépendances. Différents projets dbt peuvent exécuter différentes versions de dbt-core, Python et des packages d’adaptateur sans conflit.
Pour les équipes avec des exigences d’isolation strictes ou des besoins en ressources variables à travers différentes tâches dbt, KubernetesPodOperator résout des problèmes que Cloud Run Jobs gère moins élégamment. Le compromis est la complexité de la gestion de la configuration Kubernetes en plus de la configuration Airflow.
Quand Composer justifie son coût
La taille de l’équipe et le nombre de modèles sont de mauvais indicateurs pour savoir si vous avez besoin de Composer. Ce qui drive réellement la décision est de savoir si vos exigences de workflow dépassent ce que les outils plus simples peuvent exprimer :
- Les pipelines s’étendent sur l’extraction, la transformation et le chargement à travers plusieurs systèmes
- Vous avez besoin de capacités de backfill pour le retraitement historique
- Les exigences de conformité mandatent des pistes d’audit détaillées au niveau des tâches
- Plusieurs équipes ont besoin d’une visibilité partagée sur le statut des pipelines
- Vous exécutez déjà Composer pour d’autres workloads (le coût marginal est faible)
Le dernier point est important et souvent négligé. Si votre organisation exécute déjà Composer pour des workloads non-dbt, ajouter un DAG dbt est presque gratuit — le coût d’infrastructure fixe est déjà payé. L’argument des 300-400 $/mois contre Composer ne s’applique que lorsque Composer serait déployé exclusivement pour dbt.
Le cadre de décision fournit la comparaison complète avec Cloud Run Jobs et Cloud Workflows. Composer justifie son coût lorsque les capacités d’orchestration sont genuinement utilisées, pas lorsqu’un projet dbt atteint un certain seuil de taille arbitraire.