dbt in 2026: Datentransformationen, Testing und Interview-Fragen für Data Engineers

dbt (data build tool) hat sich als De-facto-Standard für Datentransformationen in modernen Data-Engineering-Stacks etabliert. Im Jahr 2026 nutzen Unternehmen jeder Größe dbt, um ihre analytischen Datenmodelle zu definieren, zu testen und zu dokumentieren. Für Fachkräfte, die sich auf Vorstellungsgespräche im Bereich Data Engineering vorbereiten, gehört fundiertes dbt-Wissen zu den am häufigsten abgefragten Kompetenzen. Dieser Artikel behandelt die wesentlichen Konzepte von dbt, aktuelle Neuerungen in Version 1.10 und typische Interview-Fragen mit ausführlichen Antworten.

Schichtenmodellierung: Staging, Intermediate und Marts

Ein zentrales Architekturprinzip in dbt ist die Aufteilung der Transformationslogik in klar getrennte Schichten. Dieses Muster sorgt für Wartbarkeit, Testbarkeit und Nachvollziehbarkeit der gesamten Datenpipeline.

Staging Layer

Die Staging-Schicht dient als erste Bereinigungsstufe. Hier werden Rohdaten aus Quellsystemen in ein einheitliches Format gebracht, ohne geschäftliche Logik hinzuzufügen. Typische Operationen umfassen Typkonvertierungen, Umbenennungen und grundlegende Filterung.

-- 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

Intermediate Layer

In der Zwischenschicht werden Daten aus mehreren Staging-Modellen zusammengeführt und aggregiert. Diese Modelle kapseln Geschäftslogik, die von verschiedenen Endmodellen gemeinsam genutzt wird.

-- 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

Marts Layer

Die Marts-Schicht enthält die endgültigen, für Analysten und BI-Tools optimierten Tabellen. Hier kommen häufig inkrementelle Materialisierungen zum Einsatz, um bei großen Datenmengen die Laufzeiten zu minimieren.

-- 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)

Die ref()-Funktion und der DAG

Der Directed Acyclic Graph (DAG) ist das Herzstück jedes dbt-Projekts. Durch die konsequente Verwendung der ref()-Funktion erstellt dbt automatisch einen Abhängigkeitsgraphen, der die korrekte Ausführungsreihenfolge aller Modelle sicherstellt.

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

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

Die Vorteile der ref()-Funktion gehen weit über die reine Abhängigkeitsverwaltung hinaus. Sie ermöglicht umgebungsspezifische Ausführung, sodass dasselbe Modell in Entwicklungs-, Staging- und Produktionsumgebungen korrekt auf die jeweiligen Schemata verweist. Darüber hinaus erkennt dbt zirkuläre Abhängigkeiten bereits zur Kompilierungszeit und verhindert so fehlerhafte Pipeline-Ausführungen.

In Vorstellungsgesprächen wird häufig gefragt, warum hartcodierte Tabellenreferenzen problematisch sind. Die Antwort liegt in der fehlenden Nachverfolgbarkeit: Ohne ref() kann dbt weder die Ausführungsreihenfolge garantieren noch Impact-Analysen durchführen, wenn sich ein Upstream-Modell ändert.

Materialisierungen: view, table, incremental und ephemeral

dbt bietet vier grundlegende Materialisierungsstrategien, die jeweils für unterschiedliche Anwendungsfälle optimiert sind.

View erstellt eine Datenbankansicht, die bei jeder Abfrage neu berechnet wird. Diese Strategie eignet sich für leichtgewichtige Transformationen mit geringem Datenvolumen, etwa Staging-Modelle.

Table materialisiert das Ergebnis als physische Tabelle. Bei jedem dbt-Lauf wird die Tabelle vollständig neu erstellt. Dies bietet schnelle Lesezeiten, verbraucht jedoch mehr Speicher und Rechenzeit.

Incremental verarbeitet nur neue oder geänderte Daten seit dem letzten Lauf. Diese Strategie ist für große Faktentabellen unverzichtbar und kann die Laufzeiten um Größenordnungen reduzieren. Die Konfiguration erfordert einen unique_key und eine Bedingung, die bestimmt, welche Zeilen als neu gelten.

Ephemeral erzeugt keine physische Repräsentation in der Datenbank. Stattdessen wird das Modell als Common Table Expression (CTE) in abhängige Modelle eingebettet. Dies eignet sich für Hilfsmodelle, die ausschließlich als Bausteine für andere Modelle dienen.

Datenqualität mit dbt-Tests sicherstellen

Robuste Datenpipelines erfordern systematische Tests. dbt unterscheidet zwischen generischen Tests, die deklarativ in YAML-Dateien definiert werden, und singulären Tests, die als eigenständige SQL-Abfragen formuliert sind.

Generische Tests in YAML

Generische Tests werden direkt in der Schema-Definition eines Modells konfiguriert. Die vier eingebauten Testtypen decken die häufigsten Datenqualitätsanforderungen ab.

# 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

Der unique-Test stellt sicher, dass keine doppelten Werte existieren. not_null prüft auf fehlende Werte. accepted_values validiert, dass eine Spalte nur vordefinierte Werte enthält. relationships überprüft referenzielle Integrität zwischen Modellen.

Singuläre Tests

Für komplexere Validierungen, die sich nicht als generische Tests ausdrücken lassen, bietet dbt singuläre Tests. Diese SQL-Abfragen geben Zeilen zurück, die als fehlerhaft gelten. Ein leeres Ergebnis bedeutet, dass der Test bestanden wurde.

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

In der Praxis empfiehlt es sich, Tests in CI/CD-Pipelines zu integrieren. So werden fehlerhafte Daten erkannt, bevor sie in Produktionsumgebungen gelangen. Viele Teams konfigurieren dbt test als obligatorischen Schritt nach jedem dbt run.

dbt Core v1.10 und die Fusion Engine

Mit Version 1.10 hat dbt Labs die sogenannte Fusion Engine eingeführt, die fundamentale Verbesserungen in der Ausführungsgeschwindigkeit bietet. Die Fusion Engine kompiliert dbt-Modelle in optimierte Ausführungspläne, die parallele Verarbeitung auf DAG-Ebene maximieren.

Zu den wichtigsten Neuerungen gehören Multi-Thread-Kompilierung, die die Parsing-Zeit bei großen Projekten mit mehreren hundert Modellen erheblich reduziert, sowie adaptive Materialisierung, bei der dbt automatisch entscheidet, ob ein inkrementeller Lauf effizienter als ein vollständiger Rebuild ist.

Darüber hinaus unterstützt Version 1.10 native Python-Modelle ohne externes Orchestrierungstool. Data Engineers können nun SQL- und Python-Transformationen im selben Projekt kombinieren und von einheitlichem Testing und Dokumentation profitieren.

Für Interview-Vorbereitungen ist es wichtig zu wissen, dass die Fusion Engine abwärtskompatibel ist. Bestehende Projekte profitieren von den Leistungsverbesserungen ohne Code-Änderungen.

Macros und Jinja-Templating

dbt nutzt Jinja als Templating-Engine, um SQL-Code dynamisch und wiederverwendbar zu gestalten. Macros sind dabei das zentrale Werkzeug zur Vermeidung von Code-Duplikation.

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

Dieses Macro kann in jedem Modell mit {{ cents_to_dollars('amount_cents') }} aufgerufen werden. Der Vorteil liegt in der zentralen Wartung: Wenn sich die Berechnungslogik ändert, muss nur das Macro angepasst werden, nicht jedes einzelne Modell.

Fortgeschrittene Anwendungsfälle umfassen dynamische Generierung von Staging-Modellen, umgebungsabhängige Konfigurationen und benutzerdefinierte Materialisierungen. In Interviews wird häufig nach dem Unterschied zwischen Macros und Modellen gefragt: Macros generieren SQL-Fragmente, während Modelle vollständige, materialisierbare Abfragen darstellen.

Typische dbt-Interview-Fragen und Antworten

Die folgenden Fragen werden in Vorstellungsgesprächen für Data-Engineering-Positionen regelmäßig gestellt.

Frage 1: Was ist der Unterschied zwischen source() und ref()?

Die source()-Funktion verweist auf Rohdaten aus externen Quellsystemen, die nicht von dbt verwaltet werden. Sie ermöglicht Freshness-Checks und dokumentiert die Herkunft der Daten. Die ref()-Funktion hingegen referenziert andere dbt-Modelle innerhalb des Projekts und baut den Abhängigkeitsgraphen auf. Ein Staging-Modell nutzt typischerweise source() für den Input und wird selbst über ref() von nachgelagerten Modellen referenziert.

Frage 2: Wann sollte eine inkrementelle Materialisierung verwendet werden?

Inkrementelle Modelle eignen sich für große Faktentabellen mit append-only oder langsam ändernden Daten. Die typischen Kriterien sind: Datenvolumen über mehrere Millionen Zeilen, ein zuverlässiger Zeitstempel zur Identifikation neuer Daten und eine Geschäftsanforderung, die vollständige Rebuilds zeitlich nicht zulässt. Es ist wichtig zu betonen, dass inkrementelle Modelle komplexer sind und Randfälle wie Late-Arriving Data berücksichtigt werden müssen.

Frage 3: Wie funktioniert der DAG in dbt und warum ist er wichtig?

Der DAG wird automatisch aus allen ref()- und source()-Aufrufen konstruiert. Er bestimmt die Ausführungsreihenfolge, ermöglicht Parallelisierung unabhängiger Pfade und bildet die Grundlage für Impact-Analysen. Wenn ein Staging-Modell geändert wird, zeigt der DAG alle betroffenen nachgelagerten Modelle. Dies ist besonders in großen Projekten mit mehreren Teams unverzichtbar.

Frage 4: Wie unterscheiden sich generische und singuläre Tests?

Generische Tests werden deklarativ in YAML konfiguriert und sind wiederverwendbar (unique, not_null, accepted_values, relationships). Singuläre Tests sind individuelle SQL-Abfragen für komplexe Geschäftsregeln, die sich nicht mit generischen Tests abbilden lassen. Beide Typen geben fehlerhafte Zeilen zurück, wobei ein leeres Ergebnis einen bestandenen Test signalisiert.

Frage 5: Was ist der Zweck von Packages in dbt?

Packages ermöglichen die Wiederverwendung von Macros, Tests und Modellen über Projekte hinweg. Das bekannteste Beispiel ist dbt_utils, das häufig benötigte Funktionen wie surrogate_key, pivot und date_spine bereitstellt. Packages werden in der packages.yml deklariert und mit dbt deps installiert. Sie fördern Standardisierung und reduzieren redundanten Code in Organisationen mit mehreren dbt-Projekten.

Frage 6: Wie wird mit Schema-Änderungen in inkrementellen Modellen umgegangen?

Standardmäßig ignoriert dbt neue Spalten bei inkrementellen Läufen. Mit der Konfiguration on_schema_change stehen vier Strategien zur Verfügung: ignore (Standard), fail (Lauf bricht ab), append_new_columns (neue Spalten werden hinzugefügt) und sync_all_columns (vollständige Synchronisation). In der Praxis ist append_new_columns die häufigste Wahl, da sie Flexibilität bietet, ohne bestehende Daten zu gefährden.

Fazit

dbt bleibt auch 2026 das zentrale Werkzeug für Datentransformationen in analytischen Umgebungen. Die Kombination aus SQL-basierter Modellierung, integriertem Testing und automatischer Dokumentation macht es zum Standard in modernen Data Stacks.

Die wichtigsten Erkenntnisse für die Interview-Vorbereitung:

• Die Dreischichtenarchitektur (Staging, Intermediate, Marts) sorgt für klare Verantwortlichkeiten und Wartbarkeit
• Die ref()-Funktion ist fundamentaler als nur eine Tabellenreferenz: Sie baut den DAG auf und ermöglicht umgebungsübergreifende Ausführung
• Inkrementelle Materialisierungen erfordern sorgfältige Planung bezüglich unique_key, Strategie und Schema-Änderungen
• Systematisches Testing mit generischen und singulären Tests ist Pflicht für produktionsreife Pipelines
• Die Fusion Engine in v1.10 bringt signifikante Leistungsverbesserungen ohne Code-Änderungen
• Macros und Jinja-Templating eliminieren Code-Duplikation und fördern Konsistenz

Wer diese Konzepte versteht und mit praktischen Beispielen belegen kann, ist für dbt-bezogene Interview-Fragen bestens vorbereitet.