dbt¶

dbt-core 1.12.2 avec dbt-postgres 1.11.0, dans un virtualenv isolé de l'image Airflow (/opt/dbt).

Organisation¶

dbt/
├── dbt_project.yml              configuration, association dossier → schéma
├── profiles.yml                 connexion, lue depuis l'environnement
├── packages.yml                 dbt_utils
├── macros/
│   └── generate_schema_name.sql neutralise le préfixage des schémas
└── models/
    ├── staging/       7 modèles  → vues dans silver
    ├── intermediate/  1 modèle   → éphémère, rien en base
    └── marts/         8 modèles  → tables dans gold

Matérialisations¶

Couche	Matérialisation	Pourquoi
`staging`	vue	Léger, recalculé à la lecture, toujours à jour
`intermediate`	éphémère	Inliné à la compilation : logique partagée sans objet en base
`marts`	table	Ce que Metabase interroge — les performances priment

La macro de schéma¶

Par défaut, dbt préfixe les schémas personnalisés par le schéma cible : +schema: silver produirait public_silver. Ce comportement sert à isoler plusieurs développeurs sur un entrepôt partagé.

{% macro generate_schema_name(custom_schema_name, node) -%}
    {%- if custom_schema_name is none -%}
        {{ target.schema }}
    {%- else -%}
        {{ custom_schema_name | trim }}
    {%- endif -%}
{%- endmacro %}

Secrets¶

profiles.yml ne contient aucun identifiant : tout vient de l'environnement via env_var(). Le fichier est donc versionnable tel quel.

Tests¶

58 tests à chaque exécution :

Type	Exemple
`unique`, `not_null`	clés primaires de toutes les tables
`relationships`	`fct_orders.customer_id` → `dim_customer.customer_id`
`accepted_values`	`segment ∈ {TPE, PME, ETI, Grand compte}`
`dbt_utils.accepted_range`	`satisfaction` entre 1 et 5
`dbt_utils.unique_combination_of_columns`	`(région, jour)` dans les faits énergie

dbt build enchaîne modèles et tests dans l'ordre du graphe : un modèle dont un test échoue ne propage pas ses données en aval.

Exécution¶

docker compose exec -e WAREHOUSE_PASSWORD="$WAREHOUSE_DB_PASSWORD" \
  airflow-scheduler bash -c 'cd /opt/airflow/dbt && /opt/dbt/bin/dbt build --target prod'

En temps normal, c'est le DAG 30_transform_dbt qui s'en charge, déclenché par la mise à jour d'un asset bronze.

Syntaxe des arguments de test

dbt 1.12 déprécie les arguments passés à plat sous un test générique : ils doivent vivre sous une clé arguments:. Le projet est déjà migré.