Databricks + dbt: wie der moderne Stack für Transformationen arbeitet

dbt macht aus Anweisungen im SQL SELECT getestete, versionierte und dokumentierte Pipelines für Transformationen. Databricks liefert die Rechenmaschine und den Speicher in Delta Lake. Zusammen geben sie den Analytics Engineers einen Arbeitsablauf, in dem Transformationen wie Software im Review gelesen, bei jedem Lauf getestet und automatisch dokumentiert werden.

Diese Kombination ist zu einer verbreiteten Architektur für Teams geworden, die Praktiken des Software Engineering auf Daten anwenden wollen, ohne SQL zu verlassen. Sie schreiben ein SELECT, dbt übersetzt es in DDL, und Databricks führt es in großem Maßstab aus. Das Ergebnis ist eine Tabelle in Delta, registriert im Unity Catalog und bereit für nachgelagerte BI-Werkzeuge, ML-Modelle oder Reverse ETL.

Warum Databricks + dbt so verbreitet sind

Vor dbt haben viele Datenteams ihre Daten mit eigenen Skripten in Python transformiert, orchestriert über Airflow. Die Skripte waren schwer zu testen, selten dokumentiert und für neue Teammitglieder schwer zu lesen. Wenn um 3 Uhr nachts etwas kaputtging, hieß Fehlersuche, sich durch Hunderte Zeilen PySpark oder pandas zu arbeiten.

dbt hat den Arbeitsablauf verändert, indem es SQL zur Einheit der Transformation gemacht hat. Jedes Modell ist eine SELECT-Anweisung in einer eigenen Datei. Abhängigkeiten zwischen Modellen werden mit Aufrufen von ref() erklärt, und dbt löst sie automatisch zu einem gerichteten azyklischen Graphen (DAG) auf. Tests werden in YAML neben den Modellen festgelegt. Die Dokumentation entsteht aus demselben YAML und aus den Kommentaren im SQL.

Databricks hat die Schicht der Rechenleistung verändert, indem es SQL Warehouses bereitstellt: Endpunkte für Rechenleistung, die auf Lasten in SQL optimiert sind, angeboten als Serverless, Pro oder Classic, wobei serverlose Warehouses typischerweise in 2 bis 6 Sekunden starten und schnell skalieren. Statt Spark-Cluster hochzufahren und JVM-Konfigurationen zu verwalten, richten Analytics Engineers dbt über den Adapter dbt-databricks, den Databricks selbst veröffentlicht und der den dreistufigen Namensraum von Unity Catalog unterstützt, auf ein SQL Warehouse und überlassen Databricks den Rest. Die Ergebnisse landen als Tabellen in Delta Lake, mit ACID-Transaktionen, Time Travel und erzwungenem Schema von Haus aus.

Die Kombination vereinfacht auch die Orchestrierung. dbt bestimmt die Reihenfolge der Modelle selbst, der Scheduler muss also nur einen Lauf anstoßen: einen Job in der dbt-Plattform, einen dbt-Task in Databricks Lakeflow Jobs oder einen externen Orchestrator wie Airflow. Ein großer Teil der Logik für Transformationen, die früher in eigenen Operatoren in Python lag, kann in Modelle in SQL wandern, mit Tests und Dokumentation gleich dabei.

Die Architektur: wie die Teile zusammenpassen

Der Stack aus dbt und Databricks hat vier Stufen. Die Rohdaten kommen aus den Quellsystemen über Werkzeuge zur Beladung wie Fivetran oder Airbyte (Fivetran und dbt Labs haben ihren Zusammenschluss am 1. Juni 2026 abgeschlossen) und landen als Staging-Tabellen in Delta Lake. dbt liest diese Staging-Tabellen, wendet Transformationen an, die in die Schichten Staging, Intermediate und Marts gegliedert sind, und schreibt die Ergebnisse als neue Tabellen oder Views in Delta zurück. Ein SQL Warehouse führt jede Anweisung aus. Der Unity Catalog steuert durchgehend Zugriff und Metadaten.

Das Muster der Schichtung hält die Transformationen geordnet. Staging-Modelle (stg_) benennen Spalten um, wandeln Typen und bereinigen die Rohdaten, je ein Modell pro Quelltabelle. Intermediate-Modelle (int_) verbinden Staging-Modelle und wenden die fachliche Logik an. Mart-Modelle (fct_, dim_) erzeugen die fertigen, für die Analyse bereiten Tabellen, geordnet nach fachlichen Domänen.

dbt verwaltet die Reihenfolge der Abhängigkeiten automatisch. Wenn Sie dbt build fahren, übersetzt es das SELECT jedes Modells in DDL, löst den DAG auf und führt die Anweisungen in der richtigen Reihenfolge aus. Ändert sich ein Staging-Modell, weiß dbt, welche Intermediate- und Mart-Modelle davon abhängen, und baut sie ebenfalls neu.

Materialisierungen auf Databricks

dbt hat fünf eingebaute Materialisierungen (View, Table, Incremental, Ephemeral und Materialized View), Snapshots sind ein eigener Ressourcentyp, und der Adapter dbt-databricks ergänzt Streaming Tables. Vier Möglichkeiten decken die meisten Modelle ab, und die richtige Wahl hängt an der Größe der Tabelle, an den Mustern der Abfragen und an den Anforderungen an die Aktualität.

View ist die leichteste Möglichkeit. dbt legt eine View in SQL an: Es werden keine Daten gespeichert, es ist kein Neubau nötig, und das Ergebnis ist immer frisch. Views passen gut zu Staging-Modellen und einfachen Transformationen. Der Preis dafür ist, dass jede Abfrage das darunterliegende SQL erneut ausführt.

Table materialisiert bei jedem Lauf das vollständige Ergebnis als Tabelle in Delta. Die Abfragen sind schnell, weil die Daten vorberechnet sind, doch die Dauer des Neubaus wächst mit dem Datenvolumen. Tabellen passen zu Modellen der Mart-Schicht, deren voller Neubau noch in den Zeitplan passt.

Incremental verarbeitet nur neue oder geänderte Zeilen. Sie setzen einen Filter mit WHERE auf einen Zeitstempel oder eine ID-Spalte in das Makro is_incremental(), und auf Databricks führt dbt die Ergebnisse standardmäßig per Merge in die bestehende Delta-Tabelle zusammen und aktualisiert dabei die Zeilen, die zum unique_key passen. Für große Faktentabellen ist das der wichtigste Hebel: Ein inkrementeller Lauf liest nur den jüngsten Ausschnitt einer Ereignistabelle, statt sie ganz neu zu bauen.

Snapshot hält langsam veränderliche Dimensionen vom Typ 2 fest. dbt vergleicht den aktuellen Stand einer Quelltabelle mit ihrem vorigen Snapshot und legt historische Datensätze mit Zeitstempeln in dbt_valid_from und dbt_valid_to an. Nutzen Sie Snapshots, wenn Sie verfolgen müssen, wie sich Attribute einer Dimension über die Zeit ändern, etwa die Preisstufe eines Kunden oder die Abteilung einer Mitarbeiterin.

Eine praktische Regel: Wechseln Sie auf Incremental, sobald ein voller Neubau nicht mehr in Ihren Zeitplan oder Ihr Budget für Rechenleistung passt. Bis dahin lohnt sich die zusätzliche Komplexität der inkrementellen Logik (Schlüssel für den Merge, Filter auf Zeitstempel, der Umgang mit verspätet eintreffenden Daten) meist nicht.

Tests und Datenqualität

Das Rahmenwerk für Tests in dbt fährt nach jedem Build Zusicherungen gegen Ihre Daten. Die Tests werden in Schemadateien in YAML neben den Modellen festgelegt, die sie prüfen.

Generische Data Tests decken die häufigsten Prüfungen ab, und dbt liefert vier davon mit: unique (keine Dubletten in einer Schlüsselspalte), not_null (Pflichtfelder sind gefüllt), accepted_values (Statusfelder enthalten nur bekannte Werte) und relationships (Fremdschlüssel verweisen auf bestehende Datensätze in der übergeordneten Tabelle). Sie erklären sie in wenigen Zeilen YAML, und dbt erzeugt das SQL, das sie prüft.

Singuläre Data Tests decken fachliche Regeln ab. Sie schreiben eine Abfrage in SQL, die die Zeilen zurückgibt, welche die Regel verletzen. Gibt die Abfrage Zeilen zurück, ist der Test fehlgeschlagen. Ein Beispiel ist ein Test, der Bestellungen mit negativem Umsatz findet:

SELECT order_id, revenue FROM fct_orders WHERE revenue < 0

Mit einer solchen Prüfung fangen Teams Fehler aus Migrationen ab, etwa doppelt gezählte Datensätze zu Erstattungen beim Umzug von einem alten ERP, und zwar beim ersten produktiven Lauf statt erst im Dashboard. dbt nennt sie Data Tests, um sie von Unit Tests zu unterscheiden, die die Logik eines Modells gegen feste Eingabezeilen prüfen.

Die Tests laufen als Teil von dbt build. Schlägt ein Test fehl (beim voreingestellten Schweregrad error), überspringt dbt die Modelle, die ihm nachgelagert sind. Das ist der entscheidende Unterschied zum herkömmlichen ETL, wo Tests, sofern es sie überhaupt gibt, meist ein getrennter, abgehängter Schritt sind, den niemand ansieht, bis etwas sichtbar kaputtgeht.

Die Leistung optimieren

dbt übernimmt die Logik der Transformation, doch die Leistung hängt daran, wie die darunterliegenden Tabellen in Delta aufgebaut sind und wie das SQL Warehouse von Databricks konfiguriert ist.

OPTIMIZE und Z-ORDER sind die klassischen Werkzeuge für die Anordnung der Daten. OPTIMIZE verdichtet kleine Dateien zu größeren und senkt damit die Zahl der Dateizugriffe je Abfrage. Z-ORDER legt zusammengehörige Daten anhand ihrer Spaltenwerte nebeneinander in dieselben Dateien: Wenn Dashboards immer nach region und date filtern, überspringen Abfragen auf diesen Spalten mehr Dateien. Auf verwalteten Tabellen in Unity Catalog kann Predictive Optimization OPTIMIZE für Sie ausführen.

Liquid Clustering ersetzt Z-ORDER und die Partitionierung, und Databricks empfiehlt es für alle neuen Tabellen. Es clustert inkrementell, und mit CLUSTER BY AUTO wählt Databricks die Schlüssel anhand der Abfragemuster. In dbt-databricks setzen Sie es mit liquid_clustered_by oder auto_liquid_cluster; mit liquid_clustered_by führt der Adapter nach jedem Lauf OPTIMIZE aus, sofern Sie das nicht überspringen. Eine bestehende Tabelle ohne Partitionen lässt sich mit ALTER TABLE umstellen; eine partitionierte lässt sich ab Databricks Runtime 18.1 umwandeln.

Die Größe des SQL Warehouse zählt mehr, als die meisten Teams annehmen. Ein zu kleines Warehouse lässt Abfragen anstehen und auf die Platte auslagern. Ein zu großes verschwendet Ausgaben für DBU. Beginnen Sie klein, beobachten Sie die Laufzeiten der Abfragen und die Länge der Warteschlange in der Historie des SQL Warehouse und skalieren Sie von dort. Photon, die vektorisierte Maschine in C++, die die Ausführung von SQL beschleunigt und mit den APIs von Spark verträglich bleibt, ist die voreingestellte Maschine der SQL Warehouses, das von dbt erzeugte SQL läuft also bereits darauf.

Die Strategien inkrementeller Modelle wirken ebenfalls auf die Leistung. Der Adapter dbt-databricks unterstützt append, insert_overwrite, merge (die Voreinstellung auf Delta), replace_where, delete+insert und microbatch. merge behandelt Upserts über einen unique_key; append ist die einfachste, passt aber nur zu unveränderlichen Daten aus Ereignissen; replace_where überschreibt nur die Zeilen, die zu Ihren incremental_predicates passen; und microbatch verarbeitet zeitbasierte Stapel. Filtern Sie bei jeder Strategie die Quellseite auf den Ausschnitt, der neue Datensätze enthalten kann, damit Databricks weniger Daten liest.

CI/CD und Deployment

Projekte in dbt nutzen denselben Ablauf in Git wie Anwendungscode: Feature-Branches, Pull Requests, Code Review und automatische Tests vor dem Merge.

Der Schritt der CI fährt dbt build --select state:modified+ und baut damit nur die geänderten Modelle und die von ihnen abhängigen nachgelagerten Modelle. Das hält die CI schnell: Ein großes Projekt baut bei einem typischen PR womöglich nur eine Handvoll Modelle neu, solange die CI mit dem Manifest eines produktiven Laufs vergleichen kann. Die Tests laufen als Teil des Builds. Schlägt ein Test fehl, ist der PR blockiert.

Die Strategie der Umgebungen trennt die Belange sauber. Jede Entwicklerin bekommt ein eigenes Schema (etwa dev_jane), damit Experimente andere Teammitglieder nicht treffen. Eine Umgebung für das Staging fährt den vollständigen Build gegen Daten in produktiver Größe als letzten Schritt der QA. Die produktive Umgebung bedient die Tabellen, aus denen BI-Werkzeuge und andere Data Consumer lesen.

Für die Ausführung wählen Teams zwischen der dbt-Plattform (früher dbt Cloud: verwaltete Zeitpläne, die IDE dbt Studio im Browser, Historie der Jobs) und dbt Core mit einem Orchestrator wie Airflow, Dagster oder einem dbt-Task in Lakeflow Jobs. Die dbt-Plattform ist einfacher zu betreiben. dbt Core gibt mehr Kontrolle über die Umgebung der Ausführung und passt besser zu Teams, die Airflow ohnehin für Lasten außerhalb von dbt fahren. Die neuere Maschine von dbt Labs in Rust, 2025 als dbt Fusion Engine eingeführt und heute dbt v2, führt Databricks als allgemein verfügbar.

Dokumentation, Lineage und die Anbindung an Dawiso

dbt erzeugt Dokumentation und Graphen der Lineage aus den Referenzen zwischen den Modellen. dbt docs generate erzeugt eine durchsuchbare Website, die jedes Modell, seine Spalten, Beschreibungen und Tests sowie den DAG der Abhängigkeiten zeigt. Die Konfiguration persist_docs schiebt die Beschreibungen der Modelle in die Kommentare der Tabellen in Databricks, sodass sie in der Oberfläche des Unity Catalog sichtbar werden. In der dbt-Plattform stellt dbt Catalog (früher dbt Explorer) dieselben Metadaten bereit.

Doch die Dokumentation von dbt hat eine Grenze in ihrem Umfang: Sie kennt nur, was innerhalb des dbt-Projekts liegt. Sie sieht weder die vorgelagerten Pipelines der Beladung noch die nachgelagerten Berichte im BI, weder die Datei in Excel, die jemand von Hand hochlädt, noch die anderen Datenplattformen der Organisation. Für ein Team, das dbt neben Snowflake, einem alten Warehouse in Oracle und einer Reihe von Dashboards in Power BI betreibt, deckt die Dokumentation von dbt nur den Teil der Datenlandschaft ab, den dbt selbst baut.

Genau hier fügt sich Dawiso ein. Sein dbt-Konnektor liest Metadaten der dbt-Plattform (Projekte, Jobs, Modelle, Quellen, Tests und Exposures) in den Datenkatalog, neben den Metadaten aus den anderen Konnektoren von Dawiso wie dem Databricks-Konnektor. Im Business Glossary lässt sich ein Begriff wie „Umsatz“ mit den Objekten im Katalog verknüpfen, die ihn umsetzen, etwa mit einer Spalte fct_orders.revenue. Die Data Lineage verbindet die Beziehungen aus dbt (Modell zu Modell, Modell zu Quelle, Exposure zu Modell) mit der Lineage aus anderen Konnektoren, etwa der Lineage auf Spaltenebene, die der Databricks-Konnektor aus system.access.column_lineage liest. Der dbt-Konnektor selbst liefert Beziehungen auf Objektebene, keine Lineage von Spalte zu Spalte.

Über das Model Context Protocol (MCP) können KI-Agenten den Dawiso MCP-Server nutzen, um den Katalog zu durchsuchen, Details zu Objekten zu lesen, die Lineage zu verfolgen und Datenproben anzusehen, und für Nutzer, deren Rolle es erlaubt, über seine Schreibwerkzeuge auch Änderungen zurückzuschreiben. Ein KI-Assistent, der einem Analysten in einer IDE mit MCP-Unterstützung beim Schreiben eines dbt-Modells hilft, kann nachschlagen, ob eine Spalte existiert, wie sie beschrieben ist und welche nachgelagerten Objekte von ihr abhängen, ohne dass der Analyst den Editor verlassen muss.

Fazit

Der Stack aus dbt und Databricks funktioniert, weil er die Analytics Engineers dort abholt, wo sie ohnehin sind: im SQL. dbt bringt die Praktiken des Software Engineering mit, also Versionskontrolle, Tests, Dokumentation und CI/CD, und Databricks bringt Rechenleistung und Speicher. Das Ergebnis sind Pipelines für Transformationen, die sich schneller bauen und leichter debuggen lassen und sich an neue Teammitglieder übergeben lassen, ohne dass dafür mündlich überliefertes Wissen nötig wäre. Die verbleibende Lücke, die Sicht über Plattformen hinweg, schließt sich, wenn ein Katalog wie Dawiso die auf das Projekt begrenzte Dokumentation von dbt mit der übrigen Datenlandschaft verbindet.

Quellen

• dbt Developer Hub - Materializations
• dbt Developer Hub - Configure incremental models
• dbt Developer Hub - Databricks configurations
• dbt Developer Hub - Add snapshots to your DAG
• dbt Developer Hub - Add data tests to your DAG
• dbt Developer Hub - Supported data platforms
• dbt Labs - Updated names for dbt platform and features
• GitHub - databricks/dbt-databricks
• Fivetran - Fivetran and dbt Labs complete merger
• Databricks - dbt task for jobs
• Microsoft Learn - SQL warehouse types
• Databricks - What is Photon?
• Databricks - Use liquid clustering for tables
• Dawiso Help - dbt connector
• Dawiso Help - Databricks connector
• Dawiso Help - Business glossary
• Dawiso Help - Dawiso Model Context Protocol (MCP)