Stack dbt, BigQuery, Looker : l'architecture de référence

La stack de référence sur Google Cloud tient en une phrase : dbt transforme les données brutes en tables de faits et de dimensions testées dans BigQuery, et LookML expose ces tables aux utilisateurs sous forme d'explores gouvernés dans Looker. Chaque couche a un rôle précis, et la plupart des problèmes de performance, de coût ou de confiance viennent d'une logique placée au mauvais étage. Ce guide décrit qui fait quoi, les conventions qui évitent les regrets, et une architecture minimale qui tient pour une équipe de deux personnes comme pour un groupe.

Les trois couches et leur contrat

Couche	Outil	Responsabilité	Ce qu'elle ne doit pas faire
Stockage et calcul	BigQuery	Stocker, exécuter les requêtes, partitionner, clusteriser	Porter de la logique métier dans des vues ad hoc non versionnées
Transformation	dbt	Nettoyer, joindre, historiser, tester ; produire des tables au bon grain	Formater pour l'affichage, gérer les permissions utilisateurs
Sémantique et accès	Looker (LookML)	Définir les mesures, les explores, la sécurité au niveau ligne, le cache	Transformer les données (jointures complexes, dédoublonnage, historisation)

La règle de répartition la plus utile : si une logique doit être vraie pour tous les outils, y compris hors Looker, elle va dans dbt. Si elle concerne la façon dont un humain ou un agent interroge les données, elle va dans LookML. Une dédoublonnage de clients va dans dbt. Un access_filter par région va dans LookML. Une mesure « CA net » est déclarée une fois dans LookML, sur des colonnes de montant que dbt a rendues explicites.

Le flux, du brut à l'écran

Ingestion. Les sources arrivent dans BigQuery brutes, dans un dataset par source (raw_shopify, raw_hubspot, raw_ga4), via BigQuery Data Transfer, Fivetran, Airbyte ou des exports natifs. Personne ne requête ces datasets directement.

Staging (dbt). Un modèle par table source, préfixé stg_, qui renomme, type, et ne fait rien d'autre. Matérialisé en vue. C'est la seule couche qui connaît les noms de colonnes des sources.

Intermédiaire (dbt). Modèles int_ pour les jointures et les règles métier réutilisables (rattacher une commande à un client canonique, calculer un statut). Souvent éphémères ou en vues.

Marts (dbt). Tables de faits (fct_orders, fct_sessions) et de dimensions (dim_customers, dim_products), matérialisées en tables, partitionnées par date et clusterisées sur les clés de filtre fréquentes. C'est ce que Looker lit.

Sémantique (LookML). Une vue LookML par table de mart, des explores par domaine, des mesures nommées et décrites, des datagroups alignés sur la fin du run dbt.

Consommation. Dashboards Looker, explores pour les analystes, Looker Studio via le connecteur Looker pour la diffusion large, agents Conversational Analytics, API pour les intégrations.

Conventions de nommage qui évitent les regrets

Elles semblent secondaires jusqu'au jour où quarante modèles et deux cents champs existent.

dbt. stg_<source>__<table>, int_<domaine>_<action>, fct_<événement>, dim_<entité>. Clés en <entité>_id, toujours du même type. Montants suffixés _amount, comptes _count, booléens préfixés is_ ou has_. Dates en _date, horodatages en _at. Devise unique dans les marts, la conversion se fait en amont.

LookML. La vue porte le nom de la table (fct_orders devient la vue orders via sql_table_name). Les dimensions reprennent les noms de colonnes sans les traduire ; la traduction vit dans label. Les mesures suivent <quantité>_<agrégat> ou un nom métier explicite : net_revenue, order_count, average_order_value. Un group_label par famille de champs.

Datasets BigQuery. raw_* pour les sources, staging, intermediate, marts (ou analytics) pour dbt, un dataset looker_scratch dédié aux PDT, avec expiration automatique.

Tests : où et lesquels

Dans dbt, à chaque run. unique et not_null sur chaque clé primaire, relationships entre faits et dimensions, accepted_values sur les statuts, et un test de réconciliation par indicateur clé : la somme de fct_orders.invoiced_amount sur le mois clos doit égaler le total de la comptabilité à un seuil près. Ce dernier test est celui qui protège la crédibilité du dashboard de direction.

Dans Looker, à chaque PR. Le LookML Validator (syntaxe et références), le Content Validator (dashboards cassés par un renommage), et un test d'exécution des explores critiques via l'API ou un outil comme Spectacles. Une PR qui casse un dashboard de direction ne doit pas pouvoir être fusionnée.

À la frontière. Les primary_key déclarées dans LookML doivent correspondre aux tests unique de dbt. Quand un mart change de grain, la PR dbt et la PR LookML se font ensemble.

CI : le minimum qui tient

Un dépôt dbt et un dépôt LookML (ou un mono-dépôt avec deux dossiers), chacun avec une intégration continue.

Côté dbt. À chaque PR : dbt build --select state:modified+ contre un schéma de CI éphémère, avec les tests. Au merge : déploiement, run planifié (Cloud Composer, Cloud Run Jobs, dbt Cloud ou GitHub Actions selon la taille). À la fin du run, une table de log meta.load_log reçoit un horodatage.

Côté Looker. Le projet est connecté à Git avec PR obligatoires. Un datagroup lit la table de log :

datagroup: dbt_daily {
  sql_trigger: SELECT MAX(finished_at) FROM `dwh.meta.load_log` WHERE status = 'success' ;;
  max_cache_age: "24 hours"
}

Le cache Looker se vide exactement quand dbt a livré de nouvelles données, ni avant (requêtes inutiles) ni après (données périmées).

Maîtrise des coûts

BigQuery facture le volume traité ou la capacité. Sur cette stack, quatre réglages font l'essentiel de la facture.

Partitionner et clusteriser les marts dans dbt (partition_by sur la date d'événement, cluster_by sur les clés de filtre). Un explore filtré sur la date ne lit que les partitions utiles.

Forcer le filtre de partition dans LookML avec conditionally_filter ou always_filter sur les explores de grandes tables, et déclarer partition_keys sur les PDT.

Matérialiser les agrégats une fois, dans dbt (une table fct_daily_sales par jour et par produit) plutôt que de laisser trente tuiles recalculer la même somme. Les aggregate_table de Looker complètent pour les agrégats spécifiques aux dashboards.

Mesurer. INFORMATION_SCHEMA.JOBS filtré sur le compte de service Looker et sur le compte dbt, une fois par mois. Les vingt requêtes les plus chères indiquent où agir. Sans cette mesure, personne ne sait si l'optimisation a servi.

Réglage souvent oublié : un dataset looker_scratch avec expiration de tables à sept jours, pour que les PDT abandonnées ne s'accumulent pas.

Une architecture minimale

Pour une équipe de deux personnes et cinq sources, ce qui suit suffit et se met en place en quatre à six semaines.

• Un projet Google Cloud, BigQuery en tarification à la demande au départ, passage aux slots réservés au-delà d'une centaine de TiB traités par mois.
• BigQuery Data Transfer pour Google Ads et GA4, un connecteur géré pour le CRM et la plateforme e-commerce.
• dbt Core planifié par un Cloud Run Job quotidien, ou dbt Cloud si personne ne veut gérer l'ordonnancement. Une quinzaine de modèles au départ.
• Looker (Google Cloud core) édition Standard, un projet LookML, trois explores (ventes, clients, acquisition), un datagroup.
• Un dépôt Git par outil, GitHub Actions pour la CI dbt, PR obligatoires côté Looker.
• Looker Studio, via le connecteur Looker, pour les rapports figés à large diffusion.

Ce qu'on ajoute quand l'organisation grandit : des environnements dbt séparés (dev, CI, prod), un catalogue de données, des tests de fraîcheur dbt (source freshness), une sécurité au niveau ligne dans LookML, et des agents Conversational Analytics sur les explores nettoyés.

Ce qui s'observe en production : dans un grand groupe industriel, Looker et BigQuery servent les dashboards de direction depuis plusieurs années avec une couche sémantique gouvernée. Les incidents les plus coûteux sont venus de logique placée au mauvais étage : une historisation faite dans une PDT Looker au lieu de dbt, impossible à tester, reconstruite chaque nuit sur trois ans de données. La déplacer a réglé à la fois le coût et la confiance.

FAQ

Faut-il dbt si l'on a déjà des tables dérivées Looker ?

Les PDT sont pratiques pour un agrégat spécifique à un dashboard. Dès qu'elles portent des jointures complexes, de l'historisation ou une logique dont d'autres outils ont besoin, elles deviennent difficiles à tester et coûteuses à reconstruire. dbt est fait pour cela, avec des tests et une CI. La transition se fait mart par mart.

Où définir les métriques, dans dbt ou dans LookML ?

Une seule des deux couches doit être exposée aux utilisateurs. Sur une stack Looker, LookML porte les mesures et les explores, et dbt garantit des colonnes de montant explicites et testées. Si d'autres outils que Looker doivent consommer les mêmes métriques, la couche métrique dbt (MetricFlow) devient une option, à condition de ne pas dupliquer les définitions.

Peut-on faire tourner cette stack sans data engineer ?

Une personne à l'aise en SQL et en Git suffit pour la mettre en place et la maintenir à cette échelle, à raison de deux à trois jours par mois une fois en production. L'ordonnancement géré (dbt Cloud, Cloud Run Jobs) évite d'avoir à opérer un Airflow.

Quel est le premier signe qu'une logique est au mauvais étage ?

Une PDT Looker qui met plus de dix minutes à se reconstruire, ou un modèle dbt qui contient des colonnes formatées pour l'affichage. Dans le premier cas la logique remonte dans dbt ; dans le second elle descend dans LookML.

Et ensuite

Si votre stack a déjà les trois couches mais que les chiffres se contredisent ou que la facture BigQuery monte, le problème est presque toujours une logique au mauvais étage ou une définition dupliquée. Cinq semaines suffisent pour remettre les marts et les mesures à leur place.

Voir l'offre Couche sémantique BigQuery, dbt, Looker, et pour aller plus loin : Pourquoi vos chiffres ne concordent pas et La check-list d'audit LookML.