dbt_bigquery_monitoring

Résumé

bqbooster/dbt_bigquery_monitoring est un package dbt qui mesure l’usage de BigQuery lui-même : coût (calcul et stockage), performance (jobs lents ou en échec) et hygiène du stockage (tables inutilisées, économies logique/physique). Il s’appuie sur INFORMATION_SCHEMA, sur l’export de facturation détaillé de GCP et, en option, sur les Cloud Audit Logs. Il ne produit aucune donnée métier. Quatre décisions pèsent avant adoption : le niveau d’IAM, la version du package, l’emplacement du projet et la rétention.

Prérequis

dbt — Fondamentaux (projet, packages, vars). Le catalogue détaillé des modèles est dans dbt_bigquery_monitoring — catalogue des modèles.

Ce que fait le package

Les modèles s’installent dans un dataset dédié (par convention <schema>_dbt_bigquery_monitoring), à l’intérieur d’un projet dbt existant.

flowchart LR
    IS["INFORMATION_SCHEMA<br/>JOBS, TABLE_STORAGE…"] --> J["jobs_with_cost<br/>modèle pivot"]
    AL["Cloud Audit Logs<br/>(optionnel)"] -.-> J
    BE["Export de facturation GCP<br/>(optionnel)"] --> BM["modèles de coût réel"]
    J --> DM["datamarts compute"]
    BM --> DS["daily_spend"]
    J --> DS
    ST["TABLE_STORAGE"] --> SM["datamarts storage"]

Presque tous les datamarts de calcul descendent d’un seul modèle, jobs_with_cost, dont la source dépend de la configuration :

Configuration	Source de jobs_with_cost
Par défaut	INFORMATION_SCHEMA.JOBS
enable_gcp_bigquery_audit_logs activé	Cloud Audit Logs seuls
Et should_combine_audit_logs_and_information_schema activé	Les deux fusionnés

Les modèles qui dépendent d’une option non activée (audit logs, export de facturation) sont exclus du DAG, pas seulement vides. Ceux des réservations de slots s’exécutent toujours mais ne renvoient des lignes que si le projet utilise des réservations.

Configuration

Les variables sont préfixées dbt_bigquery_monitoring et documentées dans macros/variables.sql du package.

Variable	Rôle
bq_region	Région d’INFORMATION_SCHEMA interrogée ; doit correspondre à celle des datasets
enable_gcp_billing_export et paramètres associés	Coût réellement facturé, au lieu d’une estimation aux prix publics
enable_gcp_bigquery_audit_logs et paramètres associés	Bascule vers les Cloud Audit Logs ; exige un sink Cloud Logging vers BigQuery, configuré hors dbt
should_combine_audit_logs_and_information_schema	Fusionne les deux sources
use_flat_pricing	Modèle de coût estimé : forfait (slots) ou à la demande (par To lu)
lookback_window_days, lookback_incremental_billing_window_days	Fenêtres de rafraîchissement incrémental (7 et 3 jours par défaut)
output_partition_expiration_days	Rétention des partitions des tables incrémentales (365 jours par défaut)

Valeurs par défaut à revérifier

Les défauts cités (7, 3, 365 jours ; use_flat_pricing) correspondent à la version 0.x consultée. Les relire dans macros/variables.sql de la version installée.

Audit logs : quand les activer

Un sink Cloud Logging vers BigQuery donne des signaux que INFORMATION_SCHEMA n’a pas : le client émetteur de la requête (caller_supplied_user_agent), une rétention plus longue (INFORMATION_SCHEMA.JOBS* ne garde qu’environ 180 jours) et la capture d’événements d’accès atypiques. À activer pour des environnements multi-utilisateurs, de la conformité ou de l’audit de sécurité. Le prix : une infrastructure permanente (audit BigQuery, sink, dataset dédié) et un stockage proportionnel au volume de requêtes.

Coût de lecture d’INFORMATION_SCHEMA

Interroger les vues INFORMATION_SCHEMA consomme des octets lus et du temps de calcul. Sur un grand nombre de tables ou de jobs, un run de monitoring peut avoir un coût non négligeable : mesurer les octets facturés du premier run complet avant de planifier le package.

Décisions avant adoption

1. IAM : roles/bigquery.admin pour l’historique de configuration

La plupart des modèles se contentent de rôles de lecture (bigquery.resourceViewer, bigquery.metadataViewer, et bigquery.dataEditor sur le dataset de sortie). Deux modèles d’historique de configuration (information_schema_organization_options_changes et _project_options_changes, désactivés par défaut) exigent bigquery.config.update, apportée par roles/bigquery.admin, un rôle quasi total sur BigQuery sans équivalent plus étroit prédéfini.

Le niveau de liaison diffère

• Le modèle projet demande bigquery.admin accordé sur le projet.
• Le modèle organisation demande bigquery.admin accordé au niveau de l’organisation. Un droit projet ne suffit pas, et le projet doit appartenir à une organisation GCP. Sinon le modèle reste vide ou échoue sur un refus de permission.

Accorder ce rôle au service account qui écrit aussi les données de production concentre un privilège très large sur une identité déjà exposée. Alternative : un service account dédié à ces deux modèles, utilisé par impersonation ponctuelle, ou un rôle IAM personnalisé réduit à bigquery.config.update. Ce surcoût se justifie pour de la conformité ou de la gouvernance, moins pour du simple confort d’observabilité.

2. Version du package

Le package est en version 0.x. Sous SemVer, une version 0.x ne garantit aucune compatibilité entre versions mineures : des modèles, des colonnes ou des valeurs par défaut peuvent changer. Épingler une version exacte plutôt qu’un intervalle tant qu’il n’y a pas de 1.0, et lire le changelog avant chaque mise à jour.

3. Emplacement

L’installer dans le même projet GCP et sous le même service account que la production est le chemin le plus simple. Deux conséquences :

• un run de monitoring qui dérape consomme le même pool de slots que la production ;
• les deux partagent le même rayon d’impact IAM : toute élévation de privilège accordée au monitoring vaut aussi pour l’identité qui écrit les données de production.

Un projet dédié avec un service account en lecture seule côté source supprime ces couplages, au prix d’une IAM entre projets et d’une facturation séparée.

4. Rétention et fenêtres de lookback

Laisser les valeurs par défaut crée une dépendance implicite : si une version du package les change, la purge et la fraîcheur changent sans qu’une ligne du projet ne bouge. Les fixer explicitement dans le projet, même identiques au défaut.

Checklist d’adoption

Décision	Question
Export de facturation	Coût réel (export activé) ou estimation aux prix publics ?
Audit logs	La traçabilité et la rétention longue justifient-elles l’infrastructure et le stockage récurrent ?
Historique de configuration	Cette valeur justifie-t-elle bigquery.admin, sur quelle identité, et le projet est-il dans une organisation GCP ?
Version	Version exacte épinglée, avec quelle revue de changelog ?
Emplacement	Même projet que la production, ou projet dédié ?
Rétention	Défauts acceptés et documentés, ou valeurs explicites ?
Coût d’INFORMATION_SCHEMA	Octets facturés d’un run complet mesurés ?

Notes liées

• dbt_bigquery_monitoring — catalogue des modèles : l’inventaire détaillé.
• dbt — Fondamentaux : le projet dbt dans lequel on installe le package.
• dbt Incremental Models vs Snowflake Dynamic Tables : les modèles incrémentaux du package utilisent une fenêtre de lookback explicite, comme l’approche 1 de cette note.
• Staging, ODS, DWH et architecture médaillon : le package se place en périphérie du pipeline qu’il surveille.
• MOC Data Engineering : carte du vault.