Databricks Streaming: Real-Time Mode verändert die Engine-Wahl

Wer Streaming-Daten schnell verarbeiten möchte, muss nicht automatisch eine zusätzliche Engine einführen. Für Databricks Streaming rückt mit Real-Time Mode eine neue Option in den Vordergrund: Apache Spark kann damit auch Verarbeitungslatenzen im Millisekundenbereich erreichen. Für mittelständische Unternehmen mit Azure und Databricks verändert das die Architekturentscheidung. Statt grundsätzlich zwischen einer Analyseplattform und einer separaten Streaming-Umgebung aufzuteilen, lohnt sich zuerst die Frage: Welche Anforderungen kann die bestehende Plattform zuverlässig abdecken?

Kurz gesagt: Databricks stellt Real-Time Mode einschließlich zustandsbehafteter Verarbeitung als allgemein verfügbare Funktion bereit. In einem herstellereigenen Benchmark erreichte Spark damit bei ausgewählten Aufgaben vergleichbare oder niedrigere p99-Latenzen als Apache Flink. Das macht Spark für zeitkritische Datenpipelines interessanter, ersetzt aber weder einen eigenen Belastungstest noch die Prüfung spezieller Flink-Funktionen.

Was ist neu an Databricks Streaming mit Real-Time Mode?

Real-Time Mode ergänzt Spark Structured Streaming um einen Ausführungsmodus, der Ereignisse kontinuierlich statt in kleinen Verarbeitungspaketen verarbeitet und damit Millisekunden-Latenzen ermöglicht. Die bisher verbreitete Gleichsetzung „Spark bedeutet Micro-Batch, niedrige Latenz verlangt Flink“ greift deshalb zu kurz.

Die technische Grundlage bleibt Structured Streaming. Der Modus wird über den Trigger einer Abfrage gewählt. Bestehende DataFrame- und SQL-Logik lässt sich dadurch grundsätzlich weiterverwenden, soweit die benötigten Operationen und Ein- und Ausgaben unterstützt werden. Eine vollständige Neuentwicklung ist also nicht zwangsläufig erforderlich.

Wichtig ist die Trennung zwischen Apache Spark als Open-Source-Projekt und der Databricks-Plattform: Laut Databricks sind zustandsbehaftete Operatoren dort bereits allgemein verfügbar; für Open Source nennt der Anbieter Apache Spark 4.3. Aus der Verfügbarkeit auf Databricks folgt deshalb nicht automatisch dieselbe Unterstützung in jeder Spark-Installation.

Nicht jede Pipeline lässt sich einfach umschalten

Real-Time Mode verlangt laut Anbieter den Ausgabemodus update. Als Quelle wird Kafka unterstützt; als Ausgabe kommen Kafka oder ein zeilenbasierter foreach-Sink infrage. Auf Databricks nennt der Beitrag Classic Compute und Lakeflow Spark Declarative Pipelines als Ausführungswege.

Für Deine Planung bedeutet das: Prüfe die konkrete Runtime, Operatoren und Schnittstellen, bevor Du einen Wechsel zusagst. Gerade eine Pipeline, die direkt in eine Lakehouse-Tabelle schreiben soll, darf nicht allein aufgrund des neuen Triggers als unverändert kompatibel gelten.

Wie aussagekräftig sind die Latenzwerte gegenüber Apache Flink?

Die veröffentlichten Werte belegen niedrige Latenzen für drei getestete Verarbeitungstypen, aber keinen allgemeinen Geschwindigkeitsvorsprung von Spark gegenüber Flink. Databricks maß bei 10.000 Datensätzen pro Sekunde über 30 Minuten die Zeit vom Kafka-Eingang bis zum Kafka-Ausgang.

Die p99-Latenz beschreibt den Wert, den 99 Prozent der gemessenen Ereignisse nicht überschreiten. Im Test ergaben sich:

• Transformation ohne Zustand: jeweils 3 Millisekunden für Spark Real-Time Mode und Flink.
• Zustandsbehaftete Aggregation: 14 Millisekunden für Spark gegenüber 45 Millisekunden für Flink.
• Verknüpfung eines Streams mit statischen Daten: 9 Millisekunden für Spark gegenüber 95 Millisekunden für Flink.

Die Einordnung ist entscheidend: Spark lief auf Databricks, Flink auf AWS Managed Service for Apache Flink in Version 1.18. Verglichen wurden der schlechteste Spark-Durchlauf und der beste Flink-Durchlauf. Es handelt sich dennoch um einen Herstellerbenchmark mit bestimmten Aufgaben und unterschiedlichen Betriebsumgebungen, nicht um einen neutralen Vergleich sämtlicher aktueller Konfigurationen.

Für eine Azure-Architektur sind diese Ergebnisse daher ein Prüfauftrag, keine Leistungszusage. Netzwerkwege, Ereignisgrößen, Datenverteilung, Zustand und Zielsystem beeinflussen Deine tatsächliche Latenz. Außerdem endet die Messung hier am Kafka-Ausgang: Die Zeit bis zur sichtbaren Reaktion in einer Fachanwendung kann länger sein.

Wann bleibt Apache Flink die passendere Wahl?

Apache Flink bleibt besonders dann relevant, wenn sehr große schlüsselbezogene Zustände, komplexe Ereignismuster oder Event-Time-Timer den Kern der Anwendung bilden. Auch eine bereits gut betriebene Flink-Plattform ist ein sachlicher Grund, nicht allein wegen eines neuen Benchmarks zu wechseln.

Für die Auswahl solltest Du insbesondere diese Anforderungen abgleichen:

• Sehr großer Zustand: Flink 2.x unterstützt entkoppelte Zustandsspeicherung mit ForSt, ausgelegt auch auf Zustände jenseits der lokalen Festplattenkapazität.
• Komplexe Ereignisfolgen: Flink bietet eine CEP-Bibliothek sowie SQL MATCH_RECOGNIZE, um Muster über mehrere Ereignisse zu erkennen.
• Zeitsteuerung anhand der Ereigniszeit: Event-Time-Timer werden laut Beitrag in Spark Real-Time Mode bei transformWithState noch nicht unterstützt.
• Vorhandene Betriebsfähigkeiten: Ein eingespieltes Flink-Team mit stabilen Prozessen muss den Nutzen einer Migration gegen Aufwand und Risiken abwägen.

Ein möglicher Anwendungsfall wäre die Erkennung einer bestimmten Reihenfolge von Maschinenereignissen innerhalb fachlicher Zeitfenster. Hier zählt nicht nur, wie schnell ein einzelnes Ereignis verarbeitet wird, sondern ob sich die gewünschte Zeit- und Musterlogik zuverlässig ausdrücken lässt.

Was heißt das für Unternehmen mit Azure und Databricks?

Für Unternehmen mit bestehender Azure-Databricks-Umgebung wird es attraktiver, zusätzliche Streaming-Anforderungen zunächst innerhalb ihrer vorhandenen Plattform zu prüfen. Der mögliche Vorteil liegt nicht nur in der Laufzeit, sondern auch in weniger parallelen Entwicklungs- und Betriebsprozessen.

Wenn Dein Team bereits Python, SQL und Spark nutzt, kann es auf vorhandenen Kenntnissen aufbauen. Gemeinsame Datenbestände und die Governance über Unity Catalog können zudem helfen, Zugriffe und Datenherkunft konsistenter zu organisieren. Das entbindet Dich allerdings nicht davon, Kafka, externe Zielsysteme und deren Berechtigungen separat einzubeziehen.

Die fachliche Reaktionszeit entscheidet

Ein Produktionsdashboard zur Schichtauswertung benötigt andere Aktualisierungsintervalle als eine Anwendung, die unmittelbar auf ein Ereignis reagieren soll. „Echtzeit“ ist deshalb noch keine belastbare Anforderung.

Definiere zuerst, wann die Information tatsächlich benötigt wird: am Ausgang der Datenpipeline, in einer API oder sichtbar im Fachsystem. Wenn Sekunden fachlich ausreichen, kann Micro-Batch weiterhin die passende Lösung sein. Millisekunden sind kein Selbstzweck und garantieren keine niedrigeren Betriebskosten.

Diese Abwägung gehört in die Architektur Deiner Datenplattform. Wenn Kafka die Ereignisse transportiert, sollten außerdem Partitionierung, Aufbewahrung und Wiederverarbeitung Teil der Planung sein. Dafür ist die Perspektive auf Streaming mit Kafka genauso wichtig wie die Auswahl der Verarbeitungsengine.

So prüfst Du die Entscheidung vor dem produktiven Einsatz

Ein begrenzter Praxistest liefert mehr Entscheidungssicherheit als ein isolierter Vergleich von Spitzenwerten:

1. Ziel festlegen: Definiere fachliche Reaktionszeit, erwartetes Datenvolumen und zulässige Verzögerungen bei Lastspitzen.
2. Kompatibilität prüfen: Gleiche Quellen, Senken, Zustandsoperationen und Timer mit der Unterstützung des gewählten Betriebsmodus ab.
3. Realistisch messen: Nutze repräsentative Ereignisse, ungleich verteilte Schlüssel und verspätet eintreffende Daten. Miss auch p99 statt nur Durchschnittswerte.
4. Störungen testen: Prüfe Neustarts, Wiederanlauf, Rückstau und das Verhalten des Zielsystems bei Wiederholungen.
5. Gesamtaufwand vergleichen: Bewerte Infrastrukturkosten, Bereitschaftsdienst, Qualifizierung und zusätzliche Governance-Aufgaben zusammen.

Was das für dich bedeutet

Real-Time Mode ist ein guter Anlass, die Engine-Auswahl neu zu bewerten – nicht, funktionierende Flink-Anwendungen pauschal abzulösen. Wenn Du bereits Databricks betreibst, sollte Spark bei niedrigen Latenzanforderungen mit auf die Prüfliste. Entscheidend bleiben die unterstützte Fachlogik, die gemessene Reaktionszeit und ein beherrschbarer Betrieb.

Du möchtest klären, welche Engine zu Deiner Azure-Datenplattform passt? Mit unserer Databricks Beratung unterstützen wir Dich bei Architekturentscheidung und technischer Validierung.

Redaktionelle Einordnung auf Basis eines Beitrags im Databricks-Blog.