Wir geben die allgemeine Verfügbarkeit des Echtzeit-Modus für Spark Declarative Pipelines auf Databricks bekannt

Wir haben letztes Jahr Real-Time Mode (RTM) eingeführt, mit dem Kunden operative Anwendungsfälle mit geringer Latenz umsetzen können. Das war ein echter Meilenstein, da Streaming-Daten damit in Millisekunden verarbeitet werden können – bis zu 100-mal schneller als mit herkömmlichen Micro-Batch-Architekturen. Zudem müssen keine separaten, spezialisierten Engines wie Flink parallel zu Spark betrieben werden. Das beendet redundante Codebasen, fragmentierte Governance-Modelle und unnötigen Betriebsaufwand.

Ab heute ist RTM in Spark Declarative Pipelines (SDP) allgemein verfügbar. SDP hat sich zum Standard für Streaming- und ETL-Pipelines auf Databricks entwickelt und übernimmt automatisch die Auflösung von Abhängigkeiten, inkrementelle Verarbeitung, Orchestrierung, Fehlerorchestrierung und Dateneinhaltung. Mit RTM lassen sich operative Pipelines mit geringer Latenz erstellen, während alle diese SDP-Vorteile erhalten bleiben. Ob Betrugserkennung, Echtzeit-Benachrichtigungen oder das Bereitstellen aktueller Features für operative Stores – Sie können SDP jetzt für all diese Anwendungsfälle nutzen.

Was ist der Real-Time Mode (RTM)?

RTM ist eine Weiterentwicklung der Spark Structured Streaming-Engine, die Ende-zu-Ende-Latenzen im Millisekundenbereich erreicht. Dies gelingt durch kontinuierliches Streaming von Daten, die gleichzeitige Ausführung aller Abfragephasen und die sofortige Weitergabe von Daten zwischen den Phasen bei ihrer Erstellung. Einen tiefen Einblick in die Architektur finden Sie in dem Blogbeitrag „Breaking the microbatch barrier: The architecture of Apache Spark Real-Time Mode“.

RTM unterstützt Workloads, die von Datenentscheidungen in Millisekunden profitieren. Beispiele hierfür sind Betrugserkennung, Live-Personalisierung, Echtzeit-Empfehlungssysteme und die Echtzeit-Berechnung von Features. Wir haben RTM bei tatsächlichen Kunden-Workloads zur Feature-Berechnung mit Apache Flink verglichen; dabei zeigte sich, dass RTM bis zu 92 % schneller ist als spezialisierte Engines wie Flink. Die Benchmark-Ergebnisse sind unten dargestellt. Weitere Informationen zu den verwendeten Datensätzen und Abfragen finden Sie in diesem GitHub-Repository.

Warum RTM auf Spark Declarative Pipelines

Kunden setzen für ihre ETL-Workloads zunehmend standardmäßig auf SDP. Dank RTM unterstützt SDP nun sämtliche Streaming-Workloads, einschließlich operativem Low-Latency-Streaming, sodass Kunden ein einziges Framework für alle Pipelines nutzen können. Ein einziges Framework bedeutet eine einheitliche Beobachtbarkeit, ein Abrechnungsmodell und keine Fragmentierung über verschiedene APIs hinweg.

SDP Serverless geht noch einen Schritt weiter. Sie müssen weder Rechenleistung auswählen noch Cluster dimensionieren. Sie erhalten Latenzen im Subsekundenbereich ohne komplexe Infrastrukturanpassungen und zahlen nur für die Kerne, die Ihre Abfrage tatsächlich nutzt.  RTM-Abläufe profitieren zudem von SDP-Funktionen wie versionsfreien Upgrades und wartungsbedingten Ausfallzeiten, die sowohl den Betriebsaufwand als auch Störungen durch Upgrades minimieren.

Ein Anwendungsfall, in dem RTM auf SDP unmittelbare Wirkung zeigt, ist die Echtzeit-Berechnung von Features. ML-Modelle für Betrugserkennung oder Personalisierung basieren auf aktuellen Signalen wie dem Gesamttransaktionsvolumen eines Nutzers in den letzten 10 Minuten, um präzise Vorhersagen zu treffen. Die Berechnung dieser aggregierten Gleitfenster und deren Bereitstellung in einem Online-Store innerhalb von Millisekunden ist genau der Bereich, in dem RTM auf SDP die Lücke schließt. Der Databricks Feature Store nutzt genau diese Architektur, um eine Ende-zu-Ende-p99-Latenz von 200 ms von Kafka zum Online-Feature-Store zu ermöglichen.

Erste Schritte mit RTM auf SDP

Schritt 1: Konfiguration der Pipeline

Für den Real-Time Mode muss der Pipeline-Modus auf continuous und spark.databricks.streaming.realTimeMode.enabled eingestellt sein, woraufhin true übernimmt.

Schritt 2: Einen Echtzeit-Aktualisierungsablauf definieren

Der Echtzeitmodus erfordert einen Aktualisierungsablauf. Verwenden Sie dp.create_sink(), um das Ziel festzulegen, und nutzen Sie dann den @dp.update_flow-Dekorateur, wobei pipelines.trigger auf "RealTime" und target auf die Senke gerichtet ist.

Unterstützte Quellen und Senken finden Sie in der Dokumentation.

Schreiben von Features in eine benutzerdefinierte Senke

Anwendungsfälle wie Betrugserkennung oder Echtzeit-Personalisierung erfordern nicht nur die Echtzeit-Berechnung von Features, sondern auch deren Speicherung in einem abfragbaren Low-Latency-Store. Ein Betrugsmodell benötigt die jüngste Transaktion eines Kunden, bevor diese freigegeben wird, und eine Personalisierungs-Engine muss abrufen können, was ein Nutzer gerade angesehen hat.

Mit SDP können Sie Daten in benutzerdefinierte Senken wie Lakebase, Redis oder beliebige andere OLTP-Stores schreiben, indem Sie eine ForEach-Senke verwenden. Definieren Sie den Schreiber, registrieren Sie ihn als foreach_sink und verbinden Sie ihn mit einer update_flow.

Features landen innerhalb von Millisekunden nach ihrer Erstellung in Ihrem operativen Store, ohne dass eine Offline-Online-Synchronisierung dazwischengeschaltet ist. Anwendungen und Modelle können sie mit extrem geringer Latenz abfragen. 
Was sind die nächsten Schritte für RTM auf Serverless?

• Kosteneffizientere Ausführung von RTM-Pipelines: Fassen Sie mehrere RTM-Abläufe in einer einzigen Pipeline zusammen, anstatt für jede Abfrage eigene Ressourcen bereitzustellen. Zudem optimiert das System Quell- und Shuffle-Partitionen automatisch basierend auf dem Workload, sodass manuelle Anpassungen entfallen.
• Erweiterte Senkenunterstützung: Native Lakebase-Senke für SDP mit integriertem Batching, automatischen Wiederholungsversuchen und UC-verwalteter Authentifizierung.

Fazit

RTM erweitert Spark Declarative Pipelines um eine neue Klasse von Workloads: operative, latenzsensitive Anwendungen, die eine sofortige Reaktion auf Streaming-Daten erfordern. Da es Latenzen im Subsekundenbereich in die SDP-APIs bringt, die Ihr Team bereits nutzt, entfällt die Notwendigkeit, ein separates Framework oder eine eigene Engine für zeitkritische Pipelines zu betreiben. Ob Sie Pipelines zur Betrugserkennung, Personalisierungs-Engines oder ML-Feature-Berechnungssysteme entwickeln – der Real-Time Mode bietet Ihnen die von Ihrer Anwendung geforderte Latenz bei gleichzeitig einfacher Handhabung durch SDP.

Der Real-Time Mode in Spark Declarative Pipelines ist ab sofort allgemein verfügbar.

Technische Ressourcen

Nutzen Sie die folgenden Ressourcen für den Einstieg in RTM auf SDP:

• Dokumentation: Real-Time Mode auf Lakeflow-Pipelines verwenden
• Dokumentation: Verbindung mit Lakebase-Streaming-Senke herstellen
• Dokumentation: ForEach-Senke zum Schreiben einzelner Zeilen in Pipelines nutzen
• Code-Beispiele: Beispiele für den Real-Time Mode auf SDP

FAQ

Was ist der Real-Time Mode (RTM) in Spark Declarative Pipelines?

Der Real-Time Mode (RTM) ermöglicht es Spark Declarative Pipelines (SDP), Streaming-Daten mit Ende-zu-Ende-Latenzen im Millisekundenbereich zu verarbeiten. Er streamt Daten kontinuierlich, führt alle Abfragephasen gleichzeitig aus und leitet Daten direkt nach ihrer Erstellung zwischen den Phasen weiter. Echtzeit-Pipelines profitieren von der Orchestrierung und der automatischen Fehlerorchestrierung durch SDP.

Ist der Real-Time Mode in Spark Declarative Pipelines verfügbar?

Ja. Der Echtzeitmodus für Spark Declarative Pipelines ist jetzt allgemein verfügbar. Damit wird der bereits in Spark Structured Streaming verfügbare Echtzeitmodus in SDP-Pipelines integriert.

Wie aktiviere ich den Echtzeitmodus in einer Pipeline?

Stelle die Pipeline auf den Modus continuous und setze spark.databricks.streaming.realTimeMode.enabled auf true. Definiere dann einen Aktualisierungs-Flow, bei dem pipelines.trigger auf "RealTime" und ein Ziel, das auf eine Senke verweist, eingestellt ist.

Kann eine Echtzeit-Pipeline in Lakebase oder einen anderen OLTP-Datenspeicher schreiben?

Ja. Definiere eine ForEach-Senke mit einem Writer, der open, process und close implementiert, und verweise dann mit einem Echtzeit-Flow darauf. Dies funktioniert für Lakebase, Redis oder jeden anderen OLTP-Datenspeicher.

Für welche Anwendungsfälle ist der Echtzeitmodus in Spark Declarative Pipelines gedacht?

Der Echtzeitmodus wurde für operative Workloads entwickelt, die Streaming-Daten innerhalb von Millisekunden in Entscheidungen umwandeln. Beispiele hierfür sind Betrugserkennung, Live-Personalisierung, Echtzeit-Empfehlungen und die Berechnung von Features in Echtzeit. Der Databricks Feature Store nutzt diese Architektur, um eine p99-Latenz von 200 ms von Apache Kafka bis zum Online-Feature-Store zu erreichen.

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