Déclencheurs dbt événementiels avec Eventarc

Les exécutions dbt planifiées s’effectuent à intervalle fixe, que de nouvelles données soient disponibles ou non. Une fréquence trop élevée traite zéro nouvelles lignes la plupart du temps ; une fréquence trop faible retarde les données qui sont arrivées peu après la dernière exécution.

Eventarc déclenche dbt lorsque des données en amont arrivent réellement — « exécuter dbt quand il y a quelque chose de nouveau à transformer » plutôt que selon un planning fixe. C’est de l’orchestration événementielle sans DAGs Airflow ni boucles de polling : un service GCP achemine les événements vers un Cloud Run Job.

Déclencheurs Cloud Storage

Le pattern le plus courant : déclencher dbt lorsqu’un fichier est déposé dans un bucket GCS. Cela convient aux pipelines où les données en amont sont livrées sous forme de fichiers — exports CSV, dumps Parquet depuis des systèmes externes, ou sorties d’outils d’extraction.

gcloud eventarc triggers create dbt-on-upload \
    --location=us-central1 \
    --destination-run-job=dbt-daily \
    --destination-run-region=us-central1 \
    --event-filters="type=google.cloud.storage.object.v1.finalized" \
    --event-filters="bucket=your-data-bucket" \
    --service-account=dbt-runner@PROJECT_ID.iam.gserviceaccount.com

L’événement object.v1.finalized se déclenche lorsqu’un objet est créé ou écrasé dans le bucket. Chaque upload de fichier déclenche votre job dbt. Pour les buckets à écritures fréquentes, cela peut signifier de nombreuses invocations dbt — ce qui peut ou non être souhaitable.

Pour affiner le périmètre, Eventarc prend en charge la correspondance de patterns de chemin. Si seuls les fichiers dans un préfixe spécifique doivent déclencher dbt :

gcloud eventarc triggers create dbt-on-raw-data \
    --location=us-central1 \
    --destination-run-job=dbt-daily \
    --destination-run-region=us-central1 \
    --event-filters="type=google.cloud.storage.object.v1.finalized" \
    --event-filters="bucket=your-data-bucket" \
    --event-filters-path-pattern="objectId=/raw/daily/*" \
    --service-account=dbt-runner@PROJECT_ID.iam.gserviceaccount.com

Cela ne se déclenche que lorsque des objets arrivent sous le préfixe raw/daily/. Les fichiers dans d’autres préfixes — sauvegardes, archives, staging — sont ignorés.

Déclencheurs de journaux d’audit BigQuery

Pour les pipelines où les données en amont arrivent via des jobs de chargement BigQuery (et non des uploads de fichiers), Eventarc peut surveiller les journaux d’audit BigQuery :

gcloud eventarc triggers create dbt-on-bq-load \
    --location=us-central1 \
    --destination-run-job=dbt-daily \
    --destination-run-region=us-central1 \
    --event-filters="type=google.cloud.audit.log.v1.written" \
    --event-filters="serviceName=bigquery.googleapis.com" \
    --event-filters="methodName=google.cloud.bigquery.v2.JobService.InsertJob" \
    --service-account=dbt-runner@PROJECT_ID.iam.gserviceaccount.com

Cela déclenche dbt chaque fois qu’un job de chargement BigQuery se termine. Le pattern fonctionne lorsqu’un outil d’ingestion (Fivetran, Airbyte, un pipeline personnalisé) charge des données directement dans des tables BigQuery référencées par les sources dbt.

Le filtre de journal d’audit methodName=google.cloud.bigquery.v2.JobService.InsertJob est large — il capture tous les inserts de jobs BigQuery, y compris les requêtes, pas seulement les jobs de chargement. Pour plus de précision, traitez la charge utile de l’événement dans une Cloud Function légère qui filtre par type de job et table source avant d’invoquer le Cloud Run Job. Cela ajoute un niveau d’indirection mais empêche dbt de s’exécuter à chaque exécution de requête dans le projet.

Combinaison de déclencheurs événementiels et d’exécutions planifiées

L’exécution purement événementielle présente un risque de fragilité : si la source d’événements échoue silencieusement (un système en amont cesse d’envoyer des fichiers, un appel API commence à renvoyer des résultats vides), dbt ne s’exécute jamais. Personne ne le remarque jusqu’à ce que quelqu’un demande « pourquoi le tableau de bord affiche-t-il les données d’hier ? »

Le pattern robuste combine les deux :

1. Les déclencheurs Eventarc gèrent le chemin nominal — les données arrivent, dbt s’exécute rapidement
2. Cloud Scheduler fournit un filet de sécurité — une exécution planifiée qui rattrape ce que les événements ont manqué

# Événementiel : exécuter à l'arrivée des données
gcloud eventarc triggers create dbt-on-upload \
    --location=us-central1 \
    --destination-run-job=dbt-daily \
    --destination-run-region=us-central1 \
    --event-filters="type=google.cloud.storage.object.v1.finalized" \
    --event-filters="bucket=your-data-bucket" \
    --service-account=dbt-runner@PROJECT_ID.iam.gserviceaccount.com

# Filet de sécurité planifié : assurer un rafraîchissement des modèles au moins quotidien
gcloud scheduler jobs create http dbt-daily-fallback \
    --location=us-central1 \
    --schedule="0 6 * * *" \
    --uri="https://us-central1-run.googleapis.com/apis/run.googleapis.com/v1/namespaces/PROJECT_ID/jobs/dbt-daily:run" \
    --http-method=POST \
    --oauth-service-account-email=dbt-scheduler@PROJECT_ID.iam.gserviceaccount.com

L’exécution planifiée est un filet de sécurité. Si Eventarc a déjà déclenché une exécution réussie pour les données du jour, l’exécution planifiée traite zéro nouvelles lignes (en supposant que vos modèles sont incrémentaux) et se termine rapidement. Le coût d’une exécution redondante est négligeable. Le coût de manquer une journée de données ne l’est pas.

Déduplication et limitation du débit

Les déclencheurs événementiels peuvent se déclencher plus souvent que vous ne voulez que dbt s’exécute. Dix fichiers arrivant en succession rapide déclenchent dix exécutions dbt. Pour la plupart des projets dbt, seule la dernière exécution est pertinente — les neuf précédentes traitent des données incomplètes.

Cloud Run Jobs aide ici : si une exécution de job est déjà en cours lorsqu’un nouveau déclencheur se produit, Cloud Run met l’exécution en file d’attente. Mais mettre en file d’attente dix exécutions redondantes gaspille quand même des ressources de calcul.

Stratégies pour gérer cela :

Debouncing via Cloud Workflows. Au lieu de déclencher directement le Cloud Run Job, acheminez Eventarc vers un Cloud Workflow qui vérifie si une exécution est déjà en cours. Dans ce cas, ignorez ou différez. Cela ajoute de la complexité mais empêche les exécutions redondantes.

Approche par fenêtre de batch. Plutôt que de déclencher sur des uploads de fichiers individuels, déclenchez sur un fichier « manifeste » ou « marqueur de fin » que votre processus en amont écrit après que tous les fichiers d’un batch ont été uploadés. Cela convertit de nombreux événements en un seul.

Exécutions dbt idempotentes. Concevez vos modèles dbt pour être idempotents — exécuter dbt deux fois sur les mêmes données produit le même résultat. Les modèles incrémentaux avec une déduplication appropriée y parviennent naturellement. Si les exécutions redondantes sont peu coûteuses et sans danger, la limitation du débit devient inutile.

Quand les déclencheurs événementiels sont pertinents

dbt événementiel fonctionne bien pour :

• Les tableaux de bord en quasi-temps-réel où les utilisateurs attendent une fraîcheur des données en quelques minutes après les mises à jour de la source
• Les pipelines multi-sources où différentes sources arrivent à des moments imprévisibles
• Les environnements sensibles aux coûts où n’exécuter dbt qu’en cas de besoin économise des ressources de calcul (pertinent pour la tarification BigQuery basée sur les slots)

Cela ajoute une complexité non justifiée lorsque :

• Un planning quotidien suffit. Si les parties prenantes consultent les tableaux de bord une fois le matin, des exécutions horaires ou événementielles gaspillent des efforts d’ingénierie pour une fraîcheur que personne n’utilise.
• Les données sources arrivent selon un planning prévisible. Si Fivetran synchronise à 5h du matin et prend 30 minutes, planifier dbt à 6h est plus simple et tout aussi efficace.
• Le projet dbt n’est pas incrémental. Les modèles à rafraîchissement complet traitent toutes les données indépendamment du moment où ils s’exécutent. Les déclencheurs événementiels n’économisent rien si le modèle ignore le timing des mises à jour de la source.

Pour la plupart des équipes qui démarrent avec dbt sur GCP, un job cron Cloud Scheduler est le point de départ plus simple. Eventarc apporte de la valeur lorsque les exigences de fraîcheur des données nécessitent réellement un déclenchement événementiel.