dbt ist die Transformationsschicht, die aus rohen Loads ein sauberes, nachvollziehbares Datenmodell macht. Versionierbar, testbar, dokumentiert. Genau das Fundament, auf dem belastbare BI und AI aufsetzen.
Was ist dbt?
dbt ist das T in ELT. Daten landen roh im Warehouse, dbt transformiert sie dort zu versionierten SQL-Modellen, mit Tests, Lineage und Doku. Die Logik lebt nicht mehr verstreut in BI-Tools und Skripten, sondern an einer Stelle, unter Versionskontrolle.
Das klingt nach Engineering-Disziplin, und genau das ist es. Der Effekt: Eine Kennzahl ist überall gleich definiert, ein Fehler ist nachvollziehbar, und neue Teammitglieder lesen das Modell statt es zu raten.
Wann dbt passt, und wann nicht
Sinnvoll, wenn:
- mehrere Quellen zu einem konsistenten Modell zusammenlaufen
- dieselben Definitionen mehrere Dashboards speisen
- Datenqualität und Lineage prüfbar sein müssen
- ein Team SQL und git-Disziplin mitbringt
Eher nicht, wenn:
- nur ein einzelner Report gebraucht wird
- es keine modellierte Datenbasis gibt, die transformiert werden will
- niemand die Modelle pflegt
Ohne dbt vs. mit dbt
| Kriterium | SQL im BI-Tool | dbt |
|---|---|---|
| Definitionen | pro Dashboard dupliziert | einmal, zentral |
| Tests | manuell, wenn überhaupt | bei jedem Build |
| Nachvollziehbarkeit | schwer | Lineage und Doku |
| Versionierung | keine | git |
| Onboarding | Wissen im Kopf | lesbares Modell |
Was Datascale mit dbt baut
Wir setzen das Modell auf und machen es wartbar:
- Projektstruktur, Staging- und Mart-Layer
- Modelle für die zentralen Marketing- und Revenue-Kennzahlen
- Tests gegen stille Datenfehler
- Orchestrierung über Dagster oder dbt Cloud
- Lineage und Doku für Ihr Team
- Anbindung an BI und, wo sinnvoll, an den AI-Layer
Das ganze Bild steht in der Data Platform & Governance: Lakehouse, Modellierung, Tests und Governance in einem. dbt läuft bei uns meist auf BigQuery, gespeist aus Quellen wie funnel.io oder Snowplow.
