Transformation

dbt: SQL wird zum getesteten Graphen.

dbt ist das „T“ in ELT – die Transformationsschicht direkt im Warehouse. Warum wir es einsetzen, was es ist und wie aus SQL-Dateien ein kompilierter, getesteter Abhängigkeitsgraph wird.

Warum dbt

Transformations-Layer · ELT

dbt ist kein Scheduler und kein Warehouse – es ist ein Compiler und Workflow-Layer für Analytics-Code. Sein Wert: Es macht aus einem Ordner fragiler SQL-Skripte einen Abhängigkeitsgraphen mit Tests, Dokumentation und nachvollziehbaren Änderungen. Statt Views von Hand in Reihenfolge zu bringen, verdrahtest du Modelle über ref() – den Rest leitet dbt ab.

SQL von Hand

Skripte und Views in loser Reihenfolge. Was bricht, wenn ich diese Tabelle ändere? Niemand weiß es sicher.

dbt

Modelle als Code, über ref() verknüpft. Der Graph ist die Wahrheit – Reihenfolge, Impact und Tests inklusive.

Der Graph

ref() baut die Reihenfolge

Referenzen erzeugen den DAG. dbt baut nur betroffene Teile neu, erkennt Impact und bricht CI bei Regressionen.

Vertrauen

Tests & Freshness eingebaut

not_null, unique, relationships und Source-Freshness laufen als Teil des Builds – nicht als Nachgedanke.

Engineering

Software-Praktiken für Daten

Version Control, Modularität (staging → marts), Wiederverwendung via Macros, generierte Doku & Lineage.

Entkopplung

Logik getrennt von Persistenz

Die Materialization (view · table · incremental) entscheidet, wie ein SELECT zum Objekt wird – die Logik bleibt gleich.

In unserem Stack ist dbt das T nach der dlt-Ingestion: Die benannten Supply-Chain-KPIs – OTIF, Lead Time, Fill Rate – leben hier als getestete Marts-Modelle. Aktuelle Entwicklung: die neue Rust-basierte Fusion-Engine bringt echtes SQL-Verständnis in den Compile-Schritt.

Was ist dbt

Projekt · Ausführung

Das Transformations-Framework des modernen Data Stack. Du schreibst Modelle als SELECT-Statements; dbt kompiliert das Jinja-Templating zu reinem SQL, baut aus ref() den DAG, führt die Modelle im Warehouse aus und testet sie. Ausführung als CLI (dbt Core) oder über die dbt-Plattform.

Dein Projekt

Was du schreibst

ModelSELECT-Statement, das zu Tabelle oder View wird.SourceRohtabelle aus externem System – Startpunkt des Graphs.ref() / source()Referenzen, aus denen dbt den DAG ableitet.Materializationview · table · incremental · ephemeral.TestAssertion am Knoten: not_null, unique, relationships, singular.SnapshotBewahrt langsam ändernde Zustände (SCD).SeedCSV im Repo, als Tabelle geladen.MacroWiederverwendbare, parametrisierte Jinja-SQL-Logik.ExposureNachgelagerter Konsument – Dashboard, ML, API.

Ausführung

Was dbt daraus macht

ProfileVerbindung zum Warehouse (bei uns: Postgres).CompileRendert Jinja → reines, ausführbares SQL.ManifestDer kompilierte Graph des gesamten Projekts.AdapterWarehouse-spezifische Übersetzung (dbt-postgres).Docs & LineageGenerierte Doku plus interaktiver Abhängigkeitsgraph.

Merksatz: Ein dbt-Projekt ist ein Graph. Sources sind die Rohkanten, Modelle die Transformationen, Tests die Zusicherungen, Exposures die Konsumenten.

Wie ein Build abläuft

läuft · Endlosschleife

Der Befehl dbt build: dbt kompiliert Jinja zu SQL und baut aus ref() – führt die Modelle in Abhängigkeitsreihenfolge im Warehouse aus, je nach Materialization – prüft Tests und Source-Freshness – aktualisiert Docs & Lineage.

Sourceraw.orderssource✓ freshness

Sourceraw.finnhubsource✓ freshness

Model · stagingstg_ordersview✓ 3 tests

Model · stagingstg_pricesview✓ 2 tests

Model · martfct_otifincremental✓ 4 tests

Model · martdim_suppliertable✓ 3 tests

Exposuremetabase_kpidashboard✓ lineage

models/marts/fct_otif.sqlJinja

-- Modell mit Jinja-Templating
{{ config(materialized='incremental') }}

select
  o.order_id,
  o.promised_date,
  o.delivered_date,
  o.delivered_date <= o.promised_date as on_time
from {{ ref('stg_orders') }} o
join {{ source('raw','finnhub') }} p
  on p.symbol = o.symbol

-- target/compiled/.../fct_otif.sql
create table analytics.fct_otif as

select
  o.order_id,
  o.promised_date,
  o.delivered_date,
  o.delivered_date <= o.promised_date as on_time
from analytics.stg_orders o
join raw.finnhub p
  on p.symbol = o.symbol

$ dbt build0 / 5 · 0 tests

ref() Abhängigkeitgebautes ModellSource

“Ein dbt-Projekt ist ein Graph.”

— dbt als Analytics-Compiler