Databricks Streaming: Real-Time Mode wird produktionsreif

Databricks Streaming rückt näher an operative Entscheidungen: Real-Time Mode ist für Spark Declarative Pipelines allgemein verfügbar. Damit lassen sich eingehende Ereignisse laut Databricks mit Verarbeitungslatenzen im Millisekundenbereich verarbeiten. Für Dich ist das vor allem dann interessant, wenn aktuelle Daten unmittelbar eine Aktion auslösen sollen – etwa eine Risikoprüfung im Bestellprozess. Wer bereits Azure Databricks nutzt, erhält damit einen Anlass, die Architektur zeitkritischer Datenflüsse neu zu bewerten.

Kurz gesagt: Databricks macht Real-Time Mode für Spark Declarative Pipelines allgemein verfügbar und verbindet damit deklarative Datenpipelines mit Streaming-Verarbeitung im Millisekundenbereich. Unternehmen können dadurch bestimmte zeitkritische Anwendungen auf derselben Plattform wie ihre übrige Datenverarbeitung betreiben. Ob eine zusätzliche Streaming-Engine entfallen kann, hängt allerdings von den benötigten Funktionen und der gemessenen Gesamtleistung ab.

Was ist neu bei Databricks Streaming?

Neu ist die allgemeine Verfügbarkeit von Real-Time Mode innerhalb der Spark Declarative Pipelines; die zugrunde liegende Betriebsart für Spark Structured Streaming gab es bereits zuvor.

Die Erweiterung bringt niedrige Latenzen in ein deklaratives Entwicklungsmodell: Dein Team beschreibt die Verarbeitung und ihre Abhängigkeiten, während die Plattform Aufgaben wie Orchestrierung, inkrementelle Verarbeitung, Fehlerwiederherstellung und Durchsetzung von Datenqualitätsregeln übernimmt. Diese Fähigkeiten stehen damit auch für die neuen zeitkritischen Datenflüsse bereit.

Kontinuierlich statt in kleinen Paketen

Klassisches Micro-Batching sammelt Ereignisse zunächst in kleinen Verarbeitungspaketen. Real-Time Mode verarbeitet Daten dagegen kontinuierlich, führt die Stufen einer Abfrage gleichzeitig aus und reicht Ergebnisse unmittelbar an die nächste Stufe weiter. Dadurch entfällt das Warten auf die nächste Micro-Batch-Verarbeitung.

Das ist eine technische Voraussetzung für kurze Reaktionszeiten, aber keine pauschale Latenzgarantie für Deine Anwendung. Netzwerkwege, Transformationen, Datenvolumen und Zielsystem beeinflussen weiterhin, wann ein Ergebnis tatsächlich nutzbar ist. Die Herstellerangabe „Millisekundenbereich“ solltest Du deshalb mit einem eigenen Lasttest überprüfen.

Für welche Mittelstandsunternehmen lohnt sich Real-Time Mode?

Real-Time Mode lohnt sich vor allem für Unternehmen, bei denen eine schnellere Verarbeitung von Ereignissen eine operative Entscheidung messbar verbessert und aktuelle Micro-Batch-Latenzen dafür nicht ausreichen.

Ein täglich aktualisierter Vertriebsbericht benötigt diese Betriebsart normalerweise nicht. Anders sieht es aus, wenn eine Anwendung auf einen gerade eintreffenden Vorgang reagieren muss. Denkbare Einsatzfelder sind:

• Risikoprüfung im digitalen Handel: Aktuelle Bestell- und Transaktionssignale fließen in die Bewertung eines laufenden Vorgangs ein.
• Personalisierung während einer Sitzung: Neue Interaktionen verändern unmittelbar die Datenbasis für Empfehlungen.
• Operative Warnmeldungen: Eingehende Ereignisse werden zeitnah ausgewertet und an ein nachgelagertes System übergeben.
• Aktuelle Merkmale für Machine Learning: Laufend berechnete Kennzahlen stehen einem Modell möglichst schnell zur Verfügung.

Die wirtschaftliche Leitfrage lautet nicht: „Wie schnell können wir werden?“ Sondern: „Welche Entscheidung fällt heute zu spät?“ Erst wenn Du diesen Zusammenhang benennen kannst, lässt sich der zusätzliche Betriebsaufwand sinnvoll bewerten.

Analytische Reaktionszeit ist keine Maschinensteuerung

Für Fertigungsunternehmen ist die Abgrenzung wichtig: Niedrige Streaming-Latenzen sind nicht gleichbedeutend mit garantierter harter Echtzeit. Eine cloudbasierte Datenpipeline ersetzt keine sicherheitskritische Maschinensteuerung. Ihr sinnvoller Einsatz liegt beispielsweise in der schnellen Auswertung von Zustandsereignissen und der Versorgung operativer Anwendungen.

Was verändert sich für Deine Architektur auf Azure?

Für Deine Azure-Architektur eröffnet Real-Time Mode die Möglichkeit, bestimmte latenzkritische Datenflüsse in die bestehende Databricks-Umgebung zu integrieren, statt dafür eine separate Verarbeitungsplattform zu betreiben.

Wer neben Apache Spark eine weitere Engine wie Apache Flink betreibt, muss häufig zusätzliche Fähigkeiten, Überwachung und Betriebsprozesse vorhalten. Eine Zusammenführung kann diese Komplexität reduzieren. Sie ist aber nur sinnvoll, wenn die benötigten Quellen, Transformationen und Ziele unterstützt werden. Allgemeine Verfügbarkeit bedeutet nicht automatisch, dass jede bestehende Streaming-Anwendung unverändert migriert werden kann.

Für Azure Databricks solltest Du deshalb vorab prüfen:

• Ist die benötigte Funktion im vorgesehenen Workspace und Bereitstellungsmodell verfügbar?
• Passen Netzwerkanbindung, Identitäten und Zugriffsrechte zu den beteiligten Systemen?
• Welche Quellen und Ziele unterstützt die aktuelle Dokumentation?
• Bleiben Datenverarbeitung und Speicherung innerhalb der vorgesehenen regionalen und organisatorischen Grenzen?

Bei personenbezogenen Ereignissen gehören außerdem Löschkonzepte, Datenminimierung und Zugriffssteuerung in die Architekturplanung. Kürzere Latenzen ändern nichts an diesen Anforderungen. Eine durchdachte Datenplattform verbindet deshalb Verarbeitungsgeschwindigkeit mit nachvollziehbaren Verantwortlichkeiten und Betriebsregeln.

Wie gelangen Ergebnisse in operative Anwendungen?

Ergebnisse lassen sich über ForEach sinks in operative Zielsysteme wie Lakebase oder Redis schreiben, damit Anwendungen und Modelle sie dort zeitnah abfragen können.

Das ist besonders für Machine Learning relevant: Ein frisch berechnetes Merkmal hilft wenig, wenn es anschließend auf einen separaten Synchronisationslauf warten muss. Die direkte Ausgabe kann diesen Zwischenschritt vermeiden. Allerdings bleibt die Schreibgeschwindigkeit des Zielsystems ein möglicher Engpass.

Ein eigener Writer benötigt deshalb mehr als eine funktionierende Verbindung. Dein Team sollte Wiederholungsversuche, doppelte Schreibvorgänge, Zugangsdaten und das Verhalten bei Ausfällen ausdrücklich behandeln. Aus einer niedrigen Verarbeitungslatenz folgt nicht automatisch eine bestimmte Zustellgarantie im Zielsystem.

Falls Apache Kafka die Ereignisse liefert, gehört auch die vorgelagerte Strecke in die Bewertung. Datenqualität, Ereignisschlüssel und Partitionierung beeinflussen die nachfolgende Verarbeitung. Unsere Einordnung zu Streaming mit Kafka hilft Dir, diese Architekturentscheidungen im Zusammenhang zu betrachten.

So planst Du einen belastbaren Einstieg

Beginne mit einem klar abgegrenzten Datenfluss und einem fachlich begründeten Latenzziel. Eine vollständige Umstellung Deiner Streaming-Landschaft ist für die Bewertung nicht nötig.

Technische Voraussetzungen klären

Die Ankündigung nennt folgende Schritte für die Aktivierung:

• Die Pipeline läuft im kontinuierlichen Modus.
• spark.databricks.streaming.realTimeMode.enabled wird auf true gesetzt.
• Das Ausgabeziel wird mit dp.create_sink() definiert.
• Ein Update Flow verwendet @dp.update_flow, verweist auf den Sink und setzt pipelines.trigger auf "RealTime".

Diese Konfiguration ersetzt keine Kompatibilitätsprüfung. Maßgeblich bleiben die dokumentierten Einschränkungen der verwendeten Quellen, Verarbeitungsschritte und Ziele.

Nutzen und Betrieb gemeinsam messen

Miss die gesamte Strecke vom eingehenden Ereignis bis zum abfragbaren Ergebnis. Betrachte nicht nur Durchschnittswerte, sondern auch seltene Verzögerungen, Lastspitzen und die Erholung nach Ausfällen. Vergleiche zusätzlich die laufenden Kosten mit einer Micro-Batch-Alternative.

Databricks beschreibt für SDP serverless einen Betrieb ohne manuelle Cluster-Dimensionierung. Weitere Verbesserungen, darunter die gemeinsame Ressourcennutzung mehrerer RTM-Flows und ein nativer Lakebase sink, werden in der Ankündigung als nächste Schritte aufgeführt. Plane solche angekündigten Funktionen erst ein, wenn ihre Verfügbarkeit für Deine Umgebung bestätigt ist.

Was das für dich bedeutet

Real-Time Mode erweitert den Einsatzbereich von Spark Declarative Pipelines: Neben klassischen Datenpipelines kommen zeitkritische operative Anwendungen stärker infrage. Für Deinen Mittelstand liegt der mögliche Gewinn in schnelleren Entscheidungen und weniger parallelen Verarbeitungssystemen – nicht in Millisekunden als Selbstzweck.

Du möchtest prüfen, welcher Datenfluss dafür geeignet ist? Mit unserer Databricks Beratung unterstützen wir Dich dabei, Anforderungen, Architektur und einen belastbaren Pilotbetrieb aufeinander abzustimmen.

Redaktionelle Einordnung auf Basis eines Beitrags im Databricks-Blog.