Data Engineering auf Databricks: vom ETL-Wildwuchs zur einheitlichen Plattform
Die Kernaussagen auf einen Blick.
- Data Engineering auf Databricks deckt vier Bereiche ab: Daten laden (Ingestion), aufbereiten (Transformation), steuern (Orchestrierung) und verlässlich in Produktion bringen (Deployment).
- Teuer wird gewachsenes ETL meist nicht durch Lizenzen, sondern durch viele Codebasen, Betriebsmodelle und Deployment-Wege nebeneinander.
- Drei Entscheidungen prägen die Plattform: Welche Pipelines werden deklarativ gebaut? Was wird auf Databricks konsolidiert? Und wie kommen Jobs und Pipelines versioniert in Produktion?
- Declarative Pipelines und Asset Bundles senken den Aufwand deutlich, aber nur, wenn sie zum verbindlichen Standard werden und nicht bloß neben den alten Werkzeugen laufen.
Inhaltsverzeichnis
Fünf ETL-Tools sind noch keine Plattform
In vielen Unternehmen sind ETL-Landschaften über Jahre hinweg gewachsen. Unterschiedliche Fachbereiche und Data-Teams haben jeweils die Werkzeuge eingesetzt, die zu ihrem damaligen Anwendungsfall gepasst haben.
Das Konzernreporting läuft beispielsweise über Airflow und selbst entwickelte SAP-Extraktoren. Produktionsdaten werden mit Azure Data Factory in einen Data Lake geschrieben. Der Vertrieb lädt Salesforce-Daten über eine eigene Python-Strecke in ein separates Warehouse.
Jede dieser Lösungen kann für sich genommen funktionieren. Das Problem zeigt sich im Gesamtbetrieb:
- mehrere Codebasen,
- unterschiedliche Deployment-Prozesse,
- getrennte Monitoring- und Logging-Systeme,
- verschiedene Bereitschaftsmodelle,
- unklare Verantwortlichkeiten an den Übergängen.
Spätestens bei einem Incident oder einer Audit-Anfrage wird diese Trennung teuer. Wenn die Herkunft einer Kennzahl nicht vollständig nachvollziehbar ist, beginnt die Suche über mehrere Teams und Systeme hinweg. Häufig kennt jedes Team nur seinen eigenen Teil der Datenstrecke.
Eine Lakehouse-zentrierte Data-Engineering-Architektur soll nicht einfach alle vorhandenen Werkzeuge ersetzen. Sie soll zunächst klare Antworten auf vier Fragen geben:
Ingestion
Wie gelangen Daten zuverlässig ins Lakehouse?
Transformation
Wie werden sie von Bronze über Silver bis Gold verarbeitet?
Orchestrierung
Wie werden Abhängigkeiten, Wiederholungen und Fehler behandelt?
Deployment
Wie gelangen Änderungen reproduzierbar von der Entwicklung in die Produktion?
In Plattformprojekten kommt eine strategische Ebene dazu: Welche bestehenden ETL-Strecken kosten viel Betrieb ohne entsprechenden Nutzen, welche Drittwerkzeuge tragen weiterhin, und für welche neuen Strecken soll Databricks der Standard werden?
Die technischen Einzelkomponenten sind dabei selten das Hauptproblem. Schwieriger ist die Entscheidung, nach welchem gemeinsamen Entwicklungs-, Betriebs- und Deployment-Modell die Plattform arbeiten soll.
Dieser Artikel betrachtet Data Engineering auf Databricks deshalb entlang von vier Bereichen: Ingestion, Transformation, Orchestrierung und Deployment.
Was ist Data Engineering auf Databricks?
Data Engineering auf Databricks umfasst den gesamten Weg von der Quelle bis zu einer verlässlich nutzbaren Tabelle.
Dazu gehören:
Daten übernehmen
Daten aus Anwendungen, Datenbanken, Dateien und Eventströmen werden übernommen.
Rohdaten speichern
Rohdaten werden nachvollziehbar gespeichert.
Daten modellieren
Daten werden bereinigt und fachlich modelliert.
Pipelines betreiben
Pipelines werden geplant, überwacht und bei Fehlern erneut ausgeführt.
Änderungen ausrollen
Änderungen werden versioniert getestet und in Produktion gebracht.
In klassischen ETL-Landschaften übernimmt häufig ein separates Werkzeug jeden dieser Schritte. Ein Ingestion-Tool extrahiert die Daten, ein Scheduler steuert die Abläufe, ein weiteres System verarbeitet die Transformationen und ein Warehouse stellt die Ergebnisse bereit.
Auf dem Lakehouse liegen diese Aufgaben näher beieinander. Daten werden auf derselben Plattform aufgenommen, verarbeitet und für BI- oder AI-Anwendungen bereitgestellt. Berechtigungen, Lineage und Audit-Informationen können dabei über den Überblick zu Unity Catalog durchgängig verwaltet werden.
Drei Veränderungen sind besonders relevant.
Pipelines beschreiben stärker das gewünschte Ergebnis
Bei einer klassischen imperativen Pipeline wird Schritt für Schritt programmiert, was ausgeführt werden soll.
Eine deklarative Pipeline beschreibt dagegen, welche Tabellen entstehen sollen, welche Abhängigkeiten bestehen und welche Qualitätsregeln gelten. Die Plattform leitet daraus den Ausführungsgraphen ab und übernimmt Teile der inkrementellen Verarbeitung und Wiederanlaufsteuerung.
Orchestrierung verbindet unterschiedliche Workloads
Moderne Datenstrecken bestehen nicht nur aus Notebooks, sondern aus Ingestion-Pipelines, SQL-Transformationen, Data-Quality-Prüfungen, Machine-Learning-Jobs, API-Aufrufen und Exporten. Die Orchestrierung verbindet diese Schritte und macht Abhängigkeiten, Wiederholungen und Zuständigkeiten sichtbar.
Deployment umfasst mehr als Code
Eine produktive Pipeline besteht nicht nur aus Python- oder SQL-Code. Auch Job-Konfigurationen, Pipeline-Ressourcen, Parameter, Berechtigungen und umgebungsspezifische Einstellungen müssen versioniert werden.
Databricks Asset Bundles stellen diese Bestandteile in einem gemeinsamen Deployment-Artefakt zusammen.
Der Vorteil einer Lakehouse-zentrierten Architektur liegt deshalb weniger in einem einzelnen Feature. Entscheidend ist, dass Entwicklung, Deployment, Betrieb, Berechtigungen und Lineage nach einem gemeinsamen Modell funktionieren.
Eine gute technische Plattform ersetzt allerdings keine gute Datenmodellierung. Schlecht definierte Tabellen und unklare Geschäftslogik werden auch durch deklarative Pipelines nicht automatisch besser.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Ingestion, Transformation, Orchestrierung und Deployment
Eine Data-Engineering-Plattform auf Databricks lässt sich in vier Bereiche unterteilen.
In einem Workspace sichtbar: Ingestion über „Add data", die Transformation als Bronze-Silver-Gold-Graph und das Monitoring der Pipeline-Läufe. Die folgende Tabelle ordnet diese Bereiche.
| Bereich | Zentrale Frage | Typische Komponenten | Ziel |
|---|---|---|---|
| Ingestion | Wie gelangen Daten zuverlässig ins Lakehouse? | Auto Loader, Lakeflow Connect, Streaming- und Batch-Verfahren | Nachvollziehbare Rohdaten mit kontrollierter Schemaentwicklung |
| Transformation | Wie werden aus Rohdaten nutzbare Datenprodukte? | Lakeflow Declarative Pipelines, Spark, SQL, dbt | Versionierte Bronze-, Silver- und Gold-Tabellen |
| Orchestrierung | Wie werden Aufgaben geplant und miteinander verbunden? | Lakeflow Jobs, Airflow, Dagster, Prefect | Wiederholbare Abläufe mit Monitoring und klaren Zuständigkeiten |
| Deployment | Wie gelangen Änderungen kontrolliert in Produktion? | Databricks Asset Bundles, Terraform, CI/CD | Reproduzierbare und überprüfbare Deployments |
Diese Bereiche überschneiden sich teilweise.
Declarative Pipelines übernehmen beispielsweise nicht nur Transformationen, sondern verwalten auch Abhängigkeiten und Verarbeitungszustände innerhalb einer Pipeline. Asset Bundles bündeln wiederum Code, Pipeline-Definitionen und Job-Konfigurationen zu einem deploybaren Artefakt.
Unterhalb dieser Bereiche liegt Unity Catalog als gemeinsame Grundlage für Berechtigungen, Ownership, Lineage und Discovery. Wir vertiefen das weiter unten im eigenen Governance-Abschnitt.
Auto Loader, Lakeflow Connect und Zerobus richtig einordnen
In der Ingestion zeigt sich die Vielfalt einer Datenlandschaft besonders deutlich. Dateien, relationale Datenbanken, SaaS-Anwendungen und Eventströme benötigen unterschiedliche technische Ansätze.
Eine durchgehende Daten-Ingestion-Strategie sollte diese Wege deshalb nicht nach persönlichen Werkzeugpräferenzen ordnen, sondern nach klaren Kriterien:
- Art der Quelle,
- benötigte Aktualität,
- Datenmenge,
- Änderungsrate,
- Verfügbarkeitsanforderungen,
- Verantwortung im Betrieb.
Auto Loader für Dateien im Cloud-Speicher
Auto Loader eignet sich für Dateien, die fortlaufend in Azure Data Lake Storage, Amazon S3 oder Google Cloud Storage abgelegt werden.
Neue Dateien werden inkrementell erkannt. Checkpoints halten fest, welche Daten bereits verarbeitet wurden. Auch Schemaänderungen können kontrolliert behandelt werden.
Dadurch entfallen viele selbst entwickelte Lösungen für:
- Verzeichnis-Scanning,
- Dateideduplizierung,
- Fortschrittsverwaltung,
- Wiederanlauf nach Fehlern.
Auto Loader eignet sich besonders als Einstiegspunkt für Bronze-Tabellen, wenn Quellsysteme Daten als JSON, CSV, Avro, Parquet oder in vergleichbaren Dateiformaten bereitstellen.
Lakeflow Connect für verwaltete Quellkonnektoren
Lakeflow Connect bietet verwaltete Konnektoren für ausgewählte SaaS-Anwendungen und Datenbanken.
Der Vorteil liegt in der direkten Integration mit Databricks und Unity Catalog. Ingestion, Zieltabellen, Berechtigungen und Lineage befinden sich dadurch näher an der eigentlichen Datenplattform.
Lakeflow Connect wählen, wenn
- die benötigte Quelle unterstützt wird
- Databricks die zentrale Zielplattform ist
- zusätzliche Ingestion-Infrastruktur vermieden werden soll
- ein einheitliches Betriebsmodell wichtiger ist als ein maximal großer Connector-Katalog
Fivetran oder Airbyte wählen, wenn
- die Quelle von Lakeflow Connect nicht oder nur eingeschränkt unterstützt wird
- Nischenanwendungen oder weniger verbreitete Datenbanken angebunden werden müssen
Direkte Ingestion für hochfrequente Events
Zerobus Ingest richtet sich an Anwendungsfälle, in denen Events mit geringer Latenz direkt in Databricks aufgenommen werden sollen.
Das kann sinnvoll sein, wenn noch keine bestehende Kafka- oder Confluent-Infrastruktur vorhanden ist und ein zusätzlicher Streaming-Backbone nur für diesen Zweck unverhältnismäßig wäre.
Es ist jedoch kein automatischer Ersatz für Kafka, Confluent oder Pulsar. Bestehende Event-Plattformen erfüllen häufig zusätzliche Aufgaben:
- Entkopplung von Produzenten und Konsumenten,
- Aufbewahrung und Wiederholung von Events,
- Verteilung an mehrere Zielsysteme,
- Schema Governance,
- systemübergreifende Event-Architekturen.
Die Entscheidung hängt deshalb nicht nur von der Databricks-Ingestion ab, sondern von der Rolle des Streaming-Systems in der Gesamtarchitektur.
Klassische Batch-Verfahren bleiben relevant
JDBC-Loads, API-Extraktionen und dateibasierte Batch-Prozesse bleiben sinnvoll für:
- einmalige Migrationen,
- Backfills,
- kleine und selten aktualisierte Quellen,
- Systeme ohne CDC-Schnittstelle,
- spezielle Quellformate.
Nicht jede Quelle benötigt eine komplexe Streaming- oder CDC-Architektur.
Als grobe Orientierung gilt:
Dateien im Object Storage
Auto Loader prüfen.
Unterstützte SaaS- oder Datenbankquelle
Lakeflow Connect prüfen.
Direkte hochfrequente Events
Zerobus oder bestehende Streaming-Plattform bewerten.
Nicht unterstützte Spezialquelle
Drittanbieter oder eigene Extraktion gezielt einsetzen.
Declarative Pipelines, Spark, SQL und dbt
In der Transformationsschicht werden Rohdaten bereinigt, vereinheitlicht und für konkrete Anwendungsfälle aufbereitet.
Databricks bietet dafür mehrere Möglichkeiten:
SQL & PySpark
In Notebooks oder Python-Modulen für individuelle Transformationslogik.
Declarative Pipelines
Deklarative Tabellen- und Abhängigkeitsdefinition mit automatischer Ausführung.
Visuelle Modellierung
Standardstrecken über den Lakeflow Designer ohne Code.
dbt
SQL-zentrierte Transformationen mit Tests, Doku und Abhängigkeitsgraphen.
Lakeflow Declarative Pipelines
Lakeflow Declarative Pipelines beschreiben, welche Tabellen oder Views entstehen sollen und wie sie voneinander abhängen.
Die Pipeline-Engine kann daraus den Ausführungsgraphen ableiten und übernimmt unter anderem Teile von:
- Abhängigkeitssteuerung,
- inkrementeller Verarbeitung,
- Zustandsverwaltung,
- Monitoring,
- Lineage-Erfassung,
- Datenqualitätsprüfungen über Expectations.
Der deklarative Ansatz eignet sich besonders für:
- Bronze-Silver-Gold-Pipelines,
- kontinuierliche Dateiverarbeitung,
- CDC-Verarbeitung,
- standardisierte Transformationen,
- Materialized Views und Streaming Tables,
- Pipelines mit klaren Tabellenabhängigkeiten.
Er setzt jedoch voraus, dass Datenprodukte und Abhängigkeiten sauber modelliert sind. Eine unübersichtliche Pipeline wird nicht allein dadurch wartbar, dass sie deklarativ geschrieben wurde.
Spark Declarative Pipelines sind die offene Variante desselben Ansatzes, unmittelbar auf Spark aufgesetzt. Sie kommen vor allem dort in Frage, wo eine engere Bindung an Spark-Funktionalität oder eine Übertragbarkeit jenseits der verwalteten Plattform politisch wichtig ist.
Visuelle Modellierung
Der Lakeflow Designer richtet sich an Teams, die Standardstrecken visuell modellieren möchten.
Das kann für einfachere Integrations- und Transformationsabläufe sinnvoll sein, insbesondere wenn nicht alle Beteiligten täglich mit Python, SQL oder Notebooks arbeiten.
Wichtig ist, dass visuell erstellte Pipelines nicht zu einer getrennten Entwicklungswelt werden. Code, Konfiguration und Deployment sollten weiterhin nach denselben Standards versioniert und betrieben werden wie programmatisch entwickelte Pipelines.
Die Rolle von dbt
dbt bleibt für viele Analytics-Engineering-Teams die bevorzugte Lösung für SQL-basierte Transformationen. Der State of Analytics Engineering von dbt Labs dokumentiert die Verbreitung jährlich.
Besonders etabliert sind dort:
- modulare SQL-Modelle,
- Tests,
- Dokumentation,
- Abhängigkeitsgraphen,
- Wiederverwendung über Macros,
- Zusammenarbeit zwischen Analytics Engineers.
dbt und Lakeflow Declarative Pipelines müssen sich nicht gegenseitig ausschließen.
Eine mögliche Aufteilung ist:
Lakeflow
Für Ingestion, CDC und kontinuierliche Bronze- beziehungsweise Silver-Verarbeitung.
dbt
Für SQL-zentrierte fachliche Modelle in Silver und Gold.
Lakeflow Jobs
Für die gemeinsame Orchestrierung.
Die Entscheidung sollte pro Datenprodukt und Team getroffen werden. Ein Unternehmen mit einer etablierten dbt-Plattform muss diese nicht ablösen, nur um Databricks stärker zu standardisieren.
ETL und ELT bleiben Architekturentscheidungen
Auch auf einem Lakehouse ist nicht jede Verarbeitung automatisch ELT.
Manche Daten sollten bereits vor oder während der Ingestion reduziert, gefiltert oder technisch normalisiert werden. In anderen Fällen ist es sinnvoller, Rohdaten zunächst unverändert zu speichern und erst anschließend zu transformieren.
Im Vergleich ETL oder ELT auf dem Lakehouse sollten daher nicht nur die technische Machbarkeit betrachtet werden, sondern auch:
- Auditierbarkeit,
- Datenschutz,
- Datenvolumen,
- Wiederholbarkeit,
- Kosten,
- Fehlerbehandlung.
Orchestrierung mit Lakeflow Jobs und externen Orchestratoren
Orchestrierung verbindet einzelne Aufgaben zu einem verlässlichen End-to-End-Prozess: Pipeline-Ausführungen, SQL-, Notebook- und Python-Tasks, ML-Trainings, Qualitätsprüfungen, API-Aufrufe, Benachrichtigungen und Exporte. Sie muss Abhängigkeiten, Wiederholungen, Fehlerbehandlung, Zeitpläne und Monitoring abbilden.
Lakeflow Jobs für Databricks-interne Abläufe
Lakeflow Jobs eignet sich vor allem für Prozesse, deren wesentliche Komponenten in Databricks liegen.
Dazu zählen beispielsweise:
- Declarative Pipelines,
- Notebook- und Python-Tasks,
- SQL-Abfragen,
- dbt-Tasks,
- Modelltraining,
- Databricks-interne Qualitätsprüfungen.
Der Vorteil liegt in der gemeinsamen Plattform. Job-Konfiguration, Compute, Berechtigungen, Ausführungsinformationen und Workload-Monitoring können an einer Stelle verwaltet werden.
Airflow, Dagster und Prefect für plattformübergreifende Prozesse
Airflow ist in vielen größeren Unternehmen bereits als übergeordneter Workflow-Orchestrator etabliert. Der Airflow Survey 2024 der Apache Airflow Community zeigt eine breite Adoption in Enterprise-Umgebungen.
Das ist besonders sinnvoll, wenn ein Prozess mehrere Plattformen verbindet, beispielsweise:
- SAP-Extraktion,
- Databricks-Verarbeitung,
- Übergabe an ein ERP-System,
- Freigabeprozess,
- Versand einer Benachrichtigung,
- Ausführung eines nachgelagerten Services.
Dagster und Prefect verfolgen teilweise modernere Ansätze und können insbesondere in neuen Plattformen eine Alternative sein.
Die sinnvolle Grenze verläuft nicht pauschal zwischen einzelnen Produkten, sondern zwischen Verantwortungsbereichen:
Interne Verarbeitung
Databricks-interne Datenverarbeitung wird in Lakeflow Jobs orchestriert.
Plattformübergreifende Prozesse
Werden im zentralen Unternehmens-Orchestrator gesteuert.
Übergabepunkt
Der externe Orchestrator startet bei Bedarf einen Lakeflow Job, statt jeden Databricks-Schritt selbst abzubilden.
So bleibt die technische Detailsteuerung in Databricks, während der übergeordnete Prozess zentral koordiniert wird.
Wichtig ist, nicht zwei unabhängige Scheduler für dieselbe Prozesskette zu betreiben. Sonst entstehen doppelte Zeitpläne, unklare Fehlerzustände und schwer nachvollziehbare Wiederholungen.
Deployment mit Databricks Asset Bundles und Terraform-Abgrenzung
Eine produktive Datenpipeline besteht aus mehr als einem Notebook: dazu gehören auch Pipeline-Definitionen, Job-Konfigurationen, Parameter, Umgebungsvariablen, Compute-Einstellungen, Berechtigungen, Zeitpläne und Benachrichtigungen.
Databricks Asset Bundles bündeln diese Ressourcen in einer versionierbaren Projektstruktur.
Über definierte Targets können unterschiedliche Konfigurationen für Entwicklung, Test und Produktion verwaltet werden. Deployments lassen sich anschließend über die Databricks CLI und bestehende CI/CD-Systeme ausführen.
Der eigentliche Nutzen entsteht durch den standardisierten Entwicklungs- und Deployment-Prozess:
Pull Requests
Änderungen werden in Pull Requests sichtbar.
Config-Review
Job- und Pipeline-Konfigurationen werden gemeinsam mit dem Code geprüft.
Umgebungen
Umgebungsunterschiede werden explizit beschrieben.
Automatisierung
Deployments lassen sich automatisieren.
Nachvollziehbarkeit
Der aktuelle Produktionsstand kann einem Git-Commit zugeordnet werden.
Weniger manuelle Eingriffe
Manuelle Änderungen in der Oberfläche werden reduziert.
Asset Bundles verbessern auch die Grundlage für Rollbacks. Dabei sollte jedoch zwischen einem Deployment-Rollback und einem Daten-Rollback unterschieden werden.
Ein früherer Code- oder Konfigurationsstand lässt sich erneut deployen. Bereits verarbeitete Daten, geänderte Tabellenstrukturen oder externe Seiteneffekte müssen trotzdem gesondert behandelt werden.
Asset Bundles und Terraform erfüllen unterschiedliche Aufgaben
Asset Bundles ersetzen Terraform nicht: Terraform oder OpenTofu verwalten die Plattforminfrastruktur (Accounts, Workspaces, Metastore, IAM, Netzwerk, Cluster Policies), Asset Bundles die anwendungsnahen Ressourcen (Jobs, Pipelines, Code, Modelle, Dashboards). Die Grenze sollte bewusst definiert werden, damit nicht dieselbe Ressource teils über Terraform, teils über Bundles und teils manuell läuft.
Vom ETL-Wildwuchs zur einheitlichen Data-Engineering-Plattform
Eine Pipeline wird nicht allein deshalb schwer wartbar, weil sie in einem Notebook entwickelt wurde.
Probleme entstehen, wenn grundlegende Engineering-Standards fehlen:
- keine klare Projektstruktur,
- keine Tests,
- manuelle Deployments,
- unklare Abhängigkeiten,
- fehlendes Monitoring,
- kein definierter Owner,
- keine dokumentierte Wiederanlauf- oder Backfill-Strategie.
Mit zunehmender Zahl an Pipelines werden diese Unterschiede im Betrieb immer sichtbarer.
Eine verlässliche Data-Engineering-Plattform braucht deshalb mindestens drei Eigenschaften.
Wiederholbarkeit
Eine Pipeline erzeugt bei gleichem Input ein nachvollziehbares Ergebnis.
Klare Verantwortung
Für jede Pipeline steht fest, wer technisch und fachlich verantwortlich ist.
Verbindliche Schnittstellen
Nachgelagerte Nutzer wissen, worauf sie sich bei Schema, Qualität und Verfügbarkeit verlassen können.
Wiederholbarkeit
Eine Pipeline sollte bei gleichem Input ein nachvollziehbares Ergebnis erzeugen.
Dazu gehören:
- idempotente Verarbeitung,
- kontrollierte Wiederholungen,
- dokumentierte Backfills,
- klar definierte Checkpoints,
- reproduzierbare Deployments,
- Tests für wichtige Transformationen.
Klare Verantwortung
Für jede produktive Pipeline und jedes Datenprodukt sollte feststehen:
- Wer ist technisch verantwortlich?
- Wer verantwortet die fachliche Definition?
- Wer entscheidet über Schemaänderungen?
- Wer wird bei einem Fehler informiert?
- Welche Reaktions- und Wiederherstellungszeiten gelten?
Technische und fachliche Ownership können dabei bei unterschiedlichen Rollen liegen.
Verbindliche Schnittstellen
Nachgelagerte Nutzer müssen wissen, worauf sie sich verlassen können.
Ein solcher Vertrag kann unter anderem festlegen:
- Tabellenname und Schema,
- Aktualisierungsfrequenz,
- erwartete Datenqualität,
- Verfügbarkeit,
- Umgang mit Schemaänderungen,
- verantwortliches Team,
- Deprecation-Prozess.
Diese Informationen sind insbesondere für BI- und AI-Anwendungen wichtig.
Reifegradmodell für Data Engineering auf Databricks
Stufe 1: Individuelle Pipeline-Lösungen. Mehrere ETL-Werkzeuge und Codebasen werden parallel betrieben. Deployments erfolgen unterschiedlich oder teilweise manuell.
Typische Merkmale sind:
- individuelle Python-Skripte,
- getrennte Scheduler,
- uneinheitliches Monitoring,
- unklare Ownership,
- fehlende End-to-End-Lineage,
- aufwendige Wiederherstellung bei Fehlern.
Stufe 2: Databricks als gemeinsame Zielplattform. Die wichtigsten Daten werden bereits im Lakehouse verarbeitet. Bronze-, Silver- und Gold-Strukturen sind etabliert und Unity Catalog übernimmt zentrale Berechtigungsfunktionen.
Die Pipelines sind jedoch noch unterschiedlich umgesetzt:
- einige Declarative Pipelines,
- viele Notebook-Workflows,
- verschiedene Orchestratoren,
- erste Asset-Bundle-Projekte,
- manuelle Konfigurationen in einzelnen Workspaces.
Stufe 3: Verbindliche Engineering-Standards. Neue Pipelines folgen einem definierten Standard.
Typische Merkmale sind:
- deklarative Pipelines für passende Tabellen- und CDC-Strecken,
- Lakeflow Jobs für Databricks-interne Prozesse,
- Asset Bundles als Standard für Deployments,
- automatisierte Tests und CI/CD,
- klare Trennung zwischen Bundle- und Terraform-Ressourcen,
- dokumentierte Ausnahmen für dbt, Airflow oder externe Ingestion-Tools,
- einheitliches Monitoring und Ownership.
Der Übergang von Stufe 2 zu Stufe 3 ist vor allem eine organisatorische Aufgabe.
Dafür müssen Unternehmen verbindlich entscheiden:
- Welche Technologien sind Standard?
- Welche Ausnahmen sind erlaubt?
- Wer betreibt die gemeinsame Plattform?
- Wie werden bestehende Pipelines migriert?
- Welche Qualitäts- und Deployment-Regeln gelten für alle Teams?
Ownership, Lineage und Berechtigungen
Unity Catalog liegt als gemeinsame Governance-Schicht unter Ingestion, Transformation, Orchestrierung und Deployment. Berechtigungen, Ownership und Lineage werden zentral verwaltet, statt in jeder Pipeline und in jedem BI- oder AI-Tool erneut.
Business-Intelligence-Workloads greifen auf kuratierte Silver- und Gold-Tabellen zu, AI-Anwendungen verwenden dieselben Daten für Features, Trainingsdatensätze, Evaluationen oder Agenten. Unity Catalog verbindet beide Bereiche über dieselben Berechtigungen und dieselbe Lineage. Dadurch wird nachvollziehbar, welche Quellen in eine Tabelle eingeflossen sind und welche Reports, Modelle oder Anwendungen sie anschließend verwenden.
Ohne dieses gemeinsame Governance-Modell entstehen trotz gemeinsamer Compute-Plattform schnell wieder getrennte Datenbereiche mit eigenen Berechtigungen und Verantwortlichkeiten.
Fazit
Databricks kann Ingestion, Transformation, Orchestrierung und Deployment auf einer gemeinsamen Plattform zusammenführen.
Der größte Vorteil entsteht nicht durch ein einzelnes Lakeflow-Feature, sondern durch ein einheitliches Engineering-Modell: bevorzugte Ingestion-Wege je Quelltyp, deklarative Pipelines für passende Strecken, klare Grenzen zwischen Lakeflow Jobs und externen Orchestratoren, reproduzierbare Deployments mit Asset Bundles und gemeinsame Governance über Unity Catalog.
Eine vollständige Konsolidierung ist dabei nicht immer sinnvoll. dbt, Airflow, Fivetran oder Airbyte können weiterhin die bessere Lösung sein, wenn sie funktionale Lücken schließen oder in der Organisation bereits fest etabliert sind.
Wichtig ist, dass diese Werkzeuge nicht zufällig parallel betrieben werden. Für jede Komponente sollte klar sein, welche Aufgabe sie übernimmt und warum sie benötigt wird.
Der sinnvollste Einstieg ist deshalb eine Bestandsaufnahme der bestehenden Datenstrecken:
- Welche Pipelines verursachen besonders viel Betriebsaufwand?
- Welche Prozesse sind heute nicht zuverlässig reproduzierbar?
- Wo fehlen Lineage, Monitoring oder klare Verantwortlichkeiten?
- Welche Databricks-Workloads werden noch manuell deployt?
- Welche Drittwerkzeuge liefern weiterhin einen messbaren Mehrwert?
- Welche neue Datenstrecke eignet sich als erster Lakeflow-Standard?
Auf dieser Grundlage lässt sich entscheiden, ob als Nächstes eine Ingestion-Strecke, eine Declarative Pipeline, ein Asset-Bundle-Standard oder eine klarere Orchestrierungsarchitektur umgesetzt werden sollte.
Wo lohnt sich die Konsolidierung in eurem Data-Engineering-Stack?
Verteilte Pipelines, manuelle Deployments und unklare Verantwortlichkeiten kosten im Betrieb oft mehr, als im Tagesgeschäft auffällt. In einem unverbindlichen Erstgespräch schauen wir gemeinsam auf eure Data-Engineering-Landschaft und zeigen, wo die größten Hebel liegen: weniger Betriebsaufwand, schnellere und verlässlichere Pipelines, klare Verantwortung. Ihr bekommt eine ehrliche Einschätzung und konkrete nächste Schritte, ohne Verpflichtung.
- welche eurer Pipelines und Tools echte Kandidaten für eine Konsolidierung auf Databricks sind
- welche Governance-, Orchestrierungs- und Betriebsrisiken vor dem nächsten Ausbau geprüft werden müssen
- welcher Migrationspfad pro Pipeline-Familie trägt und wie ein Rollback-Weg daneben aussieht
FAQ
Data Engineering auf Databricks umfasst Ingestion, Transformation, Orchestrierung und Deployment von Datenpipelines. Typische Komponenten sind Auto Loader und Lakeflow Connect für die Datenaufnahme, Lakeflow Declarative Pipelines für Transformationen, Lakeflow Jobs für die Orchestrierung und Databricks Asset Bundles für reproduzierbare Deployments. Unity Catalog ergänzt Berechtigungen, Ownership und Lineage.
