Cloud Run Jobs pour dbt

Cloud Run Jobs, combiné à Cloud Scheduler pour la planification temporelle et Eventarc pour les déclencheurs event-driven, offre des capacités de planification et d’exécution comparables aux orchestrateurs gérés pour moins de 5 $/mois — souvent dans les limites du niveau gratuit. Des temps d’exécution jusqu’à 168 heures (sept jours) accommodent n’importe quelle charge de travail de transformation dbt réaliste. Les projets avec des centaines de modèles s’exécutant quotidiennement génèrent généralement des coûts inférieurs à 5 $/mois.

Configuration du conteneur

La flexibilité du conteneur vous donne un contrôle total sur l’environnement d’exécution : versions spécifiques de dbt-core et d’adaptateurs, dépendances Python, packages personnalisés. Un build Docker multi-étapes garde les images petites tout en assurant la reproductibilité :

FROM python:3.11-slim as builder

WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

FROM python:3.11-slim

WORKDIR /app
COPY --from=builder /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages
COPY --from=builder /usr/local/bin /usr/local/bin

# Copy dbt project (or clone at runtime)
COPY dbt_project/ ./dbt_project/
COPY profiles.yml ./

ENTRYPOINT ["dbt"]
CMD ["run", "--project-dir", "/app/dbt_project"]

Épinglez des versions explicites dans requirements.txt :

dbt-core==1.9.1
dbt-bigquery==1.9.0

Épinglez les versions plutôt que d’utiliser les tags latest. La variance de déploiement due aux versions flottantes cause plus de maux de tête de débogage que la commodité ne le justifie. Une approche à deux dépôts sépare efficacement les préoccupations : un dépôt 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 data analysts itèrent sur le SQL sans toucher à l’infrastructure, tandis que les ingénieurs platform mettent à jour l’exécution sans conflits de merge dans les fichiers de modèles.

Authentification via Workload Identity

L’authentification via Workload Identity élimine entièrement les clés de comptes de service. Le compte de service attaché à votre Cloud Run Job utilise OAuth automatiquement. Le profiles.yml dbt spécifie method: oauth, et le système gère les identifiants. Pas de clés à faire tourner, pas de secrets à faire fuiter.

# profiles.yml for Cloud Run Jobs
my_project:
  target: prod
  outputs:
    prod:
      type: bigquery
      method: oauth
      project: my-gcp-project
      dataset: analytics
      threads: 4
      location: US

C’est la même chaîne de résolution ADC en action — dans Cloud Run, le service de métadonnées du compte de service attaché fournit les identifiants automatiquement (étape 3 de la chaîne). Pas de variable GOOGLE_APPLICATION_CREDENTIALS nécessaire, pas de fichier de clé à gérer.

Pour les secrets au-delà de l’authentification BigQuery (clés API pour les packages externes, tokens GitHub pour les packages privés), stockez-les dans Secret Manager. Montez les secrets comme variables d’environnement dans votre configuration Cloud Run Job plutôt que de les intégrer dans les images.

Patterns de planification

Les intégrations natives couvrent les patterns de planification courants sans couche d’orchestration supplémentaire :

Planification basée sur cron. Cloud Scheduler déclenche les tâches selon des expressions cron. Le compte de service du scheduler a besoin de roles/run.invoker sur le Cloud Run Job. Cela gère la grande majorité des besoins de planification dbt : exécutions quotidiennes, rafraîchissements horaires ou toute cadence fixe.

Déclencheurs event-driven. Eventarc route les événements des uploads Cloud Storage ou des logs d’audit BigQuery directement vers votre tâche. Configurez un déclencheur Eventarc pour surveiller la création d’objets Cloud Storage dans votre bucket de données brutes, en filtrant sur des préfixes ou des patterns de fichiers spécifiques. Le déclencheur invoque votre Cloud Run Job, qui peut utiliser le payload de l’événement pour déterminer quels modèles doivent être rafraîchis. Ce pattern permet “exécuter dbt lorsque les données source arrivent” sans polling ni services intermédiaires.

Gestion des réessais. Le code de sortie dbt (non-zéro en cas d’échec) déclenche le mécanisme de réessai intégré de Cloud Run. Définir --max-retries=2 gère les échecs transitoires sans logique personnalisée. Pour la plupart des équipes, c’est une gestion d’erreurs suffisante — pas besoin des politiques de réessai plus sophistiquées d’Airflow à moins que vos modes d’échec soient genuinement complexes.

Monitoring

Le monitoring s’appuie sur ce que Cloud Run fournit automatiquement, ce qui couvre la plupart des besoins opérationnels :

Le stdout et stderr du conteneur vont dans Cloud Logging
Cloud Monitoring capture les comptages d’exécutions, les durées et l’utilisation des ressources
Configurez des alertes basées sur les logs pour les patterns severity>=ERROR
Définissez des alertes basées sur les métriques pour les échecs de tâches

L’écart par rapport à Cloud Composer est la visibilité, pas la capacité. Cloud Logging capture tout, mais manque de l’historique d’exécution par tâche d’Airflow, des graphiques de Gantt et de la visualisation des dépendances. Pour un seul projet dbt s’exécutant sur un planning, Cloud Logging est plus que suffisant. Le compromis devient réel lorsque plusieurs équipes ont besoin d’une visibilité partagée sur le statut des pipelines.

Profil de coût

Le modèle de tarification est le paiement à l’exécution : temps de calcul pendant l’exécution de votre conteneur, plus un stockage minimal pour l’image du conteneur. Il n’y a pas de coût au ralenti. Un projet dbt typique s’exécutant quotidiennement — même un avec des centaines de modèles — génère des coûts inférieurs à 5 $/mois. De nombreuses équipes restent entièrement dans les limites du niveau gratuit.

Comparez cela au minimum de 300-400 $/mois de Cloud Composer 3 tournant au ralenti, avant qu’un seul DAG s’exécute. L’écart se creuse encore lorsque vous tenez compte des coûts cachés : l’architecture de Composer implique plusieurs services GCP communiquant à travers les zones, et sans une configuration soigneuse, les coûts de transfert de données s’accumulent.

Sur un an, les économies mensuelles de 300-400 $ se composent à 3 600-4 800 $ — suffisant pour financer du travail supplémentaire d’ingénierie des données, de meilleurs outils, ou simplement des marges plus saines. Le cadre de décision aide à déterminer quand cet avantage de coût l’emporte sur les fonctionnalités d’orchestration que vous abandonneriez.

Quand Cloud Run Jobs est insuffisant

Cloud Run Jobs gère bien l’exécution dbt, mais ce n’est pas un orchestrateur généraliste. Les limitations qui poussent les équipes vers des outils plus capables :

Pas de mécanisme de backfill. Le catchup et la commande backfill d’Airflow permettent de réexécuter des pipelines pour des plages de dates spécifiques avec une gestion appropriée des dépendances. Avec Cloud Run Jobs, vous devriez implémenter la logique de backfill vous-même, généralement en paramétrant votre invocation dbt et en l’exécutant en boucle.
Pas d’orchestration multi-étapes. Si un seul workflow s’étend sur l’extraction, la transformation, la validation et le reverse ETL, assembler plusieurs Cloud Run Jobs avec Cloud Workflows devient le compromis — mais au-delà de trois ou quatre étapes, le modèle DAG d’Airflow exprime plus proprement les dépendances.
Pas d’interface partagée pour la visibilité des pipelines. Cloud Logging est un outil de recherche, pas un tableau de bord opérationnel. Lorsque plusieurs équipes ont besoin de voir “ce qui a été exécuté, quand, et si ça a réussi ?” d’un coup d’œil, l’interface native d’Airflow le fournit sans tableau de bord personnalisé.

Pour la plupart des déploiements dbt uniquement sur GCP, ces limitations sont théoriques plutôt que pratiques. Ajouter de la complexité d’orchestration n’est justifié que lorsqu’une vraie contrainte est rencontrée.