Le choix de l’orchestration pour dbt sur GCP se résume souvent à un seul chiffre : 300 à 400 $ par mois. C’est le coût minimum de Cloud Composer 3 au repos, avant même d’exécuter un seul DAG. Pour beaucoup d’équipes, cela représente une part significative du budget de la plateforme data, dépensée en infrastructure plutôt qu’en création de valeur.
Cloud Run Jobs s’est discrètement imposé comme l’environnement d’exécution optimal de dbt pour la plupart des équipes. Associé à Cloud Scheduler pour la planification et Eventarc pour les déclenchements événementiels, il offre des fonctionnalités équivalentes pour moins de 5 $ par mois, souvent dans les limites du free tier. Mais Composer reste justifié dans certains scénarios. Ce guide propose un framework de décision basé sur vos besoins réels, pas sur des seuils de complexité arbitraires. Pour une vision plus globale de l’architecture, consultez mon aperçu de l’architecture data sur GCP.
La réalité des coûts : 5 $ contre 400 $ par mois
Le modèle tarifaire de Cloud Composer 3 concentre les coûts en amont. Vous payez pour l’environnement Airflow managé, que vous exécutiez 100 DAGs ou zéro. Le plus petit environnement viable en production coûte environ 300 à 400 $ par mois au repos. Ajoutez du parallélisme ou des workers plus puissants, et la facture grimpe vite.
Cloud Run Jobs inverse ce modèle. Vous payez à l’exécution : le temps de calcul pendant que votre conteneur tourne, plus un stockage minimal pour l’image. Un projet dbt typique exécuté quotidiennement (même avec des centaines de modèles) génère des coûts inférieurs à 5 $ par mois. De nombreuses équipes restent entièrement dans les limites du free tier.
L’écart se creuse quand on intègre les coûts cachés (voir mon guide d’optimisation des coûts BigQuery pour en savoir plus sur la maîtrise des dépenses GCP). L’architecture de Composer implique plusieurs services GCP qui communiquent entre zones ; sans configuration soignée, ces coûts de transfert de données s’accumulent.
Les remises sur engagement (committed use discounts) peuvent modifier l’équation si vous êtes sûr de votre choix de plateforme. Cloud Composer 3 offre jusqu’à 46 % de réduction pour un engagement de 3 ans. À ce tarif, le coût mensuel minimum descend à environ 160-215 $. C’est toujours conséquent, mais potentiellement justifiable pour les équipes dont la complexité d’orchestration le nécessite vraiment.
Ce que Cloud Run Jobs fait bien
Cloud Run Jobs supporte des durées d’exécution allant jusqu’à 168 heures (sept jours). Ce plafond dépasse largement n’importe quelle charge de transformation dbt raisonnable. L’idée que « Cloud Run ne convient qu’aux tâches rapides » reflète d’anciennes limitations qui ne s’appliquent plus.
La flexibilité des conteneurs vous donne un contrôle total sur l’environnement d’exécution : versions spécifiques de dbt-core et de l’adapter, dépendances Python, packages personnalisés. Les builds Docker multi-stage gardent les images légères tout en garantissant la reproductibilité. Fixez des versions explicites plutôt que d’utiliser des tags latest. Les écarts de déploiement causés par des versions flottantes génèrent plus de problèmes de debug que la commodité n’en vaut la peine.
L’authentification via Workload Identity élimine complètement les clés de service account. Le service account attaché à votre Cloud Run Job utilise automatiquement OAuth. Le fichier profiles.yml de dbt spécifie method: oauth, et le système gère les credentials. Pas de clés à renouveler, pas de secrets à exposer.
# profiles.yml pour Cloud Run Jobsmy_project: target: prod outputs: prod: type: bigquery method: oauth project: my-gcp-project dataset: analytics threads: 4 location: USLes intégrations natives couvrent les patterns de planification courants. Cloud Scheduler déclenche les jobs via des expressions cron ; le service account du scheduler a besoin du rôle roles/run.invoker sur le Cloud Run Job. Pour les patterns événementiels (exécuter dbt quand les données sources arrivent), Eventarc route les événements depuis les uploads Cloud Storage ou les audit logs BigQuery directement vers votre job.
Le monitoring s’appuie sur ce que Cloud Run fournit nativement. Les sorties stdout et stderr du conteneur arrivent dans Cloud Logging. Cloud Monitoring capture le nombre d’exécutions, les durées et l’utilisation des ressources. Configurez des alertes basées sur les logs pour les patterns severity>=ERROR et des alertes métriques pour les échecs de jobs. Le code de sortie de dbt (non-zéro en cas d’échec) déclenche le mécanisme de retry intégré de Cloud Run ; --max-retries=2 gère les erreurs transitoires sans logique personnalisée.
Quand Cloud Composer justifie son coût
La valeur de Composer apparaît quand la complexité de l’orchestration l’exige réellement. La taille de l’équipe et le nombre de modèles sont de mauvais indicateurs ; ce qui détermine vraiment la décision, c’est de savoir si vos besoins dépassent ce que des outils plus simples peuvent exprimer.
L’orchestration de pipelines de bout en bout représente la force principale de Composer. Quand un workflow unique couvre l’extraction de données depuis des APIs, la transformation dbt, la validation de la qualité des données et le reverse ETL vers les systèmes en aval, le modèle DAG d’Airflow exprime ces dépendances proprement. Chaque étape peut utiliser l’opérateur approprié : PythonOperator pour les scripts d’extraction, BashOperator ou KubernetesPodOperator pour dbt, BigQueryOperator pour le post-traitement. L’alternative (assembler plusieurs Cloud Run Jobs avec Workflows) devient difficile à maintenir au-delà de trois ou quatre étapes.
Les capacités de backfill deviennent pertinentes quand vous avez besoin de retraitement historique. Le mécanisme de catchup d’Airflow et la commande backfill permettent de relancer des pipelines pour des plages de dates spécifiques avec une gestion correcte des dépendances. Cloud Run Jobs n’a pas d’équivalent ; il faudrait implémenter la logique de backfill vous-même, typiquement en paramétrant votre invocation dbt et en l’exécutant en boucle.
Le monitoring enterprise via l’interface native d’Airflow offre une visibilité que Cloud Logging n’a pas. Historique d’exécution au niveau des tâches, diagrammes de Gantt montrant le parallélisme, visualisation claire des dépendances et des échecs. Tout cela prend de la valeur à mesure que la complexité des pipelines augmente. Pour les exigences de conformité imposant des audit logs détaillés au niveau des tâches, la base de données d’Airflow capture des métadonnées d’exécution qui satisfont les auditeurs d’une manière que le parsing de Cloud Logging ne permet souvent pas.
KubernetesPodOperator mérite une mention spécifique. Ce pattern exécute dbt conteneurisé dans des pods Kubernetes isolés, offrant une isolation de sécurité (le conteneur dbt ne peut pas accéder aux ressources propres de Composer) et une flexibilité de ressources (CPU et mémoire spécifiés par tâche). Pour les équipes ayant des exigences strictes d’isolation ou des besoins de ressources variables selon les jobs dbt, ce pattern justifie Composer même quand la logique d’orchestration elle-même est simple.
Le compromis : Cloud Workflows plus Cloud Run
Entre « utiliser Cloud Scheduler » et « déployer Cloud Composer » se trouve Cloud Workflows : une orchestration serverless à 0,01 $ pour 1 000 étapes. Cette approche hybride gère les pipelines multi-étapes sans les coûts fixes de Composer.
Workflows offre de la logique conditionnelle, de l’exécution parallèle, de la gestion d’erreurs et des politiques de retry. Vous pouvez appeler des Cloud Run Jobs, des Cloud Functions, des endpoints HTTP et diverses APIs GCP. La syntaxe YAML exprime les dépendances et les branchements :
main: steps: - run_extraction: call: http.post args: url: https://extraction-job-url/ result: extraction_result - check_extraction: switch: - condition: ${extraction_result.body.status == "success"} next: run_dbt - condition: true raise: "Extraction failed" - run_dbt: call: http.post args: url: https://dbt-job-url/ result: dbt_result - notify: call: http.post args: url: https://slack-webhook/ body: text: "Pipeline completed"Ce pattern convient aux équipes qui ont besoin d’une orchestration au-delà de la simple planification (séquencer plusieurs jobs, gérer les échecs proprement, brancher selon les résultats) mais qui ne veulent pas payer le minimum mensuel de Composer. Le compromis : vous perdez l’interface d’Airflow, la commande backfill et l’écosystème d’opérateurs. Pour des pipelines de moins de dix étapes sans besoin de retraitement historique, ce compromis penche souvent en faveur de Workflows.
Patterns d’implémentation pour Cloud Run Jobs
Une approche à deux repositories sépare efficacement les responsabilités (mon guide de déploiement Cloud Run pour dbt détaille la mise en place complète). Un repository contient votre projet dbt : modèles, tests, macros, documentation. L’autre contient la définition de l’image Docker et la configuration de déploiement. Cette séparation permet des cycles de développement indépendants. Les analystes data itèrent sur le SQL sans toucher à l’infrastructure, tandis que les platform engineers mettent à jour le runtime sans conflits de merge dans les fichiers de modèles.
Un Dockerfile typique pour cette configuration :
FROM python:3.11-slim as builder
WORKDIR /appCOPY requirements.txt .RUN pip install --no-cache-dir -r requirements.txt
FROM python:3.11-slim
WORKDIR /appCOPY --from=builder /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packagesCOPY --from=builder /usr/local/bin /usr/local/bin
# Copie du projet dbt (ou clone au runtime)COPY dbt_project/ ./dbt_project/COPY profiles.yml ./
ENTRYPOINT ["dbt"]CMD ["run", "--project-dir", "/app/dbt_project"]Fixez les versions explicitement dans requirements.txt :
dbt-core==1.9.1dbt-bigquery==1.9.0Pour les secrets au-delà de l’authentification BigQuery (clés API pour des packages externes, tokens GitHub pour des packages privés), stockez-les dans Secret Manager. Montez les secrets comme variables d’environnement dans la configuration de votre Cloud Run Job plutôt que de les intégrer dans les images.
Les déclencheurs événementiels via Eventarc permettent des patterns comme « exécuter dbt quand les données sources arrivent ». Configurez un trigger Eventarc pour surveiller la création d’objets dans votre bucket Cloud Storage de données brutes, en filtrant sur des préfixes ou des patterns de fichiers spécifiques. Le trigger invoque votre Cloud Run Job, qui peut utiliser le payload de l’événement pour déterminer quels modèles doivent être rafraîchis.
Framework de décision
Commencez avec Cloud Run Jobs sauf si vous avez des besoins spécifiques qui imposent autre chose. La différence de coût est substantielle, et pour la plupart des workflows dbt (même les plus volumineux), Cloud Run Jobs fournit tout ce qu’il faut.
Choisissez Cloud Run Jobs quand :
- Votre projet dbt compte moins de 50 modèles avec des dépendances simples
- La planification est le principal besoin d’orchestration (exécutions quotidiennes, horaires ou événementielles)
- Vous privilégiez la simplicité plutôt que des fonctionnalités d’orchestration que vous n’utiliserez pas
- L’efficacité des coûts compte plus qu’un confort opérationnel marginal
- Votre équipe est petite et n’a pas besoin de la visibilité multi-utilisateurs d’Airflow
Choisissez Cloud Composer quand :
- Les pipelines couvrent l’extraction, la transformation et le chargement sur plusieurs systèmes
- Vous avez besoin de backfill pour le retraitement historique
- Les exigences de conformité imposent des audit trails détaillés au niveau des tâches
- Plusieurs équipes ont besoin de visibilité sur l’état des pipelines partagés
- Vous utilisez déjà Composer pour d’autres workloads (le coût marginal est faible)
Choisissez Workflows plus Cloud Run quand :
- Vous avez besoin d’une orchestration multi-étapes avec logique conditionnelle
- Les besoins de backfill sont minimes ou gérables manuellement
- La sensibilité aux coûts exclut Composer
- La complexité du pipeline dépasse ce que Cloud Scheduler seul peut exprimer
- Vous êtes à l’aise sans l’interface et l’écosystème d’Airflow
La plateforme a considérablement évolué. Les recommandations datant de 2023 ou avant reflètent souvent des limitations (plafonds de durée d’exécution, intégrations manquantes, outillage immature) qui ne s’appliquent plus. Cloud Run Jobs en 2026 gère des charges de travail qui nécessitaient auparavant Composer. Évaluez selon les capacités actuelles, pas selon des suppositions dépassées.
Mieux vaut commencer simple
La plupart des équipes s’en sortent bien en démarrant avec Cloud Run Jobs déclenché par Cloud Scheduler, puis en ajoutant de la complexité uniquement quand elles rencontrent une vraie limitation. Cloud Workflows gère l’orchestration multi-étapes sans les coûts fixes de Composer. Composer devient rentable quand vous avez besoin de backfills, de monitoring enterprise ou de pipelines multi-systèmes complexes. Laisser des besoins clairs guider la décision évite le schéma classique de payer pour des fonctionnalités qui restent inutilisées.
L’approche incrémentale force aussi à clarifier quelles fonctionnalités d’orchestration vous utilisez vraiment. Les 300-400 $ d’économies mensuelles s’accumulent ; sur un an, cela représente 3 600 à 4 800 $ qui pourraient financer du travail supplémentaire en data engineering, de meilleurs outils, ou simplement de meilleures marges.
Adaptez votre choix d’orchestration à votre complexité réelle. Pour la plupart des déploiements dbt sur GCP, Cloud Run Jobs est la bonne solution.