dbt pour les nuls : guide pratique
dbt, c’est quoi en une phrase
dbt te permet d’écrire des transformations SQL comme du code versionné, testé, documenté et déployé proprement.
Pourquoi dbt change la donne
Sans dbt, on voit souvent :
- des requêtes SQL copiées dans plusieurs endroits
- des définitions métier incohérentes
- peu de tests
- une doc obsolète
Avec dbt :
- chaque modèle est un fichier clair
- les dépendances sont explicites
- les tests sont automatisés
- la documentation est générée
Le minimum à comprendre
1. model
Un model = une transformation SQL matérialisée en table ou view.
2. ref()
ref('nom_modele') déclare une dépendance entre models.
3. tests
Deux niveaux :
- tests génériques (
not_null,unique,accepted_values) - tests métier personnalisés
4. sources
Permet de documenter et tester les tables d’entrée.
Structure simple pour commencer
models/
staging/
stg_customers.sql
stg_orders.sql
marts/
fct_orders.sql
dim_customers.sql
schema.yml
Règle utile :
- staging = nettoyage léger + renommage cohérent
- marts = logique métier et indicateurs
Exemple concret
-- models/staging/stg_orders.sql
select
order_id,
customer_id,
cast(order_date as date) as order_date,
amount
from {{ source('app', 'orders') }}
where order_id is not null
-- models/marts/fct_orders.sql
select
o.order_id,
o.customer_id,
o.order_date,
o.amount,
c.country
from {{ ref('stg_orders') }} o
left join {{ ref('stg_customers') }} c
on o.customer_id = c.customer_id
Les 5 commandes à connaître
dbt debugdbt rundbt testdbt builddbt docs generate
Plan de déploiement en 3 phases
- Pilote : un domaine métier, 5 à 10 models, tests de base.
- Standardisation : conventions de nommage, revues SQL, CI.
- Industrialisation : monitoring des runs, SLA, ownership par domaine.
Erreurs fréquentes
- tout mettre dans un seul model géant
- ignorer les tests source
- mélanger logique métier et nettoyage dans les marts
- ne pas versionner les changements de définitions KPI
En résumé
dbt n’est pas magique. C’est surtout une discipline qui rend les transformations lisibles, testables et maintenables. Commence petit, impose des conventions, et monte en puissance progressivement.
Vous avez un projet data similaire ? Parlons-en → isdataconsulting.com
Besoin d'aide pour mettre ça en place ?
Missions Data Engineering, Architecture Data, Data Product Owner — ISData Consulting.