Databricks DLT mit Lakeflow: Bronze-Silver-Gold-Pipelines bauen
Die Kernaussagen auf einen Blick.
- Lakeflow Declarative Pipelines (vormals Delta Live Tables) ist das deklarative Framework von Databricks für Datenpipelines: Definiert werden Tabellen, Qualitätsregeln und ihre Abhängigkeiten. Die Plattform übernimmt die Ausführungsplanung, die inkrementelle Verarbeitung und die Wiederherstellung nach Fehlern.
- Beim deklarativen Ansatz übernimmt die Runtime einen größeren Teil der Ablaufsteuerung: Statt eines festen Programmablaufs wird der gewünschte Zustand der Tabellen beschrieben.
- Die zentrale Entwurfsentscheidung liegt beim Tabellentyp: Streaming Tables verarbeiten fortlaufend eintreffende Daten inkrementell (typisch für Bronze und Silver), Materialized Views halten abgeleitete Aggregate und Joins aktuell (typisch für Gold). Expectations prüfen die Datenqualität direkt in der Pipeline.
- Empfehlenswert ist, Lakeflow Declarative Pipelines für neue Bronze-, Silver- und Gold-Strecken zu prüfen, mit Qualitätsregeln von Beginn an und einer bewussten Compute-Wahl (Classic oder Serverless) je Pipeline. Für verzweigte Prozess-Workflows ohne Tabellenfokus bleiben Lakeflow Jobs oder Notebooks die passendere Wahl.
Inhaltsverzeichnis
Neuer Name, gleicher imperativer Code
Bei einem Plattform-Review im Frühjahr 2026 hatte ein Team seine bestehenden DLT-Pipelines gerade auf die neue Bezeichnung umgestellt: alle DLT-Pipelines waren auf Lakeflow Declarative Pipelines umbenannt, auch das Repository war inzwischen in lakeflow/ umbenannt worden. Der verantwortliche Engineer fasste die Änderung mit den Worten zusammen: „Neuer Name, gleicher Code." In einer der Pipelines bestand die mit @dlt.table dekorierte Funktion jedoch aus 180 Zeilen imperativer Pandas-Logik, Schleifen über externe API-Calls und einem manuellen spark.sql-Block am Ende, der die Zieltabelle erst leerte und dann neu schrieb. Die Pipeline wurde zwar ausgeführt, die erwartete Lineage in Unity Catalog entstand jedoch nicht.
Diese Situation tritt in vielen gewachsenen Databricks-Plattformen auf. Mit der Umbenennung von DLT (2024/2025) wurde häufig nur die Bezeichnung angepasst. Das zugrunde liegende deklarative Modell wurde dabei nicht immer konsequent übernommen. Ein bestehender Notebook-Workflow wird durch einen zusätzlichen @dlt.table-Decorator noch nicht zu einer sinnvoll modellierten deklarativen Pipeline. Die Vorteile bei Lineage, Wiederanlauf und Datenqualität bleiben dann weitgehend ungenutzt.
Wie viele bestehende Lakeflow-Pipelines unterscheiden sich abgesehen vom @dlt.table-Decorator tatsächlich von einem klassischen Notebook-Workflow? In welchen Pipelines erfolgt die Wiederherstellung nach Fehlern weiterhin über ein manuelles Leeren und Neuladen der Tabellen? In welchen Pipelines sind Qualitätsregeln bereits Bestandteil der Tabellendefinition und wo werden sie weiterhin nachgelagert geprüft? Welche Pipelines würdet ihr heute neu in Lakeflow modellieren, welche bewusst nicht?
Die zentrale Aussage lautet: Lakeflow Declarative Pipelines basiert auf einer klaren Beschreibung des gewünschten Tabellenzustands. Tabellen, Erwartungen und Abhängigkeiten werden beschrieben. Databricks übernimmt daraus die Planung der Abhängigkeiten, der inkrementellen Verarbeitung und der Wiederherstellung. Bei konsequent deklarativer Umsetzung verbessern sich Wartbarkeit, Lineage und die Integration von Qualitätsregeln. Bleibt die Implementierung dagegen überwiegend imperativ, entsteht zusätzlicher Plattformaufwand, ohne dass die wesentlichen Vorteile des Modells genutzt werden.
Was sind Lakeflow Declarative Pipelines?
Lakeflow Declarative Pipelines ist ein Framework zur deklarativen Definition von Datentransformationen auf Databricks. Pipelines werden dabei über die gewünschten Tabellen und ihre Abhängigkeiten beschrieben: über @dlt.table in Python oder CREATE OR REFRESH STREAMING TABLE und CREATE OR REFRESH MATERIALIZED VIEW in SQL. Aus diesen Definitionen erzeugt die Runtime den Ausführungsgraphen. Sie bestimmt die Ausführungsreihenfolge, verwaltet den Verarbeitungszustand und erzeugt die technische Lineage. Der Begriff Lakeflow Declarative Pipelines ersetzt seit dem Rebranding 2024/2025 den älteren Namen Delta Live Tables; Databricks dokumentiert die Komponente jetzt als Lakeflow Spark Declarative Pipelines im Lakeflow-Stack.
Dadurch verändert sich die Aufgabenteilung zwischen Entwicklungsteam und Plattform. In einem klassischen Notebook-Workflow wird jeder Verarbeitungsschritt ausdrücklich programmiert und orchestriert: lies hier, transformiere dort, schreib in die Zieltabelle, fang Fehler hier ab. In einer Lakeflow-Pipeline wird dagegen beschrieben, welche Tabellen aus welchen Quellen entstehen sollen, mit welchen Erwartungen an die Daten und in welchem Schema. Abhängigkeiten und Wiederanlauf werden anschließend von der Pipeline-Runtime verwaltet. Daraus ergeben sich mehrere praktische Vorteile: Lineage entsteht automatisch in Unity Catalog, Datenqualitätsregeln können direkt mit der jeweiligen Tabelle definiert werden statt in einem nachgelagerten Job, und der Anwendungscode konzentriert sich stärker auf die Transformation und den gewünschten Tabellenzustand.
Das Framework ist jedoch nicht für jede Art von Workflow geeignet. Generierte Pipelines mit dynamischen Tabellen-Namen zur Laufzeit, Workflows mit komplexer Verzweigungslogik außerhalb der Datentransformation und Workflows, die ausschließlich Prozesse auslösen und keine Tabellen erzeugen, sind weiterhin besser in Lakeflow Jobs oder einer anderen Orchestrierung aufgehoben. Wie Lakeflow Connect, Auto Loader, Lakeflow Jobs und Asset Bundles im gemeinsamen Betriebsmodell zusammenspielen, zeigen wir im Überblick zu Data Engineering auf Databricks.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Delta Live Tables vs Lakeflow Declarative Pipelines: Was sich geändert hat
Wer nach Delta Live Tables oder Databricks DLT sucht, landet beim selben Produkt. Databricks hat DLT 2024/2025 in Lakeflow Declarative Pipelines umbenannt und als Transformations-Komponente in den Lakeflow-Stack eingeordnet, neben Lakeflow Connect für die Ingestion und Lakeflow Jobs für die Orchestrierung. Der Schwerpunkt der Änderung liegt auf dieser Einordnung; das zugrunde liegende Modell bleibt gleich.
Der Python-Namespace @dlt und die SQL-Syntax mit CREATE OR REFRESH STREAMING TABLE und CREATE OR REFRESH MATERIALIZED VIEW bleiben bestehen, vorhandene DLT-Pipelines laufen unter dem neuen Namen weiter. Parallel hat Databricks die Kern-Prinzipien als Spark Declarative Pipelines in Richtung Apache Spark geöffnet (dazu weiter unten). Eine Migration ist damit nicht erforderlich, und die ältere Bezeichnung bleibt für Recherche und bestehende Dokumentation relevant. Entscheidend bleibt die Frage aus dem vorigen Abschnitt: ob eine Pipeline das deklarative Modell tatsächlich nutzt oder nur den Decorator trägt.
Wie funktioniert das deklarative Modell?
Eine Lakeflow-Pipeline setzt sich im Kern aus drei Elementen zusammen: Tabellen-Definitionen, Expectations und einer Quelle.
Tabellen-Definition
Legt die Transformation und gegebenenfalls das erwartete Schema fest.
Expectations
Definieren die Datenqualitätsregeln für die jeweilige Tabelle.
Quelle
Ein Auto-Loader-Pfad, ein Stream aus einem Kafka-Topic, eine andere Pipeline-Tabelle oder eine reguläre Unity-Catalog-Tabelle.
Aus den Tabellenreferenzen erzeugt die Runtime automatisch den Abhängigkeitsgraphen.
Streaming Table oder Materialized View?
Für die inkrementelle Verarbeitung sind insbesondere zwei Tabellentypen relevant: Streaming Tables und Materialized Views.
Streaming Table wählen, wenn
- Daten fortlaufend eintreffen und nur neue Zeilen hinzukommen (append-only, keine Updates oder Deletes der Bestandszeilen)
- Die Pipeline in Bronze oder Silver liegt und Datei-, Event- oder CDC-Daten verarbeitet
- Auto Loader oder ein Kafka-Stream als Quelle dient
Materialized View wählen, wenn
- Ein Aggregat, Join oder konsumfertiges Ergebnis über veränderliche Eingangstabellen entstehen soll
- Die Tabelle im Gold-Layer sitzt und Endnutzer direkt darauf zugreifen
- Die Eingangsdaten einen endlichen Schlüsselraum haben, statt unbegrenzt zu wachsen
Auto Loader lässt sich direkt als Quelle einer Streaming Table einsetzen. Eine typische Bronze-Pipeline besteht aus einer Streaming Table, die neue Dateien über Auto Loader verarbeitet. Wie Auto Loader und Lakeflow Connect die Ingest-Verantwortung verteilen, klären wir im Überblick zu Auto Loader auf Databricks.
Lakeflow Declarative Pipelines vs Notebook-Workflows
Der Unterschied lässt sich anhand einer typischen CDC-Pipeline verdeutlichen. Im Notebook-Ansatz müssen Aufgaben, Schemata, Checkpoints und Abhängigkeiten für jede Stufe einzeln definiert werden: ein Notebook liest mit spark.readStream aus dem Bronze-Layer, ein zweites Notebook führt einen MERGE-Statement gegen die Silver-Tabelle aus, ein drittes baut die Gold-Aggregation. Drei Workflow-Tasks, drei manuelle Schema-Definitionen, drei Checkpoint-Pfade, ein eigener Data-Quality-Job am Ende. Im deklarativen Ansatz werden die drei Zieltabellen und ihre Beziehungen innerhalb einer Pipeline beschrieben: drei Tabellen-Definitionen in einer Pipeline-Datei, drei Expectations als Teil der Definition, ein Compute-Profil. Verarbeitungszustand, technische Lineage und Wiederanlauf werden von der Runtime verwaltet.
| Aspekt | Notebook-Workflow | Lakeflow Declarative Pipelines |
|---|---|---|
| Pipeline-Definition | imperativer Ablauf, Schritt für Schritt | deklarative Tabellen-Beschreibung |
| Abhängigkeiten | manuell über Workflow-Tasks verdrahtet | implizit aus Tabellen-Referenzen abgeleitet |
| Inkrementalität | per Hand über Checkpoints und Watermarks | über Streaming Tables und Materialized Views |
| Wiederherstellung nach Fehlern | manueller Rerun, ggf. Truncate-and-Reload | Die Runtime verwaltet den Verarbeitungszustand für jede Tabelle |
| Quality-Gates | separater Job nach der Pipeline | Expectations als Teil der Tabellen-Definition |
| Lineage in Unity Catalog | nur, wenn Schreibpfade UC-konform sind | automatisch aus dem Pipeline-Graphen |
| Deployment | Notebook-Sync plus Workflow-Definition | Pipeline-Spec, deploybar über Asset Bundles |
| Compute-Modell | beliebige Cluster | Classic-Pipeline-Cluster oder Serverless Pipelines |
Besonders deutlich wird der Unterschied bei der Einarbeitung neuer Teammitglieder. Bei umfangreichen Notebook-Workflows müssen Abhängigkeiten, Checkpoints und Wiederanlauf häufig erst aus mehreren Dateien und Jobdefinitionen rekonstruiert werden: welcher Task triggert welchen, wo läuft der Wiederanlauf, welches Notebook hängt am Cluster, wie wird das Schema versioniert. In einer deklarativen Pipeline sind Tabellen und Abhängigkeiten zentral über Definitionen und Pipeline-Graph nachvollziehbar. Darin liegt ein wesentlicher Vorteil für Wartbarkeit und gemeinsame Entwicklung.
Datenqualität direkt in der Pipeline prüfen
Expectations integrieren Datenqualitätsregeln direkt in die Pipeline und sind damit ein zentraler Bestandteil des Modells. Eine Expectation beschreibt eine Bedingung, die beim Schreiben einer Tabelle auf die eingehenden Datensätze angewendet wird. Drei Modi stehen zur Verfügung: drop verwirft Zeilen, die die Regel verletzen, quarantine schreibt sie in eine separate Tabelle, fail stoppt die Pipeline.
Dadurch müssen grundlegende Qualitätsprüfungen nicht erst in einem separaten nachgelagerten Prozess erfolgen. Ein separater Datenqualitätsjob kann für diese Regeln häufig entfallen, die Regel sitzt direkt auf dem Schreibpfad. Ein Datensatz ohne erforderlichen Schlüssel wird abhängig vom gewählten Modus ausgeschlossen, isoliert oder führt zum Abbruch der Pipeline. Verletzt ein Datensatz eine fachlich zwingende Regel, bricht die Pipeline ab, bevor nachgelagerte Tabellen mit ungültigen Daten weiterverarbeitet werden. Die Qualitätsregeln werden gemeinsam mit der Pipeline dokumentiert und überwacht: Unity Catalog kann nachvollziehen, welche Regeln auf welcher Tabelle laufen.
Die Wahl des Fehlerverhaltens sollte fachlich und technisch abgestimmt werden.
drop
Eignet sich, wenn einzelne ungültige Ereignisse verworfen werden dürfen: etwa bei Sensor- und Event-Daten, in denen verlorene Zeilen den Bestand nicht verfälschen.
quarantine
Ermöglicht die Weiterverarbeitung und stellt fehlerhafte Datensätze separat zur Prüfung bereit, sodass der Fachbereich die Quarantäne-Tabelle nachprüfen kann.
fail
Eignet sich für Regeln, deren Verletzung eine weitere Verarbeitung ausschließt (etwa Schlüssel-Eindeutigkeit oder Pflicht-Felder im Stammdatenstrom).
Je nach fachlicher Bedeutung können in den einzelnen Schichten unterschiedliche Modi sinnvoll sein: drop in Bronze, quarantine in Silver, fail in Gold-Tabellen mit Vertrags-Charakter.
Welche Runtime passt wann?
Für Lakeflow Declarative Pipelines stehen klassische und serverlose Compute-Varianten zur Verfügung. Classic-Pipeline-Cluster sind dedizierte Compute-Ressourcen pro Pipeline. Größe, Skalierung und weitere Clusteroptionen werden vom Plattformteam konfiguriert; Photon ist optional. Serverless Pipelines laufen auf einem Databricks-verwalteten Compute-Profil mit verwaltetem Photon-Compute, Auto-Skalierung und in der Regel kürzeren Bereitstellungszeiten als bei klassischen Clustern.
Die geeignete Variante hängt von Lastprofil, technischen Anforderungen und Kosten ab.
Serverless Pipelines wählen, wenn
- Lastspitzen unregelmäßig auftreten, etwa CDC-Bursts oder stündliche Updates
- Pipelines kurze Laufzeiten haben und häufig neu gestartet werden
- Die Pipeline sich noch in der Entwicklung befindet, mit häufigem Redeploy
Classic Compute wählen, wenn
- Die Pipeline gleichmäßig hohe Last fährt (24/7-Streaming)
- Spezielle Cluster-Anforderungen bestehen (Init-Skripte, GPU, Custom-Libraries)
- Serverless Pipelines in eurer Region noch nicht GA ist
Regionale Verfügbarkeit und Datenresidenz müssen vor der Festlegung auf Serverless geprüft werden: in vielen Workspaces mit deutscher Daten-Residenz oder Public-Sector-Anforderung ist Serverless noch nicht freigegeben oder läuft über einen anderen Compute-Pfad. Serverless sollte daher nicht ohne Prüfung der regionalen und regulatorischen Anforderungen als allgemeiner Standard festgelegt werden. Wie die Compute-Wahl im Lakehouse-Stack mit Jobs, Warehouses und Apps zusammenspielt, zeigen wir im Überblick zu Serverless auf Databricks.
Lakeflow Declarative Pipelines, Lakeflow Jobs und Spark Declarative Pipelines im Vergleich
Lakeflow Declarative Pipelines ist eine von drei Komponenten im Lakeflow-Stack. Eine klare Abgrenzung hilft dabei, Transformation und Orchestrierung mit den passenden Komponenten umzusetzen.
Lakeflow Jobs übernimmt die übergeordnete Orchestrierung von Pipelines und weiteren Tasks. Ein Job kann eine Pipeline triggern, einen Notebook-Task, einen SQL-Task oder eine externe REST-Call-Sequenz. Was Lakeflow Jobs leistet und wo es als Geschwister-Orchestrierung neben Pipelines steht, klären wir im Überblick zu Lakeflow Jobs. Faustregel: Tabellenorientierte Transformationen eignen sich grundsätzlich für Declarative Pipelines. Die Koordination mehrerer Pipelines, Notebooks und externer Schritte gehört dagegen in Lakeflow Jobs.
Spark Declarative Pipelines (SDP) ist die quelloffene Variante des deklarativen Modells. Databricks hat die Kerntechnologie hinter Lakeflow Declarative Pipelines 2025 an das Apache-Spark-Projekt gespendet und als Spark Declarative Pipelines open-source gestellt; sie wird damit Teil von Apache Spark selbst. Databricks beschreibt die Komponente als Erweiterung von Apache Spark™ Spark Declarative Pipelines. SDP nutzt die gleiche Tabellen-Definitions-Syntax und läuft auch außerhalb der vollständig verwalteten Databricks-Umgebung. Bei Portabilitätsanforderungen (Multi-Cloud-Strategie, on-prem-Komponenten, Vendor-Exit-Pfade) wird SDP damit zur ergänzenden Option. Was SDP von der Managed-Variante unterscheidet und wo die Portabilität greift, zeigen wir im Überblick zu Spark Declarative Pipelines.
Der gemeinsame Deployment-Weg über alle drei Komponenten hinweg sind Asset Bundles. Pipeline-Spec, Job-Definition und SQL-Tasks können gemeinsam in Asset Bundles definiert und über CI/CD in die jeweiligen Workspaces deployt werden. Wie Asset Bundles als IaC-Modell den Pipeline-Stack tragen, klären wir im Überblick zu Asset Bundles.
Lineage, Berechtigungen und Governance
Neue Lakeflow-Pipelines sollten ihre Tabellen in Unity Catalog verwalten. Unity Catalog ist dabei der vorgesehene Governance- und Speicherpfad für neue Implementierungen: UC ist die Default-Speicherung für neue Pipelines, und der ältere Hive-Metastore-Ansatz sollte für neue Pipelines nicht mehr als Zielarchitektur verwendet werden. Daraus ergeben sich Auswirkungen auf drei Bereiche.
Drei Governance-Schichten: Lineage, Rechte, Schema.
Lineage entsteht automatisch aus dem Pipeline-Graphen, Berechtigungen liegen auf Schema-Ebene in Unity Catalog, Schemaänderungen bleiben über den UC-Audit-Trail nachvollziehbar.
Lineage entsteht automatisch. Jede Tabellen-Definition, die eine andere Tabelle als Quelle nennt, erzeugt eine Lineage-Kante in UC. Die Pipeline-Definition bildet zugleich die technische Grundlage für den Datenflussgraphen. Das ersetzt keine fachliche Lineage-Dokumentation, aber es schließt die Lücke zwischen Code und Katalog: Technische Teams und Audit können auf denselben Lineage-Graphen zugreifen. Wie automatische Lineage in UC mit manueller Domain-Dokumentation zusammenspielt, zeigen wir im Überblick zu Unity Catalog Lineage.
Berechtigungen liegen auf Schema-Ebene, nicht in der Pipeline. Die Pipeline schreibt mit einer Service-Principal-Identität in ein UC-Schema. Datenberechtigungen werden über Unity Catalog und nicht innerhalb der Transformationslogik verwaltet. Dadurch bleiben Berechtigungsverwaltung und Pipeline-Code klar voneinander getrennt. Das hat Folgen für die Pipeline-Entwicklung: Entwickler benötigen nur die für Deployment und Ausführung erforderlichen Rechte auf den vorgesehenen Zielobjekten.
Schemaänderungen werden über Unity Catalog nachvollziehbar. Wenn eine Streaming Table eine neue Quell-Spalte aufnimmt, ändert sich das UC-Schema; der Audit-Trail liegt in UC. Ob Schemaänderungen zugelassen werden, muss in der Pipeline bewusst konfiguriert werden: entweder über pipelines.autoOptimize.zOrderCols-Konfiguration, über schemaTrackingLocation oder über die Datenfluss-Definition selbst. Implizite Schema-Drift, die in Notebook-Workflows oft unbemerkt durchläuft, wird hier zur expliziten Entscheidung.
Wann sind Notebook-Workflows besser als Lakeflow Declarative Pipelines?
Nicht jede Verarbeitung lässt sich sinnvoll als deklarative Pipeline modellieren. In vier Situationen können Notebook-Workflows oder Lakeflow Jobs geeigneter sein.
Laufzeit-generierte Pipelines
Tabellen stehen erst zur Laufzeit aus einer Konfiguration fest, z. B. je Mandant unterschiedlich. Das deklarative Modell passt hier nur eingeschränkt.
Komplexe Verzweigungslogik
Prozessbezogene Wenn-Dann-Logik außerhalb der Datentransformation gehört in Lakeflow Jobs oder eine vergleichbare Orchestrierung.
Reine Trigger-Strecken
Pipelines ohne Tabellen-Output, deren einziger Zweck ein REST-Call an ein Drittsystem ist, passen besser als Notebook-Task in einem Job.
Gewachsener Legacy-Spark-Code
Migration lohnt sich meist erst, wenn die Pipeline ohnehin überarbeitet wird oder der zusätzliche Nutzen klar belegt ist.
Faustregel: Neue tabellenorientierte Pipelines sollten mit Lakeflow geprüft werden. Bestehende Pipelines sollten vor allem dann migriert werden, wenn ohnehin eine Überarbeitung ansteht oder der zusätzliche Nutzen klar belegt ist.
Was Lakeflow Declarative Pipelines nicht entscheiden: Architektur, Compute und Operating Model
Lakeflow Declarative Pipelines legt das Verarbeitungsmodell einzelner Datenpipelines fest. Übergreifende Entscheidungen zur Plattform- und Datenarchitektur müssen weiterhin separat getroffen werden: Das Framework legt nicht fest, wie Bronze, Silver und Gold strukturiert sind, welche Tabellen welchem Datenprodukt gehören, ob ein Lakehouse domain-orientiert oder zentral aufgebaut ist, oder welche Identitäts- und Netzwerk-Architektur die Pipelines betreibt.
Drei Plattform-Themen sitzen über der Pipeline-Modell-Entscheidung:
- Ein domain-orientiertes Lakehouse braucht vor dem ersten Pipeline-Default ein Operating Model für Datenprodukte: Ownership, Schema-Verantwortung, Quality-SLAs. Wie Datenprodukt-Topologie und Pipeline-Topologie zusammengehen, zeigen wir im Überblick zu Data Mesh auf Databricks.
- Unity Catalog als Governance-Layer wird unabhängig von der Pipeline-Wahl eingeführt; Berechtigungs-, Tag- und Lineage-Strategie liegen oberhalb. Wie Berechtigungen, Lineage und Audit zusammenspielen, klären wir im Überblick zu Unity Catalog Lineage.
- Compute kontrolliert auszurollen bedeutet, Pipeline-Compute und Job-Compute im selben Rahmen zu entscheiden; sonst entstehen unterschiedliche und nicht abgestimmte Compute-Standards innerhalb desselben Workspace. Wie die Compute-Verteilung zwischen Pipelines, Jobs und Warehouses aussieht, zeigen wir im Überblick zu Serverless auf Databricks.
Lakeflow Declarative Pipelines fügt sich in jedes dieser Modelle ein, gibt aber keines davon vor. Stehen die übergreifenden Plattformstandards nicht zuerst fest, werden diese Architekturentscheidungen am Ende verstreut in einzelnen Pipelines getroffen, oft unbeabsichtigt und ohne gemeinsame Linie.
Grenzen von Lakeflow Declarative Pipelines
Lakeflow Declarative Pipelines verändert die Art, wie Datentransformationen definiert und betrieben werden. Für jeden produktiven Einsatz reicht diese eine Komponente allein jedoch nicht aus; sie sitzt in einem Plattform-Kontext, der die Wirkung trägt oder begrenzt.
Fachliche Modus-Entscheidung nötig
drop, quarantine und fail haben unterschiedliche Konsequenzen für die Datenwahrheit nachgelagerter Tabellen. Die Wahl gehört in die Architektur-Diskussion mit dem fachlichen Owner der Tabelle.
Eingeschränkte Pipeline-Generierung
Lakeflow erwartet eine statische Tabellen-Topologie pro Pipeline. Mandantenspezifische Schemata oder parametrisierte Tabellen-Namen stoßen an Grenzen.
Serverless regional begrenzt
In Regionen ohne Serverless-Verfügbarkeit oder mit speziellen Compliance-Anforderungen bleibt Classic Compute die einzige Option.
Umstellung aufwendiger als Umbenennung
Die technische Umbenennung bestehender DLT-Pipelines ist schnell erledigt. Eine konsequente Umstellung auf das deklarative Modell (imperative Reste raus, Expectations rein) ist deutlich aufwendiger.
Lineage nur für erfasste Schreibwege
Tabellen, die außerhalb der Pipeline geschrieben werden, etwa durch nachgelagerte Notebook-Tasks, erscheinen in der UC-Lineage nicht.
Trotz dieser Einschränkungen ist Lakeflow Declarative Pipelines für viele neue tabellenorientierte Data-Engineering-Pipelines auf Databricks eine geeignete Option. Der Wartbarkeits- und Lineage-Hebel trägt, sobald die Pipeline regelmäßig läuft und mehrere Engineers daran arbeiten. Ein zweiter Hebel ist die Abstraktion vom Betrieb: Mit Serverless Pipelines entfällt das Cluster-Management, und die laufende Tabellenpflege wie OPTIMIZE und VACUUM erledigt Predictive Optimization automatisch. Eigene Aufräum-Jobs entfallen damit, und der Betriebsaufwand sinkt. Sobald ein Pipeline-Default für die Plattform gesetzt ist, sollten Compute-Profil, Expectations-Modi und Asset-Bundle-Deployment in einem konsistenten Vorgehen geklärt sein. Ohne gemeinsame Standards entstehen unterschiedliche Implementierungs- und Betriebsmodelle innerhalb derselben Plattform. Damit geht ein wesentlicher Vorteil der Standardisierung verloren.
Fazit
Lakeflow Declarative Pipelines verbindet Transformationscode mit standardisierten Plattformfunktionen für Lineage, Datenqualität und Wiederanlauf.
Lakeflow Declarative Pipelines verbindet Transformationscode mit standardisierten Plattformfunktionen für Lineage, Datenqualität und Wiederanlauf: Die Entwicklung beschreibt den gewünschten Tabellenzustand, während die Runtime die Ausführung organisiert. Dadurch entsteht ein einheitliches Modell für Transformation, technische Lineage und Qualitätsregeln.
Für eine erfolgreiche Einführung sind drei Faktoren besonders wichtig. Der Nutzen steigt insbesondere, wenn automatische Lineage und zentrale Governance tatsächlich benötigt werden. Werden Tabellen außerhalb der vorgesehenen Unity-Catalog-Pfade geschrieben, geht ein wesentlicher Teil des Nutzens verloren. Qualitätsregeln sollten von Beginn an vorgesehen werden, da eine spätere Integration häufig aufgeschoben wird. Auch das Compute-Profil pro Pipeline (Classic gegen Serverless) gehört pro Pipeline geklärt. Wenn diese drei Faktoren nicht klar sind, schiebt der Pipeline-Default das Problem in den Code.
Teams, die Pipelines noch ohne Lineage-Anforderung bauen, Quality-Gates als nachgelagerten Job betreiben und Compute über alle Pipelines hinweg pauschal setzen: In solchen Umgebungen ist zunächst zu prüfen, welches konkrete Problem durch einen Wechsel gelöst werden soll.
Qualitätsregeln sollten bereits bei der ersten Tabellendefinition berücksichtigt werden, mit fachlicher Modus-Entscheidung pro Tabelle. Compute-Wahl bewusst pro Pipeline. Bestehende DLT-Pipelines können technisch unter der neuen Bezeichnung weitergeführt werden. Eine inhaltliche Überarbeitung ist vor allem dann sinnvoll, wenn die Pipeline ohnehin angepasst oder neu gestaltet wird.
Der Nutzen entsteht nicht allein durch den verwendeten Decorator. Entscheidend ist die konsequente Beschreibung von Tabellen, Abhängigkeiten und Qualitätsanforderungen als deklaratives Modell.
Lakeflow Declarative Pipelines als Default für neue Bronze/Silver/Gold-Strecken mit Lineage-Anforderung.
FAQ
Konzeptionell ja, namensseitig nein. Lakeflow Declarative Pipelines ist der neue Name für das Pipeline-Framework, das vorher Delta Live Tables (DLT) hieß. Der -Decorator bleibt vorerst gültig, die Pipeline-Spec ist kompatibel. Was sich ändert: die Einbettung in den Lakeflow-Stack neben Lakeflow Connect und Lakeflow Jobs, und der Default-Compute über Serverless Pipelines.
