Databricks Streaming: Was Apache Spark 4.3 im Alltag verändert

Aktuelle Maschinendaten auswerten, frühere Stammdatenstände nachvollziehen und Transformationen schneller testen: Apache Spark 4.3 adressiert drei Aufgaben, die viele Datenteams im Mittelstand beschäftigen. Die Version ist in Databricks Runtime 19 verfügbar. Für Databricks Streaming ist besonders relevant, dass Real-Time Mode jetzt auch Informationen über mehrere Ereignisse hinweg behalten und verarbeiten kann. Für dich als Entscheiderin oder Entscheider stellt sich damit die Frage: Wo vereinfacht das die bestehende Architektur – und wo bleibt ein Update zunächst nur technischer Fortschritt?

Kurz gesagt: Apache Spark 4.3 erweitert Real-Time Mode um zustandsbehaftete Verarbeitung und ergänzt Open-Source Auto CDC um SCD Type 2 für Änderungshistorien. Project Feather reduziert bei geeigneten kleinen Abfragen den Ausführungsaufwand. Unternehmen auf Azure Databricks können damit prüfen, ob sie zeitkritische Verarbeitung, historische Auswertungen und Entwicklungsschleifen stärker auf derselben Plattform bündeln können.

Was ist neu bei Databricks Streaming mit Apache Spark 4.3?

Apache Spark 4.3 unterstützt in Real-Time Mode jetzt Streaming-Aggregationen, die Entfernung von Duplikaten mit dropDuplicates und individuelle zustandsbehaftete Verarbeitung mit transformWithState in Scala und Java.

Der Unterschied liegt im Gedächtnis der Verarbeitung: Ein einzelner Messwert sagt oft wenig aus. Erst zusammen mit vorherigen Werten entsteht ein aussagekräftiger Zustand, etwa ein laufender Zähler je Maschine oder eine Zusammenfassung innerhalb eines Zeitfensters. Solche Aufgaben lassen sich nun im latenzarmen Ausführungsmodus von Structured Streaming umsetzen.

Das bestehende Programmiermodell bleibt erhalten. Auch die Mechanismen für State Store und Checkpointing werden weiterverwendet. Dein Team muss deshalb nicht allein wegen niedrigerer Latenzen auf eine andere Streaming Engine wechseln – sofern die benötigten Funktionen und Betriebsanforderungen abgedeckt sind.

Niedrige Latenz braucht passende Ressourcen

Für drei getestete zustandsbehaftete Workloads nennt Databricks P99-Ende-zu-Ende-Latenzen unter 150 Millisekunden. P99 bezeichnet die Grenze, die 99 Prozent der gemessenen Latenzen nicht überschreiten. Diese Ergebnisse sind jedoch keine Zusage für deine produktive Pipeline.

Technisch ermöglicht Spark den kontinuierlichen Datenaustausch zwischen gleichzeitig laufenden Verarbeitungsstufen. Dafür müssen genügend Task-Slots für die zusammengehörigen Tasks verfügbar sein. Reichen die Ressourcen nicht aus, startet die Gruppe nicht; Spark bricht frühzeitig ab, statt unbegrenzt zu warten.

Für Azure Databricks heißt das: Niedrige Latenz ist nicht nur eine Codefrage, sondern auch eine Frage der Kapazitätsplanung. Prüfe mindestens:

• Wie groß wird der gespeicherte Zustand je Schlüssel?
• Wie ungleich verteilen sich Ereignisse auf Maschinen, Artikel oder Aufträge?
• Welche Lastspitzen muss die Pipeline verkraften?
• Wie verhalten sich Wiederanlauf und Wiederherstellung nach Fehlern?

Wann lohnt sich Real-Time Mode für den Mittelstand?

Real-Time Mode lohnt sich für unterstützte Anwendungen, bei denen Ereignisse mit gespeichertem Kontext verarbeitet werden müssen und eine Reaktion im Millisekundenbereich fachlich notwendig ist.

Ein denkbarer Einsatz ist die Überwachung von Anlagenzuständen: Einzelne Sensormeldungen werden fortlaufend zu einem aktuellen Bild je Anlage zusammengeführt. Auch die Bereinigung doppelt eintreffender Ereignisse kann relevant sein, bevor nachgelagerte Anwendungen damit arbeiten. Das sind mögliche Anwendungsmuster, keine Aussage über garantierte Reaktionszeiten.

Nicht jede Auswertung braucht diese Geschwindigkeit. Wenn ein Bericht stündlich aktualisiert wird, ist eine extrem niedrige Verarbeitungslatenz meist kein ausreichender Grund für einen Architekturwechsel. Entscheidend ist die Zeit zwischen einem Ereignis und einer tatsächlich hilfreichen Handlung.

Wer bereits Kafka nutzt, sollte zudem Ereignistransport und Verarbeitung auseinanderhalten. Spark verarbeitet die Daten; damit entfällt nicht automatisch die Rolle einer Ereignisplattform. Bei der Planung von Streaming mit Kafka gehören deshalb Datenaufbewahrung, erneutes Einlesen und die Anforderungen weiterer Datenabnehmer weiterhin auf die Agenda.

Wie verbessert SCD Type 2 historische Auswertungen?

SCD Type 2 in Open-Source Auto CDC ermöglicht es, Änderungen an Datensätzen als Historie zu erhalten, statt ausschließlich den jeweils aktuellen Zustand abzubilden.

Apache Spark 4.3 stellt diese Unterstützung über Python, SQL und Spark Connect bereit. Änderungen können automatisiert angewendet werden; selbst entwickelte Logik für manuelle Merge-Vorgänge lässt sich dadurch reduzieren.

Für einen mittelständischen Betrieb ist das beispielsweise bei Vertriebsgebieten relevant. Wird ein Kunde heute einer anderen Region zugeordnet, darf das nicht ungeprüft die Auswertung eines früheren Geschäftsjahres verändern. Eine historisierte Dimension schafft die Grundlage, Aufträge mit dem damals gültigen Stammdatenstand zu betrachten.

Historisierung ersetzt keine fachlichen Regeln

Die technische Funktion entscheidet allerdings nicht, welche Historie dein Unternehmen benötigt. Vor der Umsetzung solltest du mit Fachbereich und Datenteam klären:

• Welche Attribute sollen historisiert werden?
• Welcher Zeitpunkt bestimmt die fachliche Gültigkeit?
• Wie werden verspätete Änderungen und Korrekturen behandelt?
• Welche Zugriffs-, Lösch- und Aufbewahrungsregeln gelten?

Gerade bei personenbezogenen Daten ist mehr Historie nicht automatisch besser. SCD Type 2 unterstützt nachvollziehbare Auswertungen, stellt aber allein weder Revisionssicherheit noch Datenschutzkonformität her. Diese Anforderungen gehören in die Konzeption deiner Datenplattform.

Kleine Datenmengen: weniger Wartezeit bei der Entwicklung

Mit Project Feather adressiert Spark 4.3 ein alltägliches Problem: Bei kleinen Testdaten kann die Organisation der Ausführung mehr Aufwand verursachen als die eigentliche Berechnung. Das bremst kurze Schleifen aus Programmieren, Ausführen und Prüfen.

Für geeignete kleine Abfrageabschnitte mit einer einzigen Partition bietet Spark eine optional aktivierbare Ausführung als einzelner Task ohne Shuffle. Unterstützte Operationen können dadurch eine unnötige Datenumverteilung vermeiden. Das betrifft ausgewählte Abfrageformen, nicht beliebige Spark-Jobs.

Hinzu kommt optionales Arrow-native Dataset caching. Dabei werden zwischengespeicherte Datenblöcke im Arrow-Format abgelegt. Für passende Eingaben können dadurch Formatkonvertierungen entfallen, etwa wenn Entwicklerinnen und Entwickler dieselben Daten wiederholt untersuchen.

Die praktische Einordnung: Feather ist vor allem für explorative Arbeit und Tests auf kleinen Ausschnitten interessant. Auch KI-generierter Transformationscode lässt sich so auf geeigneten Testdaten zügiger überprüfen. Daraus folgt aber keine pauschale Beschleunigung großer produktiver Datenverarbeitungen. Beide Funktionen müssen bewusst aktiviert und mit den eigenen Abfragen geprüft werden.

So bewertest du das Update auf Azure Databricks

Beginne nicht mit einer flächendeckenden Migration, sondern mit einem abgegrenzten Test. Ein sinnvoller Ablauf besteht aus vier Schritten:

1. Anwendungsfall auswählen: Nimm eine Pipeline mit messbarem Bedarf an niedriger Latenz, Historisierung oder kürzeren Entwicklungsschleifen.
2. Ausgangszustand erfassen: Dokumentiere Laufzeiten, Ressourcenbedarf, Kosten und Ergebnisqualität der bisherigen Lösung.
3. Kompatibilität und Betrieb prüfen: Teste Bibliotheken, Konfigurationen, Wiederherstellung und Verhalten unter Last mit Databricks Runtime 19.
4. Nutzen vergleichen: Entscheide anhand fachlicher Verbesserungen und Betriebsaufwand, nicht allein anhand eines Benchmarks.

Mit Spark 4.3 beginnt außerdem ein vierteljährlicher Feature-Release-Zyklus statt des bisherigen halbjährlichen Rhythmus. Für dein Team macht das einen geregelten Prüf- und Freigabeprozess wichtiger. Häufigere Neuerungen bedeuten nicht, dass jede Version sofort produktiv eingesetzt werden muss.

Was das für dich bedeutet

Apache Spark 4.3 erweitert die Möglichkeiten einer gemeinsamen Plattform für Streaming, historische Daten und Entwicklung. Der größte Nutzen entsteht dort, wo eine konkrete Engstelle wegfällt: fehlender Kontext in Echtzeit, aufwendige Historisierungslogik oder unnötige Wartezeit bei kleinen Tests.

Du möchtest herausfinden, welche Neuerung zu deiner Azure-Databricks-Umgebung passt? Als Databricks-Partner unterstützt Ailio dich bei Architekturentscheidungen und der technischen Bewertung. Sprich mit uns über deine Databricks-Roadmap.

Redaktionelle Aufbereitung und Einordnung auf Basis eines Beitrags im Databricks-Blog.