Spark Declarative Pipelines: Was Open Source vom Lakeflow-Modell übernimmt und was nicht
Die Kernaussagen auf einen Blick.
- Spark Declarative Pipelines (SDP) überträgt das deklarative Pipeline-Modell in den Apache-Spark-Standard: Tabellen-Definitionen, automatische Abhängigkeiten, Erwartungen als Data-Quality-Gates.
- Portabel ist vor allem die Definition der Pipeline. Compute, Lineage, Deployment und Monitoring müssen außerhalb von Databricks selbst aufgebaut und betrieben werden.
- Vor der Entscheidung sollte geklärt werden, ob tatsächlich mehrere Spark-Zielplattformen vorgesehen sind, welche benötigten Funktionen in der eingesetzten Spark-Version bereits stabil verfügbar sind und wer Betrieb, Monitoring und Lineage trägt.
- Mein Vorschlag: Die Anforderungen an Portabilität sollten für jede Pipeline separat bewertet werden. SDP ist vor allem dort sinnvoll, wo ein zweites Spark-Ziel konkret geplant ist.
Inhaltsverzeichnis
Open Source ist nicht automatisch der Ersatz
In Architektur-Reviews geht es bei Spark-Pipelines selten um eine einzelne Technologie, sondern um die Wahl zwischen drei Bauweisen: klassische Spark-Notebooks für Batch und Structured Streaming, das verwaltete deklarative Modell als Lakeflow Declarative Pipelines (vormals Delta Live Tables) und seit Apache Spark 4.0 die Open-Source-Spur Spark Declarative Pipelines. Sobald Multi-Cloud oder eine Open-Source-Vorgabe zur Sprache kommt, fällt schnell der Satz: „Mit SDP haben wir das deklarative Modell jetzt im Spark-Standard, das ersetzt Lakeflow." Diese Gleichsetzung greift zu kurz.
Die drei Bauweisen lösen unterschiedliche Probleme. Klassische Notebooks geben volle Kontrolle, verlangen aber, dass Abhängigkeiten, Inkremente, Datenqualität und Wiederanlauf von Hand programmiert und separat orchestriert werden. Das deklarative Modell nimmt genau diese Mechanik ab, ob als Lakeflow Declarative Pipelines oder als SDP: Beschrieben werden Zieltabellen und Erwartungen, die Engine leitet Reihenfolge, Inkremente und Streaming ab. Der Unterschied zwischen Lakeflow und SDP liegt deshalb nicht im deklarativen Modell, sondern im mitgelieferten Betrieb: Compute, Deployment, Lineage, Monitoring.
Wann lohnt das deklarative Modell überhaupt gegenüber einem sauber gebauten Spark- oder Streaming-Notebook? Wenn deklarativ, warum dann SDP statt Lakeflow Declarative Pipelines? Welches Team übernimmt Compute-Betrieb, Lineage und Deployment außerhalb von Databricks? Sind die benötigten SDP-Funktionen in der eingesetzten Spark-Version bereits produktionsreif?
Die Entscheidung läuft damit in zwei Stufen: zuerst deklaratives Modell oder klassisches Notebook, dann, falls deklarativ, Lakeflow oder SDP. Den zweiten Schritt entscheidet selten die grundsätzliche Open-Source-Präferenz. Ausschlaggebend ist, ob ein zweites Spark-Ziel tatsächlich geplant und finanziert ist und wer Betrieb, Monitoring und Lineage außerhalb von Databricks übernimmt.
Was sind Spark Declarative Pipelines?
Spark Declarative Pipelines (SDP) stellen ein deklaratives Pipeline-Framework innerhalb von Apache Spark bereit. Deklarativ heißt: Beschrieben wird das gewünschte Ergebnis, also welche Tabellen mit welchem Inhalt entstehen sollen, statt wie beim imperativen Ansatz jeden Verarbeitungsschritt und seine Reihenfolge selbst auszuprogrammieren. Anstelle eines fest programmierten Ablaufs werden Zieltabellen, Transformationen und Abhängigkeiten beschrieben, ergänzt um die zugehörigen Datenqualitätsregeln. Spark erzeugt daraus den Ausführungsgraphen und bestimmt die Reihenfolge der Verarbeitung, plant inkrementelle Updates und führt sie aus. Die Apache-Spark-Dokumentation beschreibt SDP als deklaratives Framework für zuverlässige, wartbare und testbare Pipelines auf Apache Spark.
Das Modell stammt aus der bisherigen Entwicklung deklarativer Pipelines bei Databricks: Das deklarative Modell, das intern als Delta Live Tables und später Lakeflow Declarative Pipelines reifte, wurde über den Spark-Verbesserungsprozess in das Apache-Spark-Projekt eingebracht. Es handelt sich um eine Überführung zentraler Bestandteile des deklarativen Modells in das Open-Source-Projekt. Für die Architektur ergibt sich daraus eine wichtige Unterscheidung: Die Pipeline-Definition kann grundsätzlich auf unterschiedlichen Spark-Plattformen eingesetzt werden. Die integrierten Databricks-Funktionen für Betrieb und Governance sind darin jedoch nicht enthalten.
SDP ist keine vollständig funktionsgleiche Open-Source-Ausgabe von Lakeflow Declarative Pipelines. Der verwaltete Compute-Betrieb, das Deployment über Databricks Asset Bundles, die automatische Lineage in Unity Catalog und die Monitoring- und Betriebsfunktionen der Databricks-Plattform sind kein Teil des Apache-Spark-Projekts. Diese Funktionen bleiben Bestandteile des Databricks-Produkts. Die Differenz-Tabelle weiter unten macht das konkret. Wie sich das deklarative Modell in den Data-Engineering-Stack auf Databricks insgesamt einordnet, 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.
Tabellen, Expectations und Inkrementalität
Der zentrale Unterschied zu klassischen Spark-Jobs liegt in der Art der Definition: Die Pipeline beschreibt den gewünschten Zustand der Zieltabellen. Die Engine leitet daraus Abhängigkeiten und Ausführungsreihenfolge ab. Beim imperativen Ansatz programmiert das Entwicklungsteam jeden Verarbeitungsschritt und seine Reihenfolge ausdrücklich. SDP-Pipelines sind deklarativ, der Entwickler beschreibt Ziel-Tabellen und ihre Qualitäts-Erwartungen. Die Engine bestimmt Abhängigkeiten, Reihenfolge und inkrementelle Verarbeitung.
Tabellendefinitionen statt Job-Skripte. Eine SDP-Pipeline besteht aus deklarativen Definitionen der Zieltabellen in SQL oder Python. Jede Tabelle wird über eine Query definiert, die jeweils aus Quellen oder vorgelagerten Tabellen abgeleitet wird. Die Engine erkennt die Abhängigkeiten zwischen diesen Tabellen automatisch und baut daraus den Ausführungs-Graphen. Das Prinzip ähnelt dem Abhängigkeitsmodell von dbt. Bei SDP ist es jedoch direkt im Spark-Framework umgesetzt.
Der Screenshot zeigt das deklarative Modell im Databricks-Lakeflow-Editor: in der Mitte die SQL-Definition einer Tabelle, rechts der daraus automatisch abgeleitete Graph. Genau diese Definition ist der portable Teil. SDP nutzt dasselbe Modell, allerdings ohne die umgebende Editor- und Betriebsschicht.
Datenqualitätsregeln innerhalb der Pipeline. Pro Tabelle lassen sich Erwartungen (Expectations) definieren, also Datenqualitäts-Regeln, die bei jeder Ausführung geprüft werden. Je nach Konfiguration können ungültige Datensätze protokolliert, ausgeschlossen oder zum Abbruch der Pipeline führen. Grundlegende Datenqualitätsregeln werden damit direkt mit der Tabelle definiert. Apache Spark dokumentiert die SDP-Komponenten und das CLI-Tooling im Spark Declarative Pipelines Programming Guide.
Automatische inkrementelle Verarbeitung und Unterstützung für Streaming. Die Engine entscheidet auf Basis der Tabellen-Definitionen, welche Daten seit dem letzten Lauf hinzugekommen sind und welche Ergebnisse aktualisiert werden müssen. Streaming-Quellen werden über die Spark-Structured-Streaming-Mechanik eingebunden. Batch- und Streaming-Quellen können innerhalb desselben deklarativen Modells verarbeitet werden. Die gemeinsame Modellierung von Batch und Streaming gehört zu den zentralen Prinzipien des Ansatzes und ist jetzt Teil der OSS-Spur. Eine erste Übersicht der Apache-Spark-4.0-Implementierung zeigt das Modell entlang konkreter Beispiele.
Für die Architektur bedeutet das: Die Pipeline-Definition selbst ist portabel. Sie hängt ausschließlich an Apache-Spark-APIs. Compute, Deployment, Monitoring und Governance bleiben vom gewählten Plattformbetrieb abhängig.
Spark Declarative Pipelines vs Lakeflow Declarative Pipelines
Die folgende Gegenüberstellung zeigt die wesentlichen Unterschiede. Sie macht sichtbar, welche Funktionen SDP abdeckt und welche zusätzlichen Plattformleistungen Databricks bereitstellt. Microsoft Learn dokumentiert Lakeflow Spark Declarative Pipelines als Framework für Batch- und Streaming-Pipelines in SQL und Python auf der Databricks-Plattform.
| Aspekt | Lakeflow Declarative Pipelines (Databricks) | Spark Declarative Pipelines (OSS) |
|---|---|---|
| Pipeline-Definition | SQL/Python, deklarative Tabellen | SQL/Python, deklarative Tabellen |
| Expectations / Quality-Gates | ja, mit Aktionen (warn, drop, fail) | ja, im Apache-Spark-Standard |
| Inkrementelle Ausführung | automatisch | automatisch |
| Streaming-Unterstützung | nativ über Structured Streaming | nativ über Structured Streaming |
| Compute | managed (Serverless Pipelines oder klassische Cluster) | self-managed (Spark-Cluster auf YARN, Kubernetes, Standalone) |
| Orchestrierung | integriert mit Lakeflow Jobs | externe Orchestrierung (Airflow, Argo, eigener Scheduler) |
| Deployment | Asset Bundles als Konvention | offen, Teams definieren das Modell |
| Lineage | automatisch in Unity Catalog | manuell oder über externes Lineage-Tool |
| Monitoring / UI | Databricks-Pipeline-UI mit Run-Historie | Spark UI, externe Tools |
| Governance | Unity Catalog-Integration | externer Katalog oder kein zentraler Katalog |
| Reife | produktiv im Einsatz seit Lakeflow-Launch | Reife und Funktionsumfang hängen von der eingesetzten Spark-Version ab |
| Lizenz / Lock-in | Databricks-Produkt-Bindung | Apache-2.0-Lizenz, plattform-unabhängig |
Aus der Gegenüberstellung ergeben sich zwei zentrale Punkte. Erstens: Die Pipeline-Definition selbst, also das, was Entwickler schreiben, ist in beiden Spuren inhaltlich weitgehend vergleichbar. Zweitens: Compute, Deployment, Lineage, Monitoring und Governance müssen bei SDP außerhalb von Databricks selbst bereitgestellt werden und werden bei Lakeflow weitgehend durch die Databricks-Plattform übernommen.
An dieser Unterscheidung sollte sich die Portabilitätsentscheidung orientieren. Eine portable Definition reicht für die meisten Multi-Target-Szenarien. Für einen wirklich plattformunabhängigen Betrieb muss zusätzlich eine eigene Betriebs- und Governance-Schicht aufgebaut werden, und das ist ein eigenständiges Plattformvorhaben mit dauerhaftem Betriebsaufwand.
Was diese Komfort- und Betriebsschicht umfasst, zeigt derselbe Editor an anderer Stelle: integrierte SQL-Entwicklung, automatischer Pipeline-Graph und ein Genie-Assistent, der eine Medallion-Pipeline aus einer Anweisung vorschlägt. Diese Schicht gehört zum Databricks-Produkt, nicht zur portablen SDP-Definition.
Welche Spark-Version braucht SDP?
Spark Declarative Pipelines wurden mit den ersten Apache-Spark-4.x-Versionen als eigenes Modul eingeführt. Der Funktionsumfang wächst mit jedem Release. Welche Funktionen stabil verfügbar sind, hängt von der konkret eingesetzten Spark-Version ab. Für eine belastbare Bewertung muss immer auch die eingesetzte Spark-Version genannt werden.
Die Lakeflow-Variante auf Databricks verfügt durch die vorherige Entwicklung als DLT und Lakeflow über einen deutlichen Reifevorsprung. Der Funktionsumfang von SDP wird schrittweise erweitert. Neue Features wie automatische Materialisierungs-Strategien oder erweiterte Streaming-Semantik werden häufig zunächst in Lakeflow erprobt und später in Apache Spark übernommen. Diese Reihenfolge ist nicht zufällig: Databricks gehört zu den maßgeblichen Beitragenden des SDP-Moduls und entwickelt und erprobt viele Funktionen zunächst innerhalb der eigenen Plattform.
Das hat zwei Konsequenzen. Erstens ist die Roadmap der OSS-Spur eng an die Lakeflow-Roadmap gekoppelt: Zwischen der Verfügbarkeit in Lakeflow und Apache Spark kann ein zeitlicher Abstand entstehen. Wie groß dieser Abstand ist, unterscheidet sich je nach Funktion. Zweitens muss der Reifegrad für jede benötigte Funktion einzeln bewertet werden: Die Tabellen-Definition mit Erwartungen ist produktionsreif, weniger verbreitete oder komplexere Einsatzszenarien wie verteilte Materialisierungen über mehrere Storage-Schichten brauchen Prüfung.
Vor jedem SDP-Einsatz gehört der GA-Status der konkret benötigten Features in der eingesetzten Spark-Version geprüft, idealerweise gegen die offizielle Apache-Spark-Dokumentation und die SDP-bezogenen Tickets im Spark-Tracker. Diese Prüfung sollte vor der Festlegung der Zielarchitektur erfolgen.
Was ist wirklich portabel?
Portabilität betrifft unterschiedliche Architekturschichten in unterschiedlichem Maß. Pipeline-Code, Compute, Storage, Deployment und Governance müssen getrennt betrachtet werden. Bei SDP ist vor allem die Pipeline-Definition übertragbar. Andere Bestandteile müssen auf der Zielplattform neu bereitgestellt oder angepasst werden.
Compute-Manager. SDP-Pipelines laufen auf jedem Spark-fähigen Compute-Manager: YARN-Cluster on-premises, Kubernetes-basierte Spark-Operatoren, Standalone-Spark-Cluster in eigener Verwaltung oder managed Spark-Dienste wie EMR. Die Pipeline kann grundsätzlich auf unterschiedlichen Spark-Umgebungen ausgeführt werden. Der Betrieb der jeweiligen Spark-Infrastruktur bleibt jedoch Aufgabe des Plattformteams.
Storage-Schicht. SDP liest und schreibt über Spark-Standard-APIs, also alles, was Spark als DataSource ansprechen kann: Delta Lake (auch außerhalb Databricks via Delta-OSS), Apache Iceberg, Hudi, Parquet, JDBC-Quellen. Das verwendete Tabellen- und Speicherformat kann unabhängig gewählt werden. Transaktionssicherheit, Versionierung und Schemaentwicklung hängen anschließend vom gewählten Tabellenformat ab.
Lineage. Bei Lineage bestehen deutliche Unterschiede zwischen den Plattformen. Unity Catalog liefert auf Databricks automatische Spalten-Lineage. SDP selbst stellt keine mit Unity Catalog vergleichbare automatische Lineage bereit. Ein SDP-Betrieb außerhalb Databricks braucht entweder ein externes Lineage-Tool wie OpenLineage oder muss auf automatische Lineage verzichten. Der fehlende Aufwand wird häufig erst bei Audit-, Fehleranalyse- oder Impact-Anforderungen sichtbar.
Deployment. Asset Bundles als Databricks-Konvention für Deployment sind kein portabler Teil, sie hängen am Databricks-CLI-Stack. Außerhalb von Databricks muss das Team einen eigenen standardisierten Deployment-Prozess definieren, typischerweise über Git-Repositories mit CI/CD-Workflows, die Build, Paketierung und Ausführung der Spark-Anwendung steuern. Wie Asset Bundles als Deployment-Konvention auf Databricks funktionieren, zeigen wir im Überblick zu Databricks Asset Bundles.
Die Portabilität von SDP liegt also vor allem in der Pipeline-Definition selbst. Die übrigen Plattformfunktionen müssen selbst umgesetzt oder durch weitere Werkzeuge ergänzt werden. Dieser zusätzliche Aufwand sollte in der Architektur- und Wirtschaftlichkeitsbewertung ausdrücklich berücksichtigt werden.
Betriebsmodell für Spark Declarative Pipelines: Compute, Orchestrierung und Monitoring
Beim Betriebsmodell werden die zusätzlichen Anforderungen konkret. Lakeflow Declarative Pipelines übernimmt auf Databricks mehrere Funktionen für Compute, Orchestrierung, Monitoring und Governance. Bei SDP außerhalb von Databricks müssen diese Funktionen selbst bereitgestellt oder mit klar benannten Einschränkungen weggelassen werden.
Compute-Management. Spark-Cluster auf Kubernetes oder YARN erfordern Prozesse für Bereitstellung, Skalierung, Ressourcenbegrenzung und Fehlerbehandlung. Managed Spark-Dienste wie EMR oder Dataproc verringern den Betriebsaufwand, beseitigen ihn jedoch nicht vollständig. Auf Databricks läuft die Pipeline auf managed Compute mit Serverless-Option, das ist eine verwaltete Plattformleistung, deren Kosten gegen den eigenen Betriebsaufwand abgewogen werden müssen.
Pipeline-Orchestrierung. SDP übernimmt nicht automatisch die übergeordnete zeitliche oder ereignisbasierte Orchestrierung. Auf Databricks integriert das die Lakeflow-Jobs-Schicht, außerhalb braucht es einen externen Orchestrator. Wie Lakeflow Jobs die Orchestrierung auf Databricks tragen, zeigen wir im Überblick zu Lakeflow Jobs. In der OSS-Spur sind Airflow, Argo Workflows oder ein eigener Scheduler die üblichen Optionen.
Monitoring und Run-Historie. Die Databricks-Pipeline-UI zeigt Run-Status, fehlgeschlagene Erwartungen, Lineage-Sichten und Performance-Metriken. Außerhalb gibt es die Spark-UI. SDP selbst stellt darüber hinaus keine mit der Databricks-Pipeline-UI vergleichbare Betriebsoberfläche bereit. Für eine langfristige Ausführungshistorie müssen Logs zentral gespeichert, aufbereitet und visualisiert werden.
Governance und Berechtigungen. Unity Catalog trägt Berechtigungen, Lineage, Audit-Logs und Discovery zentral. Außerhalb Databricks ersetzt das ein externer Katalog wie Apache Polaris, Project Nessie oder ein eigenes Berechtigungs-Modell auf Storage-Ebene. Der Aufbau einer vergleichbaren Governance-Schicht verursacht erheblichen technischen und organisatorischen Aufwand.
Für die Gesamtbewertung bedeutet das: SDP außerhalb Databricks ist die Pipeline-Definition zuzüglich der Kapazität für den Aufbau und Betrieb der erforderlichen Plattformkomponenten, die Compute, Orchestrierung, Monitoring und Governance trägt. Das kann sich lohnen, wenn die Plattform-Strategie es verlangt. Es ist aber kein Ansatz ohne relevante Einführungs- und Folgekosten.
Portable SDP-Definition mit Databricks Lakeflow betreiben
Eine für viele Unternehmen praktikable Zwischenlösung liegt zwischen den beiden Polen. SDP als Definitions-Schicht, die portabel bleibt, gleichzeitig Databricks weiterhin als primäre Betriebsplattform, solange sie die fachlichen und technischen Anforderungen erfüllt. Das Modell läuft so:
Die Pipeline-Definition wird als SDP geschrieben, also gegen die Apache-Spark-APIs ohne Databricks-spezifische Erweiterungen. Sie läuft auf Databricks innerhalb der Lakeflow-Pipeline-Mechanik, die Deployment-Schicht trägt Asset Bundles, die Orchestrierung läuft über Lakeflow Jobs. Compute, Deployment, Monitoring und Governance können weiterhin über die Databricks-Plattform genutzt werden. Gleichzeitig ist die Definition selbst portierbar: Sollte später tatsächlich ein weiteres Spark-Ziel erforderlich werden, sei es ein Cloud-Wechsel, ein zweiter Spark-Cluster auf Kubernetes für Sovereign-Cloud-Anforderungen oder eine Test-Umgebung außerhalb Databricks, lässt sich die Definition mit geringerem Aufwand auf die neue Plattform übertragen.
Dieses Modell setzt zwei klare Regeln voraus. Erstens muss die Pipeline-Definition konsequent auf standardisierte Spark- und SDP-Funktionen beschränkt bleiben, also auf Databricks-spezifische Erweiterungen verzichten, sofern der zusätzliche Nutzen proprietärer Funktionen den Verlust an Portabilität nicht rechtfertigt. Das verlangt eine bewusste Architektur-Regel im Team. Zweitens muss klar sein, dass portabel ausschließlich die Pipeline-Logik bleibt. Die Orchestrierung, das Deployment und die Lineage sind nicht portierbar, sie müssen auf der Zweitplattform neu gebaut werden.
Für viele Databricks-Plattformen ist dies ein realistischer Kompromiss. Sie erhält einen Teil der Portabilität, ohne auf die verwalteten Databricks-Funktionen verzichten zu müssen. Sie verlangt aber eine Disziplin im Pipeline-Design, die durch Architekturstandards, Reviews und technische Leitplanken abgesichert werden muss.
Spark Declarative Pipelines oder Lakeflow Declarative Pipelines?
Die Entscheidung zwischen SDP und Lakeflow Declarative Pipelines lässt sich anhand weniger Kriterien strukturieren. Wir gehen sie der Reihe nach durch.
Multi-Target-Realität. Wenn die Roadmap mehrere Spark-Plattformen vorsieht, also Databricks plus EMR plus on-premises Spark oder ähnlich, dann ist SDP die richtige Wahl für die Definitions-Schicht. Die Portabilität hat in diesem Fall einen konkreten praktischen Nutzen, weil die gleiche Pipeline auf mehreren Targets laufen muss. Bei nur einer Plattform auf der Roadmap bleibt Portabilität zunächst nur eine Option für ein mögliches zukünftiges Szenario, und Lakeflow ist dann häufig die einfachere und schneller produktive Lösung.
Open-Source-Pflicht. In manchen Industrien oder regulierten Bereichen verlangt die interne Architektur-Governance OSS-Lizenzen für strategische Komponenten. Wenn diese Vorgabe gilt, ist SDP eine naheliegende Option für die Pipeline-Definition. Der zusätzliche Plattformaufwand muss entsprechend eingeplant werden.
Migrations-Pfad aus Lakeflow. Wenn ein Team aus einer Lakeflow-Strecke heraus auf eine andere Plattform migrieren will, kann die schrittweise Umstellung auf standardisierte SDP-Definitionen das Risiko der späteren Migration reduzieren. Die Definition bleibt stabil, der Betrieb wandert. Dadurch bleibt ein späterer Plattformwechsel möglich, ohne dass er bereits kurzfristig umgesetzt werden muss.
Plattform-Engineering-Kapazität. Ohne ein internes Team, das Compute-Management, Orchestrierung und Lineage tragen kann, ist SDP außerhalb Databricks ein riskanter Pfad. Die technische Pipeline kann funktionieren, während Betrieb, Monitoring und Governance unzureichend bleiben. Lakeflow auf Databricks bleibt in dieser Konstellation die betrieblich risikoärmere Lösung.
Geschwindigkeit zur Produktion. Eine schnelle erste Pipeline auf einer bestehenden Databricks-Plattform ist mit Lakeflow Declarative Pipelines mit geringerem Einführungsaufwand produktiv einsetzbar. Die OSS-Spur lohnt sich, wenn langfristige Architekturvorgaben wichtiger sind als die kurzfristige Umsetzungsgeschwindigkeit.
Zusammengefasst gilt: SDP ist die richtige Wahl, wenn Multi-Target-Realität, OSS-Pflicht oder eine geplante Plattform-Migration einen konkreten Nutzen aus der Portabilität ziehen und ein Plattform-Engineering-Team den Betrieb trägt. Lakeflow Declarative Pipelines bleibt die richtige Wahl, wenn Databricks die strategische Heimat ist und die Vorteile des verwalteten Betriebs die zusätzliche Plattformabhängigkeit rechtfertigen.
Was Spark Declarative Pipelines nicht entscheiden: Pipeline-Code vs Plattformstrategie
Die Wahl zwischen SDP und Lakeflow ist eine Frage des Betriebsmodells. Das deklarative Modell selbst ist in beiden Spuren identisch, der Unterschied liegt in der Betriebs-, Governance- und Deployment-Schicht. Die eigentliche Architekturentscheidung betrifft daher die übergeordnete Spark-Plattform: Wie sieht die Spark-Plattform-Strategie insgesamt aus?
Auf einer Databricks-Plattform, in der Lakeflow Jobs, Unity Catalog, Asset Bundles und Serverless-Compute ineinandergreifen, ist das deklarative Modell ein Baustein in einer fest gewählten Architektur. SDP kann in diesem Fall eine spätere Migration erleichtern. Auf einer Spark-Plattform jenseits Databricks, sei es EMR, Dataproc, Synapse oder eigene Kubernetes-Cluster, steht eine andere Architektur-Frage im Raum: Wie werden Compute, Orchestrierung, Deployment und Governance auf der eigenen Plattform ergänzt? Auch das Compute-Modell auf Databricks ist Teil dieser Plattform-Frage.
Anders gesagt: Die Wahl des Pipeline-Modells sollte aus der übergeordneten Plattformstrategie abgeleitet werden. Sie ersetzt diese Plattformentscheidung nicht. Andernfalls entsteht lediglich portabler Pipeline-Code innerhalb eines weiterhin stark plattformabhängigen Betriebsmodells.
Grenzen von Spark Declarative Pipelines
Auch eine konsequent geführte Entscheidung für SDP oder Lakeflow hat Einschränkungen, die bei der Plattform-Diskussion oft erst spät auftauchen.
Portabler Code macht einen Plattformwechsel nicht automatisch einfach. Eine portable Pipeline-Definition heißt nicht, dass die Migration zwischen Plattformen trivial wäre. Daten-Backfills, Storage-Format-Konvertierung, Lineage-Rekonstruktion und Orchestrierungs-Umstellung tragen einen erheblichen Aufwand. Sie reduziert vor allem den Aufwand für die Übertragung der Transformationslogik.
Unterschiede beim Funktionsumfang werden häufig erst bei konkreten Anforderungen relevant. Die ein bis zwei Quartale Versatz zwischen Lakeflow-Features und SDP-Features klingen klein. Sie können jedoch die Wahl der Zielplattform beeinflussen, sobald eine konkrete Geschäfts-Anforderung an einem Feature hängt, das in Lakeflow bereits produktiv läuft und in SDP noch nicht stabil ist.
Eigenes Plattform-Engineering kostet. Compute-Management, Orchestrierung, Lineage und Monitoring außerhalb Databricks zu bauen ist ein dauerhaftes Plattformvorhaben mit eigenem Personal- und Betriebsbedarf. Diese Position muss den Lizenz- und Nutzungskosten einer verwalteten Plattform gegenübergestellt werden.
Hybrid-Disziplin verlangt aktive Governance. Eine Pipeline-Definition, die SDP-konform bleibt, obwohl sie auf Databricks läuft, ist nur dann portabel, wenn das Team aktiv darauf achtet. Werden im Laufe der Zeit proprietäre Funktionen in die Pipeline aufgenommen, sinkt die tatsächliche Übertragbarkeit der Pipeline.
Auch ein Open-Source-Stack enthält technische Abhängigkeiten und langfristige Architekturentscheidungen. Spark als Plattform-Standard, Kubernetes als Compute-Schicht, Iceberg als Storage-Format, OpenLineage als Lineage-Tool: Jede dieser Wahlen ist offen, aber sie ist eine Wahl. Auch ein OSS-Stack ist eine Kombination mehrerer aufeinander abgestimmter Plattformkomponenten, die zusammenpassen müssen.
Eine offene Lizenz verhindert keine Abhängigkeit vom gewählten Betriebsanbieter. Apache-2.0 verhindert keine Plattform-Bindung. SDP auf einem managed Spark-Dienst eines Cloud-Anbieters bringt Cloud-Lock-in mit, auch wenn die Software offen ist. Diese Abhängigkeit sollte bei der Bewertung ausdrücklich berücksichtigt werden.
Fazit
Spark Declarative Pipelines ist besonders sinnvoll, wenn konkret mehrere Spark-Plattformen unterstützt werden sollen oder wenn strategische Komponenten zwingend unter einer Open-Source-Lizenz stehen müssen.
Besonders relevant ist das für Architektur-Teams in regulierten Umgebungen, in Multi-Cloud-Setups oder bei geplanten Plattformwechseln von Databricks auf eine andere Spark-Umgebung, bei denen die Transformationslogik möglichst unverändert bleiben soll. Lakeflow Declarative Pipelines bleibt die richtige Wahl, wenn Databricks die strategische Heimat ist und die integrierten Betriebs- und Governance-Funktionen wichtiger sind als maximale Plattformunabhängigkeit.
Für die Entscheidung gilt ein zentraler Grundsatz: SDP schafft Portabilität vor allem auf Ebene der Pipeline-Definition. Compute, Deployment, Monitoring und Governance bleiben plattformspezifisch. Ohne diese Trennung entsteht trotz OSS-Lizenz Plattform-Abhängigkeit. Die Abhängigkeit verlagert sich dann möglicherweise auf Cloud-Dienste, Kubernetes-Plattformen oder Kataloglösungen. Beide Ebenen sollten deshalb getrennt bewertet werden.
Wo ein zweites Spark-Ziel realistisch ist, sollte die Pipeline möglichst auf standardisierte SDP-Funktionen beschränkt bleiben. Wo Databricks langfristig die einzige Zielplattform ist, können die integrierten Lakeflow-Funktionen umfassend genutzt werden. Diese Trennung erhält zukünftige Handlungsmöglichkeiten und vermeidet eine Pipeline, die auf Standardisierung verzichtet, aber dennoch nicht konsequent die Vorteile der Databricks-Plattform nutzt.
Für jede Pipeline sollte geprüft werden, ob Portabilität einen konkreten zukünftigen Nutzen hat.
FAQ
Beide nutzen das gleiche deklarative Pipeline-Modell mit Tabellen-Definitionen, Erwartungen und automatischer Inkrementalität. Spark Declarative Pipelines ist die Apache-Spark-Open-Source-Variante, Lakeflow Declarative Pipelines ist die Databricks-Plattform-Variante mit managed Compute, Unity-Catalog-Lineage, Asset-Bundles-Deployment und Lakeflow-Jobs-Orchestrierung. Die Pipeline-Definition selbst ist portabel, das Betriebsmodell um sie herum ist es nicht.
