dbt in 2026: Datatransformaties, Testing en Interviewvragen voor Data Engineers

dbt (data build tool) heeft zich in de afgelopen jaren gevestigd als de standaard voor datatransformaties in moderne data-architecturen. In 2026 is het ecosysteem rondom dbt verder gegroeid met de introductie van de Fusion Engine, verbeterde incrementele strategieen en een nog sterkere focus op datakwaliteit. Voor data engineers die zich voorbereiden op technische interviews is kennis van dbt onmisbaar geworden. Dit artikel behandelt de kernconcepten, best practices en veelgestelde interviewvragen rondom dbt.

Gelaagde Modellering: Staging, Intermediate en Marts

Een van de belangrijkste architectuurprincipes in dbt is het organiseren van modellen in duidelijk gescheiden lagen. Deze aanpak zorgt voor herbruikbaarheid, testbaarheid en een helder overzicht van de datatransformaties binnen een project.

De Staging-laag

De staging-laag vormt het eerste contactpunt met ruwe brondata. Hier worden kolommen hernoemd, datatypes gecast en basale filtering toegepast. Het doel is een schone, gestandaardiseerde versie van de brondata te creeren zonder complexe bedrijfslogica toe te voegen.

-- models/staging/stg_orders.sql
WITH source AS (
    SELECT * FROM {{ source('ecommerce', 'raw_orders') }}
)
SELECT
    id AS order_id,
    customer_id,
    CAST(order_date AS DATE) AS order_date,
    CAST(amount AS DECIMAL(10, 2)) AS order_amount,
    LOWER(status) AS order_status
FROM source
WHERE id IS NOT NULL

Dit model illustreert de typische verantwoordelijkheden van een staging-model: het hernoemen van id naar order_id voor duidelijkheid, het casten van datatypes en het filteren van ongeldige records.

De Intermediate-laag

De intermediate-laag combineert meerdere staging-modellen en voert aggregaties uit die door meerdere downstream-modellen worden gebruikt. Deze laag voorkomt duplicatie van complexe joins en berekeningen.

-- models/intermediate/int_customer_orders.sql
WITH orders AS (
    SELECT * FROM {{ ref('stg_orders') }}
),
customers AS (
    SELECT * FROM {{ ref('stg_customers') }}
)
SELECT
    c.customer_id,
    c.customer_name,
    COUNT(o.order_id) AS total_orders,
    SUM(o.order_amount) AS lifetime_value,
    MIN(o.order_date) AS first_order_date,
    MAX(o.order_date) AS last_order_date
FROM customers c
LEFT JOIN orders o ON c.customer_id = o.customer_id
GROUP BY c.customer_id, c.customer_name

Door klantstatistieken in een intermediate-model te berekenen, kunnen meerdere mart-modellen deze data hergebruiken zonder de join- en aggregatielogica te dupliceren.

De Marts-laag

De marts-laag bevat de uiteindelijke modellen die direct worden geconsumeerd door BI-tools, dashboards of API's. Hier worden bedrijfsspecifieke metrics berekend die aansluiten bij de behoeften van eindgebruikers.

-- models/marts/fct_daily_revenue.sql
{{
    config(
        materialized='incremental',
        unique_key='revenue_date',
        incremental_strategy='merge'
    )
}}
SELECT
    DATE(order_date) AS revenue_date,
    SUM(order_amount) AS daily_revenue,
    COUNT(DISTINCT customer_id) AS unique_customers
FROM {{ ref('stg_orders') }}
WHERE order_status = 'completed'
{% if is_incremental() %}
    AND order_date > (SELECT MAX(revenue_date) FROM {{ this }})
{% endif %}
GROUP BY DATE(order_date)

Dit mart-model maakt gebruik van incrementele materialisatie om alleen nieuwe data te verwerken, wat de verwerkingstijd aanzienlijk verkort bij grote datasets.

De ref()-functie en de DAG

De ref()-functie is het fundament van dbt's dependency management. Door modellen naar elkaar te verwijzen via ref() bouwt dbt automatisch een Directed Acyclic Graph (DAG) op die de volgorde van uitvoering bepaalt.

-- Bad: hardcoded reference, no dependency tracking
SELECT * FROM analytics.stg_orders

-- Good: ref() registers the dependency
SELECT * FROM {{ ref('stg_orders') }}

Het gebruik van hardcoded referenties doorbreekt de DAG en maakt het onmogelijk voor dbt om afhankelijkheden correct te traceren. De ref()-functie biedt daarnaast voordelen bij het werken met meerdere omgevingen: dezelfde code werkt in development, staging en productie zonder aanpassingen.

De DAG maakt het ook mogelijk om selectief modellen uit te voeren. Met commando's zoals dbt run --select fct_daily_revenue+ worden alleen het opgegeven model en alle downstream-afhankelijkheden uitgevoerd, wat de feedbackloop tijdens ontwikkeling versnelt.

Materialisaties: View, Table, Incremental en Ephemeral

De keuze voor een materialisatiestrategie heeft directe impact op de prestaties en kosten van een dbt-project. Elke strategie heeft specifieke use cases:

• View: Geschikt voor lichte transformaties die altijd de meest recente data moeten tonen. Geen opslagkosten, maar elke query voert de transformatie opnieuw uit.
• Table: Ideaal voor modellen die frequent worden opgevraagd en waar de data niet continu verandert. De tabel wordt bij elke run volledig herbouwd.
• Incremental: De meest efficiente optie voor grote datasets waar alleen nieuwe of gewijzigde records verwerkt hoeven te worden. Vereist een unique_key en een strategie voor het samenvoegen van data.
• Ephemeral: Modellen die als CTE worden geinjected in downstream-modellen. Nuttig voor herbruikbare logica die geen eigen tabel of view rechtvaardigt.

In de praktijk gebruiken de meeste teams views voor staging-modellen, tables voor intermediate-modellen en incrementele materialisaties voor marts met grote datavolumes.

Testing van Datakwaliteit

Een van de sterkste aspecten van dbt is het ingebouwde testframework. Tests valideren aannames over de data en waarschuwen het team wanneer datakwaliteitsproblemen optreden.

Schema Tests

Schema tests worden gedefinieerd in YAML-bestanden en controleren basiskenmerken van kolommen:

# models/staging/_stg_models.yml
version: 2

models:
  - name: stg_orders
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: order_status
        tests:
          - accepted_values:
              values: ['completed', 'pending', 'cancelled', 'refunded']
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('stg_customers')
              field: customer_id

Deze configuratie garandeert dat elke order een uniek en niet-leeg ID heeft, dat de status alleen geldige waarden bevat en dat elke customer_id daadwerkelijk bestaat in de klantentabel.

Custom Tests

Voor complexere validaties biedt dbt de mogelijkheid om custom tests te schrijven als SQL-queries. Een test slaagt wanneer de query nul rijen retourneert:

-- tests/assert_revenue_never_negative.sql
SELECT
    revenue_date,
    daily_revenue
FROM {{ ref('fct_daily_revenue') }}
WHERE daily_revenue < 0

Deze test controleert of er geen dagen bestaan met negatieve omzet, wat zou wijzen op een fout in de datatransformatie of corrupte brondata.

dbt Core v1.10 en de Fusion Engine

De release van dbt Core v1.10 in 2026 introduceert de Fusion Engine, een fundamentele herarchitectuur van de execution engine. De belangrijkste verbeteringen omvatten:

• Parallelle uitvoering: De Fusion Engine voert onafhankelijke modellen gelijktijdig uit, wat de totale runtime met 40-60% kan reduceren bij grote projecten.
• Intelligente caching: Tussenresultaten worden gecached en hergebruikt wanneer upstream-modellen niet zijn gewijzigd.
• Native Python-modellen: Python-transformaties worden nu native ondersteund zonder externe orchestrators, wat de integratie van machine learning-pipelines vereenvoudigt.
• Verbeterde incrementele strategieen: Nieuwe opties zoals microbatch maken het mogelijk om incrementele modellen in kleine batches te verwerken, wat de geheugendruk verlaagt.

Deze verbeteringen maken dbt geschikt voor nog grotere datasets en complexere transformatie-pipelines dan voorheen.

Macros en Jinja

Macros zijn herbruikbare SQL-fragmenten die met Jinja-templating worden geschreven. Ze elimineren codeduplicatie en standaardiseren veelvoorkomende patronen binnen een project.

-- macros/cents_to_dollars.sql
{% macro cents_to_dollars(column_name) %}
    ROUND({{ column_name }} / 100.0, 2)
{% endmacro %}

Deze macro kan vervolgens in elk model worden aangeroepen met {{ cents_to_dollars('amount_cents') }}. Het voordeel is tweeledig: de logica hoeft slechts op een plek te worden onderhouden, en de leesbaarheid van modellen verbetert doordat de intentie direct duidelijk is.

Geavanceerde toepassingen van Jinja omvatten het dynamisch genereren van SQL op basis van variabelen, het conditioneel toepassen van filters en het itereren over lijsten om repetitieve kolom-definities te automatiseren.

Veelgestelde dbt Interviewvragen

Hieronder volgen de meest voorkomende interviewvragen over dbt, samen met uitgebreide antwoorden die de diepgang tonen die werkgevers verwachten.

Vraag 1: Wat is het verschil tussen source() en ref() in dbt?

De source()-functie verwijst naar ruwe tabellen in het datawarehouse die buiten dbt worden beheerd. Het definieert het ingangspunt van de data-pipeline. De ref()-functie verwijst naar andere dbt-modellen en registreert een afhankelijkheid in de DAG. Het belangrijkste onderscheid is dat source() de grens markeert tussen externe systemen en het dbt-project, terwijl ref() interne afhankelijkheden beheert.

Vraag 2: Wanneer kies je voor een incrementeel model boven een table-materialisatie?

Incrementele modellen zijn de juiste keuze wanneer de brondata append-only is of een betrouwbare timestamp bevat, de tabel te groot is om bij elke run volledig te herbouwen, en de business-requirements toestaan dat er een korte vertraging zit tussen data-aankomst en beschikbaarheid. Table-materialisatie verdient de voorkeur wanneer de dataset klein genoeg is voor een volledige rebuild, de transformatielogica complex is en moeilijk incrementeel te maken, of wanneer exacte consistentie vereist is.

Vraag 3: Hoe garandeer je datakwaliteit in een dbt-project?

Een robuuste datakwaliteitsstrategie combineert meerdere lagen: schema tests voor basisvalidatie (unique, not_null, accepted_values, relationships), custom tests voor bedrijfsspecifieke regels, freshness checks op brondata via dbt source freshness, en contract-enforcement op mart-modellen. Daarnaast is het integreren van dbt test in de CI/CD-pipeline essentieel om regressies vroegtijdig te detecteren.

Vraag 4: Leg de dbt DAG uit en waarom deze belangrijk is.

De Directed Acyclic Graph is een visuele en functionele representatie van alle afhankelijkheden tussen modellen. "Directed" betekent dat data in een richting stroomt (van bron naar mart), en "Acyclic" garandeert dat er geen circulaire afhankelijkheden bestaan. De DAG bepaalt de uitvoeringsvolgorde, maakt selectieve runs mogelijk, faciliteert impact-analyse bij wijzigingen en biedt documentatie van de data-lineage.

Vraag 5: Wat zijn de voordelen van de gelaagde modellering (staging/intermediate/marts)?

Gelaagde modellering biedt scheiding van verantwoordelijkheden: staging normaliseert brondata, intermediate combineert en verrijkt, en marts leveren bedrijfsklare datasets. Dit patroon verbetert de testbaarheid (elke laag kan onafhankelijk worden getest), bevordert herbruikbaarheid (intermediate-modellen dienen meerdere marts), vereenvoudigt debugging (problemen kunnen per laag worden geisoleerd) en verbetert de onboarding van nieuwe teamleden door een voorspelbare projectstructuur.

Vraag 6: Hoe werkt de Fusion Engine anders dan de klassieke dbt-executor?

De klassieke executor verwerkt modellen sequentieel per laag in de DAG. De Fusion Engine analyseert de volledige DAG en identificeert modellen die parallel kunnen worden uitgevoerd. Daarnaast implementeert de Fusion Engine intelligente caching: wanneer een upstream-model niet is gewijzigd sinds de laatste run, worden downstream-modellen die ervan afhangen overgeslagen. Dit resulteert in snellere iteratiecycli tijdens ontwikkeling en lagere compute-kosten in productie.

Conclusie

dbt blijft in 2026 het onbetwiste centrum van de moderne data-stack voor datatransformaties. De combinatie van SQL-gebaseerde modellering, robuuste testing en de nieuwe Fusion Engine maakt het een krachtig instrument voor data engineers op elk niveau.

De kernpunten voor interview-voorbereiding:

• Gelaagde architectuur: Begrijp het onderscheid tussen staging, intermediate en marts en wanneer elke laag wordt ingezet
• ref() en de DAG: Weet hoe dependency management werkt en waarom hardcoded referenties vermeden moeten worden
• Materialisaties: Ken de vier strategieen en hun trade-offs in termen van kosten, snelheid en consistentie
• Testing: Beheers zowel schema tests als custom tests en begrijp hoe deze in CI/CD worden geintegreerd
• Fusion Engine: Wees op de hoogte van de nieuwste ontwikkelingen in dbt Core v1.10 en de impact op performance
• Macros en Jinja: Demonstreer het vermogen om herbruikbare, onderhoudbare transformaties te schrijven

Door deze concepten grondig te beheersen en te kunnen toelichten met concrete voorbeelden, onderscheidt een kandidaat zich in technische interviews voor data engineering posities.