Wat is dbt en Waarom is het Relevant in 2026?

Als je de afgelopen jaren actief bent geweest in de wereld van data engineering of analytics, heb je de naam dbt (data build tool) ongetwijfeld voorbij zien komen. Ontwikkeld door Fishtown Analytics (nu dbt Labs), is dbt uitgegroeid tot het de facto standaard voor datatransformatie in moderne data stacks. Maar wat maakt dbt zo bijzonder, en waarom is het in 2026 relevanter dan ooit?

dbt is een open-source command-line tool die data teams in staat stelt om transformaties in hun datawarehouse te definiëren, testen en documenteren met behulp van gewone SQL. In plaats van complexe ETL-pipelines te bouwen in Python of proprietary tools, schrijf je met dbt simpelweg SELECT-statements. dbt zorgt vervolgens voor de rest: dependencies beheren, de juiste volgorde van uitvoering, documentatie genereren en data-kwaliteitstesten uitvoeren.

In 2026 is dbt relevanter dan ooit om meerdere redenen. De opkomst van cloudgebaseerde datawarehouses zoals Snowflake, BigQuery, Databricks en Redshift heeft de ELT-aanpak mainstream gemaakt. Waar vroeger ETL-processen data transformeerden vóór het laden, draait ELT de zaken om: laad eerst de ruwe data, transformeer daarna in het warehouse. dbt is gebouwd voor precies dit paradigma.

Bovendien heeft de opkomst van de analytics engineer — een rol die het midden houdt tussen data analyst en data engineer — de vraag naar tools zoals dbt explosief laten groeien. dbt democratiseert datatransformatie: ook analisten zonder diepgaande software-engineeringervaring kunnen nu productie-waardige pipelines bouwen en onderhouden.

Hoe Werkt dbt? Architectuur en Kernconcepten

Om dbt goed te begrijpen, is het belangrijk de kernarchitectuur te doorgronden. dbt werkt als een transformatielaag bovenop je bestaande datawarehouse. Het verbindt zich met je warehouse via een adapter (bijv. voor Snowflake, BigQuery, Redshift of Databricks) en voert SQL-queries uit die jij hebt gedefinieerd.

De dbt Projectstructuur

Een typisch dbt-project heeft de volgende mappenstructuur:

my_dbt_project/
├── dbt_project.yml          # Projectconfiguratie
├── profiles.yml             # Verbindingsinstellingen (lokaal)
├── models/                  # SQL-transformatiemodellen
│   ├── staging/             # Ruwe data laag
│   │   ├── stg_orders.sql
│   │   └── stg_customers.sql
│   ├── intermediate/        # Tussenliggende transformaties
│   │   └── int_orders_enriched.sql
│   └── marts/               # Business-ready tabellen
│       ├── dim_customers.sql
│       └── fct_orders.sql
├── tests/                   # Aangepaste SQL-tests
├── macros/                  # Herbruikbare Jinja-functies
├── seeds/                   # Statische CSV-data
├── snapshots/               # Slowly Changing Dimensions
└── analyses/                # Ad-hoc analyses

Stap-voor-stap: Hoe dbt een Run Uitvoert

Materialisatietypes

Praktische Codevoorbeelden

Theorie is mooi, maar dbt leer je het beste door het te zien in de praktijk. Hieronder een realistisch scenario: een e-commerce bedrijf dat order- en klantdata transformeert naar een analytics-ready datamodel.

1. Source-definitie (sources.yml)

# models/staging/sources.yml
version: 2

sources:
  - name: raw_ecommerce
    database: production_db
    schema: raw
    tables:
      - name: orders
        description: "Ruwe ordertabel vanuit het transactiesysteem"
        columns:
          - name: order_id
            description: "Uniek order-ID"
            tests:
              - unique
              - not_null
          - name: customer_id
            tests:
              - not_null
          - name: order_date
            tests:
              - not_null
      - name: customers
        description: "Klantgegevens"
        columns:
          - name: customer_id
            tests:
              - unique
              - not_null

2. Staging Model (stg_orders.sql)

-- models/staging/stg_orders.sql
{{ config(materialized='view') }}

WITH source AS (
    SELECT * FROM {{ source('raw_ecommerce', 'orders') }}
),

renamed AS (
    SELECT
        order_id,
        customer_id,
        CAST(order_date AS DATE)        AS order_date,
        UPPER(status)                   AS order_status,
        amount_cents / 100.0            AS order_amount_eur,
        created_at,
        updated_at
    FROM source
    WHERE order_id IS NOT NULL
)

SELECT * FROM renamed

3. Incrementeel Model (fct_orders.sql)

-- models/marts/fct_orders.sql
{{
    config(
        materialized='incremental',
        unique_key='order_id',
        on_schema_change='fail'
    )
}}

WITH orders AS (
    SELECT * FROM {{ ref('stg_orders') }}
),

customers AS (
    SELECT * FROM {{ ref('stg_customers') }}
),

enriched AS (
    SELECT
        o.order_id,
        o.order_date,
        o.order_status,
        o.order_amount_eur,
        c.customer_id,
        c.customer_segment,
        c.country_code,
        -- Berekende velden
        DATEDIFF('day', c.first_order_date, o.order_date) AS days_since_first_order,
        CASE
            WHEN o.order_amount_eur >= 500 THEN 'high_value'
            WHEN o.order_amount_eur >= 100 THEN 'mid_value'
            ELSE 'low_value'
        END AS order_value_segment
    FROM orders o
    LEFT JOIN customers c ON o.customer_id = c.customer_id
)

SELECT * FROM enriched

{% if is_incremental() %}
    WHERE order_date > (SELECT MAX(order_date) FROM {{ this }})
{% endif %}

4. Macro voor Herbruikbare Logica

-- macros/cents_to_euros.sql
{% macro cents_to_euros(column_name) %}
    {{ column_name }} / 100.0
{% endmacro %}

-- Gebruik in een model:
-- SELECT {{ cents_to_euros('amount_cents') }} AS amount_eur

5. Model-tests (schema.yml)

# models/marts/schema.yml
version: 2

models:
  - name: fct_orders
    description: "Fact-tabel met alle orders, verrijkt met klantdata"
    columns:
      - name: order_id
        description: "Primaire sleutel"
        tests:
          - unique
          - not_null
      - name: order_status
        tests:
          - accepted_values:
              values: ['PENDING', 'COMPLETED', 'CANCELLED', 'REFUNDED']
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('dim_customers')
              field: customer_id
      - name: order_amount_eur
        tests:
          - not_null
          - dbt_utils.expression_is_true:
              expression: ">= 0"

# Project initialiseren
dbt init my_project

# Alle modellen uitvoeren
dbt run

# Specifiek model uitvoeren
dbt run --select fct_orders

# Alleen downstream modellen uitvoeren
dbt run --select +fct_orders

# Tests uitvoeren
dbt test

# Documentatie genereren en openen
dbt docs generate
dbt docs serve

# Incrementeel model volledig herbouwen
dbt run --select fct_orders --full-refresh

# Debug verbinding
dbt debug

dbt vs. Alternatieven: Vergelijking

dbt is niet de enige speler in het datatransformatielandschap. Hieronder vergelijken we dbt met de meest relevante alternatieven in 2026.

Best Practices en Productiontips voor dbt

dbt is krachtig, maar zoals elke tool is de effectiviteit sterk afhankelijk van hoe je het gebruikt. Hieronder de meest waardevolle best practices voor productieomgevingen.

1. Houd de Laagindeling Strikt aan

De Staging → Intermediate → Marts structuur (ook wel het "dbt Datagladiator"-patroon) is essentieel voor onderhoudbaarheid:

• Staging: 1-op-1 met bronsystemen, alleen renaming en type-casting
• Intermediate: Business-logica en joins, herbruikbare bouwblokken
• Marts: Business-ready tabellen voor BI-tools (facts & dimensions)

2. Gebruik Always ref() en source()

-- ❌ Verkeerd: hardcoded tabelnamen
SELECT * FROM production_db.raw.orders

-- ✅ Correct: gebruik source() voor bronsystemen
SELECT * FROM {{ source('raw_ecommerce', 'orders') }}

-- ✅ Correct: gebruik ref() voor andere modellen
SELECT * FROM {{ ref('stg_orders') }}

3. Incrementele Modellen Verstandig Inzetten

-- Gebruik een betrouwbare unique_key voor upserts
{{
    config(
        materialized='incremental',
        unique_key='order_id',
        incremental_strategy='merge'  -- of 'delete+insert' voor Redshift
    )
}}

-- Voeg altijd een buffer toe aan je incrementele filter
-- om late-arriving data op te vangen
{% if is_incremental() %}
    WHERE updated_at > (
        SELECT DATEADD('hour', -6, MAX(updated_at)) 
        FROM {{ this }}
    )
{% endif %}

4. CI/CD Pipeline Opzetten

# .github/workflows/dbt_ci.yml
name: dbt CI

on:
  pull_request:
    branches: [main]

jobs:
  dbt-ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Setup Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'
      
      - name: Install dbt
        run: pip install dbt-snowflake==1.7.0
      
      - name: dbt debug
        run: dbt debug
        env:
          DBT_SNOWFLAKE_ACCOUNT: ${{ secrets.SNOWFLAKE_ACCOUNT }}
          DBT_SNOWFLAKE_PASSWORD: ${{ secrets.SNOWFLAKE_PASSWORD }}
      
      # Run alleen gewijzigde modellen + downstream
      - name: dbt run (changed models)
        run: dbt run --select state:modified+
        
      - name: dbt test
        run: dbt test --select state:modified+

5. Packages Gebruiken

Het dbt-ecosysteem heeft een rijke verzameling packages. Voeg ze toe via packages.yml:

# packages.yml
packages:
  - package: dbt-labs/dbt_utils
    version: [">=1.1.0", "<2.0.0"]
  
  - package: calogica/dbt_expectations
    version: [">=0.9.0", "<1.0.0"]
  
  - package: dbt-labs/audit_helper
    version: [">=0.9.0", "<1.0.0"]

# Installeren via:
# dbt deps

Conclusie: Wanneer Wel en Niet dbt Gebruiken

dbt heeft de manier waarop data teams werken fundamenteel veranderd. Het heeft analytics engineering volwassen gemaakt door software-engineeringprincipes (versiebeheer, testen, documentatie, modulaire code) naar de wereld van datatransformatie te brengen.

Gebruik dbt wanneer:

• Je werkt met een cloudwarehouse zoals Snowflake, BigQuery, Databricks of Redshift
• Je team SQL-vaardig is maar niet per se software-engineer
• Je transformatielogica centraliseren wilt vanuit meerdere bronnen
• Datakwaliteit en documentatie topprioriteiten zijn
• Je CI/CD-workflows wilt toepassen op je datamodellen
• Je ELT-aanpak hanteert en transformatie in het warehouse uitvoert

Overweeg alternatieven wanneer:

• Zware Python- of ML-transformaties nodig zijn (dan is PySpark/Databricks beter)
• Je warehouse niet door dbt ondersteund wordt (hoewel het ecosysteem inmiddels zeer breed is)
• Je complexe state management nodig hebt buiten wat dbt biedt (kijk dan naar SQLMesh)
• Real-time streaming transformaties vereist zijn (dbt is batch-georiënteerd; combineer dan met Flink of dbt + Kafka)