Deklarative Spark-Pipelines: Warum Data Engineering durchgängig deklarativ werden muss

Engineering-Teams stehen unter Druck, schneller qualitativ hochwertigere Daten zu liefern, aber die Arbeit des Erstellens und Betreibens von Pipelines wird immer schwieriger, nicht einfacher. Wir haben Hunderte von Dateningenieuren befragt, Millionen von realen Workloads untersucht und etwas Überraschendes herausgefunden: Dateningenieure verbringen den größten Teil ihrer Zeit nicht mit dem Schreiben von Code, sondern mit dem operativen Aufwand, der durch das Zusammenfügen von Tools entsteht. Der Grund dafür ist einfach: Bestehende Datentechnik-Frameworks zwingen Data Engineers dazu, Orchestrierung, inkrementelle Datenverarbeitung, Datenqualität und Backfills – alles gängige Tasks für Produktions-Pipelines – manuell zu erledigen. Mit wachsenden Datenmengen und Anwendungsfällen potenziert sich dieser operative Aufwand und macht die Data Engineering zu einem Engpass für das Unternehmen statt zu einem Beschleuniger.

Dies ist nicht das erste Mal, dass die Branche an ihre Grenzen stößt. Die frühe Datenverarbeitung erforderte für jede Abfrage das Schreiben eines neuen Programms, was nicht skalierbar war. SQL hat das geändert, indem es einzelne Abfragen deklarativ machte: Sie geben an, welches Ergebnis Sie wünschen, und die Engine ermittelt, wie es berechnet wird. SQL-Datenbanken bilden heute die Grundlage für jedes Unternehmen.

Aber beim Data Engineering geht es nicht darum, eine einzelne Abfrage auszuführen. Pipelines aktualisieren im Laufe der Zeit wiederholt mehrere voneinander abhängige Datasets. Da SQL-Engines an der Abfragegrenze enden, muss alles, was darüber hinausgeht – inkrementelle Verarbeitung, Abhängigkeitsmanagement, Backfills, Datenqualität, Wiederholungsversuche – immer noch manuell zusammengestellt werden. Bei Scale wird das Nachdenken über Ausführungsreihenfolge, Parallelität und Fehlermodi schnell zur Hauptquelle der Komplexität.

Was fehlt, ist eine Möglichkeit, die Pipeline als Ganzes zu deklarieren. Spark Declarative Pipelines (SDP) erweitern die deklarative Datenverarbeitung von einzelnen Abfragen auf ganze Pipelines und ermöglichen es Apache Spark, diese durchgängig zu planen und auszuführen. Anstatt Daten manuell zwischen Schritten zu verschieben, deklarieren Sie, welche Datasets vorhanden sein sollen, und SDP ist dafür verantwortlich, wie diese im Laufe der Zeit korrekt gehalten werden. In einer Pipeline, die beispielsweise wöchentliche Verkaufszahlen berechnet, leitet SDP Abhängigkeiten zwischen Datasets ab, erstellt einen einzigen Ausführungsplan und aktualisiert die Ergebnisse in der richtigen Reihenfolge. Es verarbeitet automatisch nur neue oder geänderte Daten, definiert Datenqualitätsregeln inline und verarbeitet Backfills sowie verspätet eintreffende Daten ohne manuellen Eingriff. Da SDP die Abfragesemantik versteht, kann es Pipelines im Voraus validieren, sicher parallel ausführen und nach Ausfällen korrekt wiederherstellen – Funktionen, die erstklassige, pipeline-fähige deklarative APIs erfordern, die direkt in Apache Spark integriert sind.

Durchgängiges deklaratives Data Engineering in SDP bringt erhebliche Vorteile mit sich:

• Höhere Produktivität: Data Engineers können sich auf das Schreiben von Geschäftslogik konzentrieren, anstatt auf Glue-Code.
• Geringere Kosten: Das Framework übernimmt automatisch die Orchestrierung und die inkrementelle Datenverarbeitung, wodurch es kosteneffizienter ist als manuell geschriebene Pipelines.
• Geringerer Betriebsaufwand: Häufige Anwendungsfälle wie Backfills, Datenqualität und Wiederholungsversuche sind integriert und automatisiert.

Um die Vorteile des durchgängigen deklarativen Daten-Engineerings zu veranschaulichen, lassen Sie uns mit einer wöchentlichen Vertriebspipeline starten, die in PySpark geschrieben ist. Da PySpark nicht durchgängig deklarativ ist, müssen wir die Ausführungsreihenfolge, die inkrementelle Verarbeitung und die Datenqualitätslogik manuell kodieren und uns für Wiederholungsversuche, Benachrichtigungen und das Monitoring auf einen externen Orchestrator wie Airflow verlassen (hier der Kürze halber weggelassen).

Diese als SQL-dbt-Projekt ausgedrückte Pipeline leidet unter vielen der gleichen Einschränkungen: Wir müssen die inkrementelle Datenverarbeitung immer noch manuell programmieren, die Datenqualität wird separat behandelt und für Wiederholungsversuche und die Fehlerbehandlung müssen wir uns immer noch auf einen Orchestrator wie Airflow verlassen:

Schreiben wir diese Pipeline in SDP neu, um ihre Vorteile zu erkunden. Installieren wir zunächst SDP und erstellen eine neue Pipeline:

Als Nächstes definieren Sie Ihre Pipeline mit dem folgenden Code. Beachten Sie, dass wir die API expect_or_drop für Datenqualitätserwartungen auskommentieren, da wir mit der Community zusammenarbeiten, um sie als Open Source zu veröffentlichen:

Um die Pipeline auszuführen, geben Sie den folgenden Befehl in Ihr Terminal ein:

Mit diesem Befehl können wir unsere Pipeline sogar vorab validieren, ohne sie vorher auszuführen – das ist praktisch, um Syntaxfehler und Schema-Nichtübereinstimmungen zu finden:

Backfills werden viel einfacher – um die Tabelle raw_sales nachträglich zu füllen, führen Sie diesen Befehl aus:

Der Code ist viel einfacher – nur 20 Zeilen, die alles leisten, wofür die PySpark- und dbt-Versionen externe Tools benötigen. Wir erhalten außerdem diese leistungsstarken Vorteile:

• Automatische inkrementelle Datenverarbeitung. Das Framework verfolgt, welche Daten verarbeitet wurden, und liest nur neue oder geänderte Datensätze. Keine MAX-Abfragen, keine Checkpoint-Dateien und keine bedingte Logik erforderlich.
• Integrierte Datenqualität. Der @dp.expect_or_drop -Decorator stellt fehlerhafte Datensätze automatisch unter Quarantäne. In PySpark haben wir gute/fehlerhafte Datensätze manuell aufgeteilt und in separate Tabellen geschrieben. In dbt benötigten wir ein separates Modell und eine manuelle Handhabung.
• Automatische Abhängigkeitsnachverfolgung. Das Framework erkennt, dass weekly_sales von raw_sales abhängt, und orchestriert die Ausführungsreihenfolge automatisch. Kein externer Orchestrator erforderlich.
• Integrierte Wiederholungsversuche und Monitoring. Das Framework behandelt Fehler und bietet Observability über eine integrierte Benutzeroberfläche. Keine externen Tools erforderlich.

SDP in Apache Spark 4.1 hat die folgenden Funktionen, die es zu einer großartigen Wahl für Datenpipelines machen:

• Python- und SQL-APIs zur Definition von Datasets
• Unterstützung für Batch- und Streaming-Abfragen
• Automatische Abhängigkeitsverfolgung zwischen Datasets und effiziente parallele Updates
• CLI zum Erstellen, Validieren und Ausführen von Pipelines, lokal oder in der Produktion

Wir freuen uns auf die Roadmap von SDP, die offen mit der Spark-Community entwickelt wird. Kommende Spark-Releases werden auf dieser Grundlage aufbauen und Unterstützung für eine kontinuierliche Ausführung sowie eine effizientere inkrementelle Verarbeitung bieten. Wir planen auch, Kernfunktionen wie Change Data Capture (CDC) in SDP zu integrieren, die durch Anwendungsfälle aus der Praxis und Community-Feedback gestaltet werden. Unser Ziel ist es, SDP zu einer gemeinsamen, erweiterbaren Grundlage für die Erstellung zuverlässiger Batch- und Streaming-Pipelines im gesamten Spark-Ökosystem zu machen.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag