Wie Sie dbt-ETL-Pipelines auf Databricks umstellen

Immer mehr Teams führen ihre dbt-Transformationen auf dem Databricks Lakehouse aus: einer offenen Plattform ohne Lock-in, mit vereinheitlichten Pipelines, integrierter Unity Catalog-Governance und einem hervorragenden Preis-Leistungs-Verhältnis.

Ihr dbt-Projekt funktioniert: Modelle kompilieren, Tests sind erfolgreich und Ihre Transformationslogik befindet sich in versioniertem SQL und YAML, anstatt fest in einem bestimmten Warehouse verdrahtet zu sein. Das offene Adapter-Framework von dbt ist genau für diese Entkopplung ausgelegt. Der Wechsel von einem Cloud Data Warehouse zu einem anderen ist daher meist nur eine Frage der Anpassung des Adapters und der Verbindungskonfiguration sowie einiger kleinerer Dialektanpassungen – und erfordert kein Umschreiben Ihres DAG oder Ihrer Geschäftslogik.

Databricks ermöglicht dies mit dem gemeinsam entwickelten dbt-databricks-Adapter, offenem Lakehouse-Speicher (Delta Lake und Apache Iceberg™), Unity Catalog und Lakeflow Jobs. Diese bieten Ihnen eine offene, einheitliche Plattform, auf der dbt vom ersten Tag an mit integrierter Governance und einem hervorragenden Preis-Leistungs-Verhältnis läuft – der ideale Ort also, um Ihre dbt-Workloads auszuführen. Aus diesem Grund führen bereits mehr als 3.000 Unternehmen dbt auf Databricks aus.

Wenn Sie einen Wechsel in Erwägung ziehen, gibt es eine gute Nachricht: Sie müssen Ihr Projekt nicht neu aufbauen. Dieser Beitrag zeigt Ihnen Schritt für Schritt, wie Sie ein funktionierendes dbt-Projekt auf Databricks umleiten, indem Sie den Adapter und das Profil austauschen, einige SQL-Unterschiede beheben und Ihre Transformationslogik innerhalb von dbt beibehalten.

Warum die Umleitung von dbt ein hervorragender Ausgangspunkt für die Migration ist

Eine wiederkehrende Herausforderung bei Data-Warehouse-Migrationsprojekten ist der Versuch, alles auf einmal zu verschieben, was zu Verzögerungen und Engpässen führen kann. Ein besserer Ansatz besteht darin, mit der Transformationsschicht zu beginnen. Dies ist ein schneller Weg, um im Zuge einer Migration Kosteneinsparungen zu erzielen.

dbt-Projekte sind bereits modular und testbar. Das macht sie zu idealen Kandidaten für eine schrittweise Migration. Wenn Sie dbt auf Databricks umleiten, profitieren Sie von:

• Sofortige Validierung. Sie können die Ergebnisse zwischen alten und neuen Warehouses Modell für Modell vergleichen
• Geringeres Risiko. Ihre Transformationslogik ändert sich nicht, sodass Sie die Variablen auf Compute und Speicher isolieren
• Ein funktionierender Proof of Concept. Stakeholder können sehen, wie Abfragen auf Databricks ausgeführt werden, noch bevor Sie die Ingestion- oder BI-Schichten migrieren
• Schnellere Wertschöpfung. Anstatt einen gesamten Tech-Stack auf einmal zu migrieren, verschieben Sie zuerst die Transformationsschicht

Voraussetzungen

Umfang: Diese Anleitung beschreibt ausschließlich die Umleitung Ihrer dbt-Transformationsschicht. Es wird vorausgesetzt, dass sich Ihre Quelldaten bereits in Databricks befinden – bereitgestellt als Delta- oder Iceberg-Tabellen und in Unity Catalog registriert – und dass Ihre Kataloge und Schemata existieren. Die Migration der Daten selbst und die Einrichtung von Unity Catalog sind separate Schritte. Weitere Informationen hierzu finden Sie in den Migrationsleitfäden von Databricks und unter Lakebridge.

Stellen Sie vor dem Start sicher, dass Sie über Folgendes verfügen:

• Einen Databricks-Workspace mit einem bereitgestellten SQL-Warehouse
• Eine Unity Catalog-Einrichtung mit dem erstellten Zielkatalog und -schema, wobei Ihre Quelltabellen (Raw/Bronze) bereits als Delta oder Iceberg bereitgestellt und in UC registriert sind
• Ihr bestehendes dbt-Projekt in der Versionskontrolle (dbt Core 1.8+ oder dbt Platform)
• Lokal installiertes Python 3.9+ (für dbt Core-Benutzer)
• Zugangsdaten: ein persönliches Databricks-Zugriffstoken (Personal Access Token) oder eine OAuth-Konfiguration
• Optional kann Lakebridge einen Großteil der SQL-Konvertierung automatisieren. Es scannt Ihr Quell-Warehouse und das SQL in Ihren dbt-Modellen, konvertiert dialektspezifisches SQL in Databricks Lakehouse und gleicht die Ergebnisse mit der Quelle ab. Es leitet das SQL in einem dbt-Projekt um, anstatt dbt selbst zu migrieren, und verschiebt keine Daten, die separate Muster verwenden (Lakehouse Federation + CTAS, COPY INTO oder Auto Loader).

Das Modell, das wir in diesem Beispiel migrieren werden, ist eine Standard-Analyse-Faktentabelle, die auf zwei Quellmodellen aufbaut: orders und order_items. Es aggregiert Daten auf Bestellebene, um den Gesamtumsatz zu berechnen, und erstellt eine Liste der verkauften Produkte für jede einzelne Transaktion aus dem vergangenen Jahr. 

Dieses Modell verwendet mehrere gängige SQL-Dialektmuster wie regexp_substr, div0 und object_construct, die sich zwischen Data Warehouses oft unterscheiden, was es zu einem hervorragenden Beispiel macht. Sobald Sie gelernt haben, wie Sie diese Muster hier handhaben, können Sie denselben Ansatz auf jedes andere Modell in Ihrem Projekt anwenden.

Schritt 1: Installieren des Adapters und Hinzufügen eines Databricks-Ziels

Dieser Teil behandelt die einmalige Migrationsarbeit, die die Installation des Adapters, das Zuordnen von Namespaces und den Umgang mit Dialektunterschieden umfasst.

Installieren des dbt-databricks-Adapters

Der dbt-databricks-Adapter ist das Bindeglied zwischen Ihrem dbt-Projekt und dem Databricks Lakehouse-Warehouse. Er übersetzt das kompilierte SQL von dbt in Databricks-kompatible Abfragen.

(Benutzer von dbt Platform: Wählen Sie „Databricks“ als Verbindungstyp in einer neuen Umgebung aus, wie in der dbt-Dokumentation beschrieben – der Adapter wird automatisch installiert.)

Fügen Sie ein Databricks-Ziel zu `profiles.yml` hinzu. Lassen Sie Ihr bestehendes Ziel unverändert; Sie benötigen es für die Validierung. Fügen Sie daneben ein zweites Ziel hinzu:

Verbindung überprüfen:

Sie sollten Folgendes sehen:  Connection test: [OK connection ok].

Wenn Sie immer noch keine Verbindung herstellen können, befolgen Sie die Schritte zur Fehlerbehebung bei der Verbindung im Integrationsleitfaden für Databricks + dbt und in der dbt Databricks-Profilreferenz.

Profi-Tipp: http_path bestimmt, ob Abfragen auf einem SQL-Warehouse (empfohlen für dbt) oder einem All-Purpose-Cluster ausgeführt werden. SQL-Warehouses bieten ein besseres Preis-Leistungs-Verhältnis für SQL-intensive Workloads.

Schritt 2: Tabellenquellen auf Unity Catalog verweisen und Tests hinzufügen

Databricks verwendet einen dreistufigen Namespace: catalog.schema.table. Aktualisieren Sie die sources.yml-Einträge, aus denen fct_orders liest:

Aktualisieren Sie schema.yml, um Tests einzuschließen

Profi-Tipp: Wenn Sie database: überspringen, landen Abfragen im Standardkatalog des Workspace. Legen Sie ihn explizit fest.

Schritt 3: Erste Kompilierung

Führen Sie nun dbt compile für das Modell aus:

Unser fct_orders-Modell hat 3 Kompilierungsfehler verursacht (wie unten beschrieben), die alle mit dem Dialekt zusammenhängen. Dies ist zu erwarten. Obwohl diese drei typisch für die Dialektprobleme sind, auf die die meisten Projekte stoßen, sind sie nicht die ganze Geschichte: Größere Migrationen stoßen auch auf Strategien für inkrementelle Modelle, Snapshots und semistrukturierte Funktionen ohne direktes Äquivalent. 

Wir verwenden absichtlich ein Beispielmodell, das auf dialektspezifischen Mustern wie REGEXP_SUBSTR mit Positionsparametern, DIV0 für sichere Division und OBJECT_CONSTRUCT für die JSON-Erstellung basiert – also Funktionen, die sich von Warehouse zu Warehouse unterscheiden. Auf diese Weise werden die anfänglichen dbt run-Fehler zu einem Leitfaden für den Konvertierungsprozess. Sie zeigen Ihnen, wie Sie diese in portable Makros und Databricks-freundliches SQL umwandeln, sodass Sie dieselben Korrekturen auf den Rest Ihres Projekts anwenden können. Zur Veranschaulichung führen wir Sie durch jeden Fehler, die Ursache und die Behebung. Bevor wir uns den Fehlern widmen, noch ein Hinweis zur Portabilität: Wenn eine Funktion ein portables Äquivalent hat, können Sie sie mit den datenbankübergreifenden Makros von dbt (dem dbt.*-Namespace) einmal schreiben, sodass sie auf jedem Warehouse kompiliert wird – eine Übernahme im Zuge Ihrer Standardisierung lohnt sich. Wir gehen jeden Fehler und seine Behebung durch und zeigen Ihnen dann, wie Sie die Konvertierung für ein großes Projekt automatisieren können.

Fehler 1: REGEXP_SUBSTR-Dialektinkompatibilität

Databricks folgt dem Apache-SQL-Dialekt und unterstützt nur 2 Parameter für REGEXP_SUBSTR

Behebung: Verwenden Sie die native regexp_extract()-Funktion von Databricks

Sie könnten diese Konvertierung auch von Genie Code durchführen lassen. Das Schließen solcher Dialektlücken ist genau seine Stärke. Wir führen alle drei Schritte manuell durch, damit Sie sehen, was sich ändert.

Fehler 2: DIV0 (sichere Division)

Ursache: Einige Warehouses verwenden DIV0, um 0 zurückzugeben, anstatt bei einer Division durch Null einen Fehler auszugeben.

Behebung: Fügen Sie dbt_utils zu Ihren Paketen hinzu und verwenden Sie die integrierte safe_divide-Funktion

Fehler 3: object_construct (JSON-Builder)

Routine `object_construct` kann nicht aufgelöst werden

Behebung: Verwenden Sie die Databricks-Funktion named_struct

Kompilierung erneut ausführen:

Erfolgreich kompiliert. Gesamte Dialektänderungen für dieses Modell: dbt_utils package installed (für sichere Division), regexp_substr call converted to regexp_extract, div0-Aufruf ersetzt durch dbt_utils.safe_divide(), object_construct call converted durch named_struct.

Drei Funktionen manuell zu korrigieren, ist einfach. Ein echtes dbt-Projekt hat Hunderte oder Tausende von Modellen, und genau diese Dialektlücken schließen KI-Tools automatisch. Genie Code konvertiert dialektspezifisches SQL und führt diese Korrekturen direkt im Editor durch, sodass Sie Ihre Zeit mit der Überprüfung der Konvertierungen verbringen können, anstatt jede einzelne selbst zu schreiben.

Schritt 4: Erster Durchlauf

Sobald die Kompilierung erfolgreich ist, führen Sie das Modell und alle vorhandenen Tests aus:

Sowohl die Modellerstellung als auch die Tests sind erfolgreich. Profi-Tipp:

• Laufzeit. Notieren Sie sie sich – Sie werden sie im nächsten Schritt mit dem alten Warehouse vergleichen.
• Testfehler bei numerischen Spalten. Wenn equality- oder accepted_values-Tests fehlschlagen, liegt das fast immer an der Gleitkommapräzision und nicht an einem Logikfehler.

Schritt 5: Zeilenweiser Abgleich mit dem Legacy-Warehouse

Ein grünes dbt run beweist, dass SQL ausgeführt wird. Jetzt müssen wir die Ergebnisse des Legacy-Warehouses und von Databricks miteinander abgleichen. Verwenden Sie dbt-audit-helper, um einen zeilenweisen Vergleich durchzuführen.

Installation:

Vergleichen Sie fct_orders über beide Warehouses hinweg. In analyses/compare_fct_orders.sql:

Führen Sie es in Databricks aus (vorausgesetzt, Sie haben die Legacy-Ausgabe für den Vergleich in Databricks repliziert oder führen einen Warehouse-übergreifenden Vergleich durch):

Erwartetes Ergebnis:

Hinweis: Diese Beispiele decken die gängigsten Muster ab, sind aber nicht vollständig. Bei weiteren Abweichungen (z. B. String-Trimming, Sortierung oder benutzerdefiniertes UDF-Verhalten) legen Sie summarize=false fest, um Beispielzeilen zu materialisieren, überprüfen Sie einige Primärschlüssel, bei denen sich in_a und in_b unterscheiden, beheben Sie den Fehler im Modell oder Makro und führen Sie den Vorgang erneut aus, bis Sie eine 100-prozentige Übereinstimmung erhalten.

In unserem Durchlauf: fct_orders stimmte genau überein.

Schritt 6: Bereitstellung in Databricks

Anstatt eine separate Orchestrierungsebene für dbt zu verwalten, können Sie dbt zusammen mit Upstream-Ingestion und Downstream-Aktionen in einer einzigen Pipeline mit Lakeflow Jobs ausführen. dbt ist ein erstklassiger Task-Typ innerhalb von Jobs, und Sie benötigen weder einen externen Orchestrator noch ein benutzerdefiniertes Docker-Image.

Erstellen Sie den Job:

1. Workspace → Jobs & Pipelines → Job erstellen
2. Task-Typ: dbt
3. Git-Quelle: Ihr dbt-Repository
4. Befehle:

5. SQL-Warehouse: Ihr Prod-Warehouse
6. Warehouse-Katalog: Der Katalog, in den die Tabelle geschrieben wird: dev
7. Warehouse-Schema: Das Schema, in das die Tabelle geschrieben wird: analytics
8. Zeitplan: Ihr bevorzugter Rhythmus

Was Jobs Ihnen standardmäßig bietet:

• Vollständig verwaltet – keine zusätzliche Infrastruktur, die gekauft, gesichert oder gewartet werden muss
• Möglichkeit, eine einzige Pipeline zu erstellen, um dbt-Tasks zusammen mit Upstream-Ingestion-Pipelines sowie Downstream-Tasks wie Power BI-Aktualisierungen auszuführen

Schritt 7: Umstellung und Stilllegung

Sobald Sie Ihr dbt-Projekt validiert und auf Databricks bereitgestellt haben, besteht der nächste Schritt darin, den Produktions-Traffic kontrolliert auf Databricks zu verlagern, einen kurzen Rollback-Pfad beizubehalten und zu vermeiden, länger als nötig für zwei Warehouses zu bezahlen.

Nutzen Sie diese Checkliste:

1. Stellen Sie das Produktionsziel in profiles.yml so um, dass prod auf Databricks verweist – alle neuen Produktionsläufe schreiben nun in Databricks.
2. Aktualisieren Sie die CI/CD-Anmeldedaten, sodass PR-Prüfungen für einen Databricks-Staging-Katalog und nicht für das Legacy-Warehouse ausgeführt werden.
3. Überwachen Sie die Kosten über system.billing.usage, um das Ausgabenprofil von Databricks zu bestätigen.
4. Stellen Sie das Legacy-Ziel ein, sobald das Rollback-Fenster geschlossen ist und Sie sicher sind, dass Databricks in der Produktion stabil läuft.

Skalierung auf den Rest Ihres Projekts

Der Großteil der Arbeit, die Sie gerade erledigt haben, ist einmalig: die Adapterinstallation, das profiles.yml-Ziel und die Änderung des Quell-Namespace. Sobald diese eingerichtet sind, erfordert das Neuausrichten des nächsten Modells nur noch die inkrementellen Dialektkorrekturen.

Einige Muster erfordern mehr als nur einen Dialektwechsel, und Sie werden bei der Skalierung darauf stoßen:

• Inkrementelle Modelle – inkrementelle Strategien unterscheiden sich je nach Plattform. Die von Ihrer Quelle verwendete Strategie lässt sich möglicherweise nicht 1:1 auf eine inkrementelle Databricks-Strategie übertragen. Daher müssen Sie die Strategie neu auswählen und die inkrementelle Logik neu validieren.
• Snapshots – Sie richten die Snapshot-Logik neu aus und übertragen separat die vorhandenen historischen Snapshot-Daten, damit keine Historie verloren geht.
• Teilstrukturierte und Nischenfunktionen – einige Quellfunktionen haben keine direkte Entsprechung in Databricks und erfordern eine Neuschreibung oder ein Makro, keinen Einzeiler.

Nutzen Sie für die komplexeren Aufgaben die vollständigen Migrationsleitfäden.

Migrieren Sie von dort aus in kleinen Schritten und arbeiten Sie in der DAG-Reihenfolge – zuerst Quellen, dann Staging, Intermediate und Marts, damit jede Charge sauber mit den bereits verschobenen Modellen validiert werden kann. Führen Sie beide Ziele parallel aus und nutzen Sie audit-helper, um jedes Modell zu vergleichen, bis alle übereinstimmen. Wenn das letzte Modell grün ist, stellen Sie das gesamte Projekt um. Dieser Leitfaden ist eine vereinfachte Anleitung zur Neuausrichtung. Der vollständige Umfang einer Migration wird in unseren öffentlichen Migrationsleitfäden behandelt. 

Fazit

Die Neuausrichtung von dbt auf Databricks ist eine praktische und risikoarme Möglichkeit, eine Warehouse-Migration zu starten. Ihre Modelle und Tests bleiben unverändert – Sie ändern lediglich den Ort, an dem sie ausgeführt werden. Zudem profitieren Sie von Open-Source-Formaten und -Standards wie Delta Lake und Apache Iceberg™, während Unity Catalog Governance und Lineage auf einer Plattform bietet, die auch für Ihre Downstream-KI-Arbeit genutzt werden kann. Beginnen Sie mit einem Modell, vergleichen Sie die Ergebnisse und erweitern Sie den Umfang, bis Sie sich bereit fühlen, Databricks als primäre Plattform für Ihr dbt-Projekt zu nutzen.

Bereit, es auszuprobieren? 

1. Richten Sie eine kostenlose Databricks-Testversion ein
2. Installieren Sie den dbt-databricks-Adapter
3. Führen Sie Ihr erstes dbt compile für ein Databricks Lakehouse-Warehouse aus. Stellen Sie anschließend einen Databricks-Job bereit, um ein dbt-Modell in der Produktion auszuführen, indem Sie der Databricks- Dokumentation folgen.

Weitere Informationen zu dbt mit Databricks finden Sie im dbt-databricks-Adapter auf GitHub.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag