dbt (data build tool) ist ein quelloffenes Werkzeug, mit dem Teams Datenmodelle (aufbereitete Auswertungstabellen für Berichte und Analysen) in SQL (Abfragesprache für Datenbanken) beschreiben, versionieren, testen und im zentralen Datenspeicher berechnen lassen. Es übernimmt das „T" (Transform) in ELT (Extract-Load-Transform): Die Rechenarbeit läuft im Datenspeicher selbst, dbt setzt die Abfragen zusammen, sortiert ihre Reihenfolge und erzeugt daraus eine Übersicht, welche Tabelle aus welcher entsteht (Lineage).
Was ist dbt?
dbt ist ein SQL-basiertes Werkzeug, das Datenmodelle im Data Warehouse (zentrale Analyse-Datenbank) aus Abfragen aufbaut. Jedes Modell ist eine SELECT-Anweisung, also eine Datenabfrage, in einer .sql-Datei; dbt erkennt über zwei Verweis-Funktionen (ref() für andere Modelle, source() für Rohdaten), in welcher Reihenfolge die Modelle berechnet werden müssen. Vorlagen-Bausteine (Jinja-Templating) werden vor der Ausführung zu reinem SQL zusammengesetzt. Das Ergebnis landet je nach Konfiguration als View (nur gespeicherte Abfrage), Tabelle (vollständig neu geschrieben), Incremental Model (nur neue Zeilen ergänzt) oder Ephemeral Model (temporär, nur zur Laufzeit) im Datenspeicher. Rechenlast und Speicher liegen dabei vollständig im Ziel-System; dbt selbst hält keine Daten.
Das Projekt entstand 2016 bei Fishtown Analytics (heute [dbt Labs](https://www.getdbt.com/)) und ist Open Source unter der Apache-2.0-Lizenz veröffentlicht. Es hat sich als De-facto-Standard für SQL-basierte Transformationen im modernen Analytics-Stack etabliert. Zwei Distributionen teilen sich dasselbe Projekt-Format: dbt Core als kostenloses Kommandozeilen-Werkzeug (Python-Paket) und dbt Cloud als kommerzielle SaaS-Plattform mit IDE, Scheduler, CI/CD-Integration, Semantic Layer und einer API.
Die Kernbausteine eines dbt-Projekts sind Models (die eigentlichen SELECT-Statements), Tests (Schema-Tests wie unique, not_null, relationships sowie freie Data-Tests als SQL), Snapshots (Slowly Changing Dimensions Type 2), Seeds (kleine Tabellen aus CSV-Dateien), Macros (wiederverwendbare Jinja-Funktionen), Sources (Deklaration von Rohdaten-Tabellen) und Exposures (Verweise auf Downstream-Konsumenten wie Dashboards). Aus den ref()- und source()-Kanten leitet dbt einen Lineage-Graph und die generierte Dokumentation ab. Für die Ausführung gegen ein Warehouse ist ein Adapter erforderlich: [dbt-databricks](https://github.com/databricks/dbt-databricks), dbt-snowflake, dbt-bigquery, dbt-redshift und weitere gehören zum offiziellen Ökosystem.
Abgrenzung zu Nachbar-Werkzeugen
Der Begriff „Transformation" wird für sehr unterschiedliche Werkzeuge verwendet. Die folgende Tabelle klärt die vier häufigsten Verwechslungen im ELT-Stack.
| Werkzeug | Abgrenzung zu dbt |
|---|---|
| Apache Airflow | Orchestrator für heterogene Workflows: startet zeitgesteuert Systeme und löst Task-Abhängigkeiten. dbt orchestriert nur innerhalb eines Projekts; ein Airflow-DAG ruft dbt-Runs als Task auf, nicht umgekehrt |
| Databricks Asset Bundles | YAML-Deployment-Format für Jobs, Pipelines und Modelle in einem Databricks-Workspace. Beschreibt, wie ein Artefakt ausgerollt wird. dbt beschreibt, wie Daten transformiert werden |
| Fivetran, Airbyte | Ingestion-Tools für das „E" und „L" in ELT: bewegen Rohdaten aus Quellsystemen ins Warehouse. dbt setzt danach an und transformiert die geladenen Daten |
| Great Expectations, Soda | Dedizierte Data-Quality-Frameworks mit breiterer Testbibliothek (statistische Profile, Distributionschecks). dbt-Tests bleiben bewusst schmal und an das dbt-Projekt gebunden |
| Databricks Declarative Pipelines | Deklaratives Pipeline-Framework innerhalb der Databricks-Plattform mit Expectations, Streaming-Semantik und Change-Data-Feed. dbt ist plattformagnostisch, deckt aber kein natives Streaming ab |
Beispiel: dbt-Projekt gegen Databricks
Ein typisches dbt-Projekt liegt in einem Git-Repository und ist nach Modell-Ebenen strukturiert: models/staging/ typisiert und benennt die Spalten der Rohdaten, models/intermediate/ konformisiert Joins und Kalkulationen, models/marts/ liefert die Star-Schemata für BI und Downstream-Konsumenten. Rohdaten kommen als Bronze-Tabellen aus einer Fivetran-Ingestion im Unity Catalog an. Der dbt-databricks-Adapter materialisiert die Modelle als Delta-Tabellen und respektiert Unity-Catalog-Objekte, Delta-Materialisierungen und Liquid Clustering.
# models/marts/sales/fct_orders.sql
{{ config(
materialized='incremental',
unique_key='order_id',
incremental_strategy='merge'
) }}
select
order_id,
customer_id,
order_date,
order_total
from {{ ref('stg_orders') }}
{% if is_incremental() %}
where order_date > (select max(order_date) from {{ this }})
{% endif %}In der Ausführung schickt dbt das kompilierte SQL an ein Databricks-SQL-Warehouse. Ein Airflow-DAG orchestriert den Lauf: erst der Fivetran-Sync, dann dbt build --select state:modified+ gegen das Warehouse, danach der Refresh der Power-BI-Datasets. Databricks Asset Bundles deployen die Job-Definition selbst über Dev-, Stage- und Prod-Targets. Damit ist dbt architektonisch zwischen der Ingestion-Schicht und dem BI-Layer positioniert; die Ausführung bleibt push-down im Warehouse, dbt hält keine Daten im eigenen Prozess.
dbt (data build tool) im eigenen Unternehmen umsetzen?
Wir zeigen, wie sich das in deiner Systemlandschaft konkret abbilden lässt.