Declarative Pipelines

Declarative Pipelines ist ein Bauprinzip für Datenpipelines (Verarbeitungsstrecken, die Rohdaten in ausgewertete Tabellen verwandeln), bei dem nur das Ziel beschrieben wird: welche Tabellen entstehen sollen, woher ihre Daten kommen und welche Qualitätsregeln gelten, nicht die Reihenfolge der einzelnen Verarbeitungsschritte. Die Plattform (die Runtime) plant daraus selbst, in welcher Abfolge die Tabellen gebaut werden, verarbeitet nur die neuen Datensätze, startet nach Fehlern automatisch neu und dokumentiert die Herkunft jeder Spalte (Lineage). Die bekannteste Umsetzung sind Lakeflow Declarative Pipelines auf Databricks (früher Delta Live Tables, kurz DLT); seit 2025 ist das Modell mit Spark Declarative Pipelines auch im Open-Source-Projekt Apache Spark verfügbar.

Was sind Declarative Pipelines?

Declarative Pipelines beschreiben, wie die Zieltabellen am Ende aussehen sollen: welche Tabelle aus welcher Quelle entsteht, welche Spalten und Datentypen sie hat, welche Qualitätsregeln gelten (etwa „Kundennummer darf nicht leer sein") und wie sie mit anderen Tabellen zusammenhängt. Aus diesen Beschreibungen leitet die Plattform selbst ab, welche Tabelle zuerst gebaut werden muss, welche danach folgt und wo Zwischenstände gespeichert werden müssen, damit die Pipeline nach einem Fehler nicht komplett von vorn starten muss. Der geschriebene Code kümmert sich um die eigentliche Umwandlung der Daten, alles andere übernimmt die Plattform.

Die Kernbausteine sind Tabellen-Definitionen, Expectations und Quellen. Tabellen werden in Python über den @dlt.table-Decorator oder in SQL über CREATE OR REFRESH STREAMING TABLE und CREATE OR REFRESH MATERIALIZED VIEW deklariert. Expectations sind Datenqualitätsregeln direkt an der Tabellendefinition, zum Beispiel EXPECT ... ON VIOLATION FAIL UPDATE oder DROP ROW. Quellen sind Cloud-Storage-Pfade (typisch über Auto Loader), Kafka-Topics, andere Pipeline-Tabellen oder Unity-Catalog-Tabellen. Die Runtime löst Abhängigkeiten aus den Tabellen-Referenzen im Code auf und benötigt keine explizite Reihenfolge-Angabe.

Zwei Tabellentypen tragen das Modell: Streaming Tables für fortlaufend eintreffende, append-only Daten mit eigenem Lesefortschritt (typisch für Bronze- und Silver-Ebenen) und Materialized Views für gespeicherte Abfrageergebnisse, die die Runtime inkrementell aktualisiert, sobald sich die Eingaben ändern (typisch für Gold-Aggregate). Die Wahl des Tabellentyps entscheidet über Verarbeitungsart und Kostenlogik.

Historisch: Databricks hat das Framework 2022 als Delta Live Tables (DLT) veröffentlicht. Mit dem Rebranding 2024/2025 heißt die Komponente Lakeflow Declarative Pipelines und ist Teil des Lakeflow-Stacks (Lakeflow Connect für Ingestion, Lakeflow Declarative Pipelines für Transformation, Lakeflow Jobs für Orchestrierung). Der Python-Namespace @dlt und die SQL-Syntax blieben unverändert; bestehende DLT-Pipelines laufen unter dem neuen Namen weiter. Im Juni 2025 hat Databricks das deklarative Modell als [Spark Declarative Pipelines](https://spark.apache.org/news/spark-4-1-released.html) an Apache Spark übergeben (Spark 4.1+). Die Definitions-Sprache ist damit portabel, Betrieb und Lineage bleiben plattform-spezifisch.

Abgrenzung zu Nachbar-Konzepten

Das deklarative Modell wird häufig mit anderen Bausteinen im Data-Engineering-Stack vermengt. Die folgende Tabelle klärt die vier häufigsten Verwechslungen.

Beispiel: Bronze-Silver-Gold als deklarative Pipeline

Eine typische Anwendung ist eine Medaillon-Architektur auf Databricks, komplett als deklarative Pipeline modelliert. Eine Bronze-Streaming-Table liest neue JSON-Dateien aus einem Cloud-Storage-Pfad über Auto Loader; eine Expectation verwirft Zeilen ohne Pflichtfelder. Eine Silver-Streaming-Table wendet Typisierung, Deduplizierung und Business-Regeln an; eine weitere Expectation schlägt bei Verletzung der Referenzintegrität an. Eine Gold-Materialized-View aggregiert die Silver-Tabelle zu einem konsumfertigen Star-Schema; die Runtime aktualisiert die View inkrementell, sobald sich die Silver-Tabelle ändert.

-- Bronze
CREATE OR REFRESH STREAMING TABLE orders_bronze
COMMENT "Rohdaten aus dem Order-System, Auto-Loader-Ingest"
AS SELECT * FROM STREAM read_files(
  '/Volumes/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;

Alle drei Tabellen sind in einer Pipeline-Datei definiert. Die Runtime löst die Abhängigkeiten aus den Referenzen (orders_bronze → orders_silver → orders_gold) auf, verwaltet Checkpoints und State, prüft die Expectations und erzeugt die technische Lineage im Unity Catalog. Ein Lakeflow-Job oder ein Airflow-DAG startet die Pipeline zeitgesteuert oder ereignisbasiert; die Wiederherstellung nach Fehlern läuft ohne manuelles Leeren und Neuladen der Tabellen ab.