Databricks führt bedarfsgesteuertes Repartitioning des State für Spark Structured Streaming ein

Databricks hat On-Demand State Repartitioning für Apache Spark Structured Streaming vorgestellt, eine Funktion in der Public Preview, mit der Ingenieure die Anzahl der Partitionen einer zustandsbehafteten Streaming-Abfrage ändern können, ohne den Checkpoint neu aufzubauen oder den angesammelten Zustand zu verlieren. Die Funktion ist ab Databricks Runtime 18 verfügbar.

Was sich ändert

Laut Databricks war die Anzahl der Partitionen bei zustandsbehafteten Streaming-Abfragen bislang bereits mit der Erstellung des Checkpoints festgelegt. Eine Änderung der Standardeinstellung spark.sql.shuffle.partitions und ein Neustart der Abfrage blieben wirkungslos, da das Partitionslayout fest in den Checkpoint eingebettet war. Die einzige bisherige Option, so Databricks, bestand darin, den Checkpoint zu verwerfen und neu zu beginnen – wodurch der gesamte von der Abfrage aufgebaute Zustand verloren ging, etwa Betrugserkennungsdaten über Millionen von Konten oder mehrtägige Session-Fenster.

Databricks zufolge hebt On-Demand State Repartitioning diese Einschränkung auf. Sie gilt für jede zustandsbehaftete Streaming-Abfrage, einschließlich Aggregationen, Stream-Stream-Joins, Deduplizierung, Sessionisierung und transformWithState-Workloads.

Funktionsweise

Nutzer setzen laut Databricks eine eigene Konfiguration, spark.sql.streaming.stateStore.partitions, und starten die Abfrage neu. Diese Einstellung hat bei zustandsbehafteten Abfragen Vorrang vor spark.sql.shuffle.partitions. Beim Neustart schließt die Abfrage zunächst jeden ausstehenden Mikrobatch ab und führt anschließend eine einmalige Repartitionierung durch, bei der die Zustandsdaten physisch auf die neue Partitionsanzahl verteilt und Schlüssel neu gehasht an ihre korrekten Positionen gebracht werden. Danach nimmt die Abfrage die Verarbeitung mit der neuen Partitionsanzahl wieder auf.

Voraussetzung für die Nutzung der Funktion sind laut Databricks Databricks Runtime 18 oder höher sowie der RocksDB-State-Store-Provider, der bei neu erstellten Abfragen ab DBR 17.3 standardmäßig verwendet wird.

Monitoring

Databricks zufolge erscheint die Dauer des Repartitionierungsvorgangs in den regulären StreamingQueryProgress-Events, konkret in den durationMs-Metriken unter einem Feld namens controlBatch.REPARTITION. Das Unternehmen gibt an, dass die Dauer der Repartitionierung proportional zur Menge des betroffenen Zustands ist, bei den meisten Workloads jedoch nur wenige Sekunden in Anspruch nehmen dürfte.

Genannte Anwendungsfälle

Databricks nennt drei Szenarien für die Funktion: die nachträgliche Anpassung der Größe einer Abfrage nach dem Start, etwa wenn eine ursprünglich für ein kleines Pilotprojekt festgelegte Partitionsanzahl mit dem Wachstum nicht mehr ausreicht – beispielsweise bei einem Betrugserkennungs-Stream, der sich von einer Region auf viele ausweitet; die Anpassung an wechselnde Workloads, etwa bei einer Ad-Bidding-Pipeline, die die Partitionsanzahl tagsüber für höheren Traffic erhöhen und nachts wieder reduzieren könnte; sowie das Nachladen historischer Daten, wobei vorübergehend eine höhere Partitionsanzahl genutzt werden könnte, um die Neuverarbeitung vergangener Daten zu beschleunigen, bevor man für den stationären Betrieb wieder herunterskaliert.

Kundenbeispiel

Databricks zitiert Alexis Chicoine, Senior Software Developer bei Coveo und einer der frühen Anwender der Funktion, wonach Coveo groß angelegte zustandsbehaftete Streaming-Pipelines mit schwankenden Datenvolumina betreibt und mithilfe der Funktion die damit verbundenen Amazon-S3-API-Kosten um 40 % senken konnte. Chicoine erklärte, das Unternehmen habe zuvor zwischen Überprovisionierung oder dem Neuaufbau aus neuen Checkpoints wählen müssen, was die Speicher-API-Kosten nahe an die Rechenkosten herangetrieben habe. Nun könne man skalieren, ohne den bestehenden Zustand zu stören oder Checkpoint-Migrationen auszulösen.

Quelle: Databricks-Blog, „Announcing On-Demand State Repartitioning for Apache Spark™ Structured Streaming on Databricks", veröffentlicht am 14. September 2026.