Azure Databricks mit dbt: kein separates ETL-Tool für Orchestrierung, Tests und Abhängigkeiten nötig

Viele Teams führen gerade Azure Databricks ein und stehen dann vor derselben Frage: Welches ETL-Tool setzt man für Orchestrierung, Tests und Abhängigkeiten obendrauf? Die Antwort fällt oft reflexartig zugunsten eines zusätzlichen Werkzeugs aus. In vielen Fällen ist das gar nicht nötig.

Diese Entscheidung gab es schon lange vor Databricks, nur mit anderen Tools. Und sie endet häufig gleich. Irgendwann weiß niemand mehr genau, in welcher Reihenfolge die 1.000 Jobs eigentlich laufen müssen. Außer der einen Person, die gerade gekündigt hat.

Was ein Orchestrierungs-Tool leisten soll

Ein Orchestrierungs-Tool soll genau dieses Risiko auflösen: Dependency Management, Scheduling, Tests und Fehlerbehandlung an einer zentralen Stelle, nachvollziehbar und wiederholbar. Der klassische Reflex ist deshalb, ein separates Tool dazuzunehmen oder sich ein metadata-driven Framework mit Control Tables selbst zu bauen.

Beides ist besser als alles von Hand zu steuern. Aber jeder, der ein solches Framework selbst gebaut hat, kennt die Kehrseite. Es wächst mit jeder Anforderung. Irgendwann steckt mehr Aufwand in der Pflege des Frameworks als in der eigentlichen Datenarbeit, und das Wissen darüber konzentriert sich auf wenige Köpfe.

Warum dbt auf Azure Databricks oft kein separates Tool braucht

dbt läuft nativ in Azure Databricks. Es gibt keine separate Engine und keine eigene Runtime. dbt kompiliert die Modelle zu reinem SQL und schickt dieses ans Databricks SQL Warehouse zur Ausführung. Compute, Storage und Execution bleiben vollständig in Databricks. Nichts verlässt die Plattform, was Governance, Sicherheit und Kostenkontrolle vereinfacht.

Der DAG baut sich selbst

Statt Ausführungsreihenfolgen von Hand zu verdrahten, entsteht der Abhängigkeitsgraph automatisch. Über ref() und source() erkennt dbt, welches Modell auf welchem aufbaut, und leitet daraus die korrekte Reihenfolge ab. Kommt eine neue Tabelle hinzu, genügt ein ref() an der richtigen Stelle. Der Orchestrierungs-Overhead, der vorher Tage gekostet hat, fällt damit weitgehend weg. Lineage und Dokumentation entstehen als Nebenprodukt und lassen sich als durchsuchbare Doku-Seite generieren.

Das Ökosystem macht den Unterschied

Der eigentliche Hebel liegt im dbt-Ökosystem. Rund um den Core gibt es eine Reihe etablierter Pakete, die Qualität und Effizienz spürbar erhöhen:

• sqlfluff: Linter und Formatter für SQL mit dbt-Templater. Sorgt für einheitlichen, lesbaren Code im gesamten Team und lässt sich direkt in CI integrieren.

• dbt-utils: Sammlung bewährter Makros und Tests, die wiederkehrende Aufgaben vereinfachen und Boilerplate vermeiden.

• dbt_expectations: umfangreiche Datenqualitäts-Tests nach dem Vorbild von Great Expectations, weit über die Standard-Tests hinaus.

• elementary: Data Observability direkt aus dbt heraus, inklusive Anomalie-Erkennung, Monitoring und Reports.

• datavault4dbt: generiert Hubs, Links und Satellites für eine Modellierung nach Data Vault 2.0.

• Tests, Lineage und Dokumentation kommen out of the box mit, der Rest wird über Pakete ergänzt, statt ihn selbst zu bauen und zu warten.

dbt Core reicht oft schon

Vieles davon funktioniert bereits mit dbt Core, der Open-Source-Variante. dbt Cloud bringt zusätzliche Extras wie einen gehosteten Scheduler, eine Web-IDE, einen Semantic Layer und CI-Funktionen. Die eigentliche Kern-Power steckt aber im Core, und für den Einstieg auf Azure Databricks ist das in vielen Fällen ausreichend.

Und Lakeflow Spark Declarative Pipelines?

Eine weitere Option direkt auf der Plattform sind Lakeflow Spark Declarative Pipelines (SDP), die Weiterentwicklung von Delta Live Tables. Auch hier werden Abhängigkeiten und Ausführung deklarativ beschrieben, statt sie manuell zu verdrahten. Ihre Stärke liegt klar im Streaming, dort funktioniert SDP sehr gut. Im Bereich der klassischen Transformationen sind Ökosystem, Community und Reifegrad aber noch nicht auf dem Niveau von dbt.

Da die meisten Datenplattformen überwiegend im Batch oder über CDC arbeiten und das für die meisten Fälle ausreicht, ist dbt für reine Transformationsworkloads in der Regel die ausgereiftere und besser unterstützte Alternative. Für stark streaming-lastige Szenarien kann SDP dagegen die passendere Wahl sein.

Wann ein separater Orchestrator trotzdem sinnvoll ist

dbt ist stark in der Transformation, deckt aber nicht jeden Schritt ab. Sobald Ingestion, Schritte, die sich nicht in SQL abbilden lassen (etwa Python- oder Spark-Jobs), Machine-Learning-Pipelines oder die Koordination mehrerer Systeme ins Spiel kommen, kann ein übergeordneter Orchestrator wie Lakeflow Jobs (früher Databricks Workflows), Azure Data Factory oder Airflow weiterhin sinnvoll sein. Der entscheidende Unterschied: dbt übernimmt die Logik innerhalb der Transformationsschicht, der Orchestrator kümmert sich nur noch um das Zusammenspiel der Bausteine. Damit bleibt die Komplexität dort, wo sie hingehört.

Fazit

Auf Azure Databricks lohnt es sich, die Frage nach dem separaten ETL-Tool bewusst zu stellen, bevor man reflexartig eines hinzufügt. In vielen Fällen deckt dbt zusammen mit seinem Ökosystem genau das ab, wofür sonst ein zusätzliches Werkzeug gedacht war, und das ohne die Plattform zu verlassen.

Falls Sie gerade vor genau so einer Implementierung stehen, kommen Sie gerne auf uns zu. Wir unterstützen Sie beim Aufbau moderner Data- und AI-Plattformen auf Azure Databricks.