Spark Declarative Pipelines

Spark Declarative Pipelines (SDP) sind ein Baukasten in Apache Spark (der verbreiteten Open-Source-Engine für verteilte Datenverarbeitung), mit dem eine Datenstrecke als Ergebnis beschrieben wird, statt Schritt für Schritt programmiert zu werden. Definiert werden in SQL oder Python nur die Zieltabellen (welche Daten am Ende stehen sollen), ihre Quellen und Qualitätsregeln (welche Zeilen gültig sind); die Engine plant daraus selbst die Reihenfolge, verarbeitet nur die neuen Daten, merkt sich den Fortschritt und startet nach Fehlern wieder an. Das Framework wurde 2025 aus Databricks Delta Live Tables (später Lakeflow Declarative Pipelines) in das Apache-Spark-Projekt (ab Spark 4.0/4.1) überführt und ist damit als Open-Source-Bestandteil von Spark verfügbar.

Was sind Spark Declarative Pipelines?

Spark Declarative Pipelines sind ein Framework (also ein festes Regelwerk mit fertigen Bausteinen) innerhalb von Apache Spark, das den deklarativen Ansatz für Datenpipelines (eine automatisierte Verarbeitungskette für Daten) in den Open-Source-Standard bringt. Deklarativ heißt: Beschrieben wird nur der Zielzustand: welche Tabellen am Ende entstehen, aus welchen Quellen sie abgeleitet werden, welche Spalten und Datentypen sie tragen (das Schema) und welche Qualitätsregeln gelten. Die Spark-Engine baut daraus selbst einen Abhängigkeitsgraphen (eine Landkarte, welche Tabelle auf welcher aufbaut), plant die Reihenfolge, merkt sich den Verarbeitungsfortschritt (sogenannte Checkpoints) und startet nach Fehlern automatisch wieder an. Der Anwendungscode kümmert sich um Transformation und Zielzustand, die Engine kümmert sich um Ablauf und Zustandshaltung.

Die Kernbausteine sind Tabellen-Definitionen, Expectations und Quellen. Tabellen werden in SQL über CREATE OR REFRESH STREAMING TABLE und CREATE OR REFRESH MATERIALIZED VIEW oder in Python über Decorator-basierte Definitionen deklariert. Expectations sind Datenqualitätsregeln direkt an der Tabellendefinition, zum Beispiel EXPECT ... ON VIOLATION DROP ROW oder FAIL UPDATE. Quellen sind Cloud-Storage-Pfade, Kafka-Topics, andere Pipeline-Tabellen oder externe Tabellen aus einem Katalog. Zwei Tabellentypen tragen das Modell: Streaming Tables für fortlaufend eintreffende, append-only Daten mit eigenem Lesefortschritt und Materialized Views für gespeicherte Abfrageergebnisse, die die Engine inkrementell aktualisiert, sobald sich die Eingaben ändern.

Historisch stammt das Modell aus Databricks: 2022 als Delta Live Tables (DLT) veröffentlicht, 2024/2025 als Bestandteil des Lakeflow-Stacks in Lakeflow Declarative Pipelines umbenannt. Im Juni 2025 hat Databricks das deklarative Modell über den Spark-Verbesserungsprozess in das Apache-Spark-Projekt überführt (Spark 4.0/4.1). Damit ist die Definitions-Sprache portabel und Bestandteil des Open-Source-Standards. Verwaltetes Compute, Deployment, automatische Lineage im Katalog und die grafische Pipeline-Oberfläche bleiben Bestandteile des Databricks-Produkts und sind kein Teil des Apache-Spark-Projekts.

Unter der Haube nutzt SDP die vorhandene Spark-Structured-Streaming-Mechanik: Micro-Batch-Verarbeitung, Checkpoints und Watermarks kommen aus der Streaming-Schicht. SDP verlagert diese Mechanik in die Engine und exponiert eine höhere Abstraktionsebene, auf der Pipelines als Tabellen und Constraints beschrieben werden statt als expliziter Query- und Checkpoint-Code.

Abgrenzung zu DLT, Structured Streaming, dbt und Airflow

Der Begriff wird häufig mit vier verwandten Konzepten vermengt, die im selben Data-Engineering-Stack sitzen, aber unterschiedliche Aufgaben lösen.

Die zentrale Verwechslung ist SDP versus Lakeflow Declarative Pipelines. Beide bezeichnen dasselbe deklarative Modell, unterscheiden sich aber im mitgelieferten Betrieb. SDP liefert das Framework, kein Betriebsmodell.

Beispiel: Medaillon-Pipeline in reinem Apache Spark

Eine typische Anwendung ist eine Medaillon-Architektur, die vollständig als deklarative Pipeline modelliert wird und auf einem Standard-Apache-Spark-4.1-Cluster läuft. Eine Bronze-Streaming-Table liest neue JSON-Dateien aus einem Cloud-Storage-Pfad; eine Expectation verwirft Zeilen ohne Pflichtfelder. Eine Silver-Streaming-Table typisiert und dedupliziert; eine weitere Expectation schlägt bei Verletzung der Referenzintegrität an. Eine Gold-Materialized-View aggregiert die Silver-Tabelle zu einem konsumfertigen Tages-Aggregat; die Engine aktualisiert die View inkrementell, sobald sich die Eingaben ändern.

-- Bronze
CREATE OR REFRESH STREAMING TABLE orders_bronze
COMMENT "Rohdaten aus dem Order-System"
AS SELECT * FROM STREAM read_files(
  's3://prod/raw/orders/',
  format => 'json'
);

-- Silver mit Expectation
CREATE OR REFRESH STREAMING TABLE orders_silver (
  CONSTRAINT valid_order_id EXPECT (order_id IS NOT NULL) ON VIOLATION DROP ROW
)
AS SELECT
  order_id,
  customer_id,
  CAST(order_date AS DATE) AS order_date,
  amount
FROM STREAM(orders_bronze);

-- Gold als Materialized View
CREATE OR REFRESH MATERIALIZED VIEW orders_gold
AS SELECT
  order_date,
  count(*)   AS order_count,
  sum(amount) AS revenue
FROM orders_silver
GROUP BY order_date;

Die drei Tabellen sind in einer Pipeline-Datei definiert. Die Engine löst die Abhängigkeiten aus den Referenzen (orders_bronze → orders_silver → orders_gold) automatisch auf, verwaltet Checkpoints und State, prüft die Expectations und erzeugt einen Ausführungs-Graphen. Ein externer Orchestrator wie Airflow startet die Pipeline zeitgesteuert oder ereignisbasiert. Was in reinem Apache Spark fehlt, sind die Databricks-eigenen Betriebsleistungen wie verwaltetes Compute, automatische Katalog-Lineage und die grafische Pipeline-Oberfläche.