Databricks macht Real-Time Mode für Spark Declarative Pipelines allgemein verfügbar
Databricks hat den Real-Time Mode (RTM) für Spark Declarative Pipelines (SDP) allgemein verfügbar gemacht. Damit erreicht das Framework, das laut Unternehmen der Standard für den Aufbau von Streaming- und ETL-Pipelines auf der Plattform ist, durchgängige Streaming-Latenzen im Millisekundenbereich. Nach Angaben des Unternehmens brauchen Teams für ihre zeitkritischsten Workloads keine separate Engine wie Apache Flink mehr.
- Databricks hat den Real-Time Mode (RTM) für Spark Declarative Pipelines allgemein verfügbar gemacht.
- RTM liefert laut Databricks durchgängige Latenzen im Millisekundenbereich.
- Nach Angaben des Unternehmens ist RTM bei Workloads zur Feature-Berechnung von Kunden bis zu 92 % schneller als Apache Flink.
- Der Databricks Feature Store nutzt die Architektur für eine p99-Latenz von 200 ms von Kafka bis zum Online Feature Store.
- Über ForEach-Sinks können Pipelines in Lakebase, Redis oder andere OLTP-Stores schreiben; ein nativer Lakebase-Sink ist geplant.
Was der Real-Time Mode leistet
Databricks beschreibt RTM als Weiterentwicklung der Engine von Spark Structured Streaming. Statt in Micro-Batches zu arbeiten, streamt RTM die Daten kontinuierlich, führt alle Abfragestufen gleichzeitig aus und reicht Daten zwischen den Stufen weiter, sobald sie entstehen. So werden durchgängige Latenzen im Millisekundenbereich erreicht.
Das Unternehmen hatte RTM im vergangenen Jahr für Spark Structured Streaming eingeführt. Nach eigenen Angaben konnten Kunden damit Streaming-Daten in Millisekunden verarbeiten, bis zu 100-mal schneller als mit der herkömmlichen Micro-Batch-Architektur, und mussten neben Spark keine spezialisierte Engine wie Flink mehr betreiben. Databricks zufolge entfielen dadurch doppelte Codebasen, fragmentierte Governance-Modelle und zusätzlicher Betriebsaufwand.
Die neue Ankündigung überträgt diese Fähigkeit auf SDP. Laut Databricks übernimmt SDP automatisch Abhängigkeitsauflösung, inkrementelle Verarbeitung, Orchestrierung, Fehlerwiederherstellung und die Durchsetzung von Datenqualität, und RTM-Pipelines behalten all diese Vorteile.
Benchmarks und der Anwendungsfall Feature-Berechnung
Databricks gibt an, RTM anhand realer Kunden-Workloads zur Feature-Berechnung mit Apache Flink verglichen zu haben. Demnach ist RTM bis zu 92 % schneller als spezialisierte Engines wie Flink. Datensätze und Abfragen sind in einem GitHub-Repository referenziert, das im Beitrag verlinkt ist.
Die Feature-Berechnung hebt das Unternehmen als Anwendungsfall besonders hervor. ML-Modelle für Betrugserkennung oder Personalisierung sind auf aktuelle Signale angewiesen, etwa auf die Summe der Transaktionsbeträge eines Nutzers in den vergangenen zehn Minuten. Databricks zufolge ist RTM auf SDP dafür ausgelegt, solche Rolling-Window-Aggregationen zu berechnen und binnen Millisekunden in einem Online-Store abzulegen. Der Databricks Feature Store nutzt nach Angaben des Unternehmens diese Architektur, um eine durchgängige p99-Latenz von 200 ms von Kafka bis zum Online Feature Store zu erreichen.
Als weitere Beispiel-Workloads nennt die Ankündigung Live-Personalisierung, Echtzeit-Empfehlungssysteme und Echtzeit-Alarmierung.
Einrichtung und benutzerdefinierte Sinks
Die Aktivierung von RTM erfolgt laut Beitrag in zwei Schritten. Zunächst muss der Pipeline-Modus auf continuous stehen und spark.databricks.streaming.realTimeMode.enabled auf true gesetzt sein. Anschließend definieren Nutzer einen Real-Time-Update-Flow: Sie erstellen das Ausgabeziel mit dp.create_sink() und verwenden dann den Decorator @dp.update_flow, wobei pipelines.trigger auf "RealTime" gesetzt wird und das Ziel auf den Sink verweist.
Über einen ForEach-Sink können Pipelines in beliebige benutzerdefinierte Sinks schreiben, darunter Lakebase, Redis oder jeden anderen OLTP-Store. Der Writer implementiert open, process und close, wird als foreach_sink registriert und mit einem update_flow verbunden. Databricks zufolge landen die Features dann binnen Millisekunden nach ihrer Erzeugung im operativen Store, ohne dazwischenliegende Synchronisierung von Offline- zu Online-Speicher.
Bei SDP Serverless muss laut Unternehmen weder Rechenleistung ausgewählt noch ein Cluster dimensioniert werden, und Kunden zahlen nur für die Kerne, die ihre Abfrage nutzt. Hinzu kommen für RTM-Flows versionslose Upgrades und Wartung mit geringen Ausfallzeiten.
Wie es weitergeht und warum das wichtig ist
Databricks nennt zwei geplante Verbesserungen für RTM auf Serverless. Die erste ist ein kostengünstigerer Betrieb, indem mehrere RTM-Flows per Bin-Packing in einer einzigen Pipeline gebündelt werden, wobei das System Quell- und Shuffle-Partitionen je nach Workload automatisch anpasst. Die zweite ist eine erweiterte Sink-Unterstützung, darunter ein nativer Lakebase-Sink für SDP mit integriertem Batching, automatischen Wiederholungsversuchen und UC-verwalteter Authentifizierung.
Für Datenteams, die SDP bereits einsetzen, lautet das Angebot des Unternehmens Konsolidierung: ein Framework, ein Observability-Stack, ein Abrechnungsmodell und keine Fragmentierung über verschiedene APIs hinweg. Halten die Leistungsangaben auch bei den eigenen Workloads eines Teams stand, könnten latenzkritische Pipelines wie Betrugs-Scoring und Feature Serving auf denselben APIs laufen wie der übrige ETL-Betrieb, statt auf einer separaten Engine.
