Azure Data Factory (ADF) ist ein starkes Werkzeug für die Datenanbindung. Es kann darüber hinaus auch Transformationen ausführen, etwa über Mapping Data Flows, und wird in manchen Projekten genau dafür eingesetzt. Aus unserer Erfahrung lohnt sich jedoch ein genauer Blick darauf, wofür ADF wirklich gedacht ist. Sobald ein erheblicher Teil der fachlichen Logik in ADF wandert, wird aus einer pragmatischen Abkürzung mit wachsender Plattform schnell eine Belastung für Wartbarkeit, Testbarkeit und Nachvollziehbarkeit.
Wofür ADF wirklich stark ist
Die Stärke von ADF liegt eindeutig in der Anbindung. Es bringt von Haus aus Konnektoren für eine Vielzahl von Quellsystemen mit, von Datenbanken über SaaS-Anwendungen bis zu Dateiablagen. Über die Self-hosted Integration Runtime erreichen Sie zudem zuverlässig On-Prem-Quellen hinter der Firewall, etwa SAP-Systeme oder lokale SQL-Server, die sonst nur schwer zugänglich sind. Hinzu kommen Scheduling, Trigger und Monitoring für den reinen Datentransport. Für Extraktion und Transport ist ADF damit ein verlässliches Rückgrat.
Warum Transformation nicht in ADF gehört
Bei der Transformation zeigt ADF dagegen klare Schwächen. Mapping Data Flows werden als JSON gespeichert und sind dadurch schwer zu versionieren und kaum sinnvoll zu testen. Im Pull Request sehen Sie keine lesbaren fachlichen Änderungen, sondern unübersichtliche Diffs auf JSON-Ebene. Echte Unit-Tests für einzelne Transformationsschritte fehlen, und das Debugging ist umständlich.
Hinzu kommt ein architektonischer Punkt: Sobald ein Teil der Logik in ADF und ein anderer in Databricks liegt, verteilt sich die Transformation auf zwei Werkzeuge mit unterschiedlichen Paradigmen. Die durchgängige Lineage reißt genau an dieser Grenze, das Wissen über die Plattform fragmentiert sich über zwei Skill-Welten, und Mapping Data Flows verursachen zudem auf eigenen Spark-Clustern Kosten, die unabhängig von Ihrer Databricks-Umgebung anfallen.
Der Ansatz: Extract & Load in ADF, Transformation in dbt
Unser bewährter Ansatz trennt beides sauber. ADF übernimmt ausschließlich Extract & Load: Es zieht die Daten aus den Quellsystemen und legt sie unverändert als Dateien, typischerweise als Parquet, im Landing-Bereich von ADLS ab. Anschließend stößt ADF den Databricks-Job an, und ab dort übernimmt dbt die Verarbeitung.
Cleaning, Modellierung, Historisierung und Business-Logik laufen dann vollständig in Azure Databricks mit dbt, in einem einzigen Werkzeug mit Dependency Management, automatisierten Tests, durchgängiger Lineage und sauberer Versionierung in Git. Die gesamte Transformation bleibt damit an einem Ort, statt über ADF und Databricks verteilt zu sein.
Was diese Trennung konkret bringt
- Durchgängige Lineage von der Rohschicht bis zu den Marts, ohne Bruch an der Werkzeuggrenze.
- Nachvollziehbare Änderungen: Jede Anpassung der Logik ist als lesbarer SQL-Diff im Pull Request sichtbar und prüfbar.
- Testbarkeit: Datenqualität und Geschäftsregeln werden automatisiert geprüft statt manuell.
- Klare Verantwortlichkeiten: ADF kümmert sich um Anbindung und Orchestrierung, dbt um die fachliche Transformation.
Pragmatismus mit klarer Grenze
Für eine triviale Formatkonvertierung kann ein kleiner Schritt in ADF vertretbar sein. Fachliche Business-Logik gehört aus unserer Sicht jedoch nicht dorthin, weil sie dort schwer test- und wartbar bleibt. Die Faustregel ist einfach: Jedes Werkzeug übernimmt das, was es am besten kann. ADF die Anbindung, Azure Databricks und dbt die Transformation.
Steckt bei Ihnen fachliche Logik in ADF, die eigentlich nach Databricks gehört? Wir unterstützen Sie dabei, Ingestion und Transformation sauber zu trennen und Ihre Plattform auf Azure Databricks mit dbt wartbar aufzustellen.
Erstgespräch vereinbaren