State-Rebuilds: Kafka Streams vs. Apache Flink

1. Überblick

Zustandsbehaftete Stream-Prozessoren akkumulieren im Laufe der Zeit Zustand aus Ereignisströmen. Dieser Zustand steuert jede Aggregation, jeden Join und jede Fensterberechnung, die eine Anwendung ausführt. Wenn wir Geschäftslogik ändern, einen Fehler beheben, ein Schema weiterentwickeln oder historische Daten korrigieren, kann der aufgebaute Zustand nicht mehr gültig sein. In diesem Fall benötigen wir ein Rebuild, bei dem Eingabeereignisse erneut abgespielt werden, bis Zustand und Ausgaben wieder der Realität entsprechen.

Rebuilds sind teuer: Sie erzeugen erheblichen Replay-Traffic, verursachen anhaltenden Backpressure in der Pipeline, erhöhen die Infrastrukturbelastung und verlängern Wiederherstellungsfenster.

In diesem Artikel vergleichen wir, wie Kafka Streams und Apache Flink Rebuilds in Produktionsumgebungen auslösen, durchführen und – wo möglich – vermeiden.

2. Rebuilds in Kafka Streams

In Kafka Streams liegt der Anwendungszustand in lokalen State Stores, die durch Changelog-Topics auf dem Broker abgesichert sind. Ein Rebuild bedeutet, Consumer-Offsets zurückzusetzen und diese Stores vollständig neu zu materialisieren.

Da Zustand und Offsets eng miteinander gekoppelt sind, erzwingt jede Inkonsistenz zwischen beiden ein vollständiges Replay.

2.1. Auslöser für Rebuilds

Typischerweise benötigen wir ein Rebuild, wenn:

• Logikänderungen – wir ändern, wie Datensätze aggregiert, gejoint oder fensterbasiert verarbeitet werden
• Bugfixes – zuvor materialisierte Ergebnisse sind nicht mehr korrekt
• Topologieänderungen – wir fügen Operatoren hinzu oder entfernen sie oder verschieben Repartitionierungsgrenzen
• Schema-Evolution – die Semantik von Datensätzen oder das Serialisierungsformat ändert sich
• Datenkorrekturen – ein Fortsetzen mit aktuellen Offsets würde falsche Ausgaben beibehalten

2.2. Backpressure und Lag

Sobald ein Rebuild startet, verarbeitet die Anwendung historische Daten deutlich schneller, als sie einen Live-Stream verarbeiten würde. Dieser Durchsatzschub belastet mehrere Teile des Systems gleichzeitig:

• CPU-, Speicher- und Netzwerkauslastung steigen stark an, da Datensätze mit maximaler Geschwindigkeit erneut abgespielt werden
• Zustandsbehaftete Operatoren (Aggregationen, Joins, Fensterberechnungen) werden durch intensive State-Store-Schreibvorgänge und RocksDB-Kompaktionen zu Engpässen
• Nachgelagerte Consumer und Output-Topics können drosseln, wodurch sich die End-to-End-Latenz erhöht
• Interne Repartitionierungs- und Changelog-Topics erhöhen zusätzlich Broker- und Netzwerklast

3. Rebuilds in Apache Flink

Flink verwaltet Zustand zentral über periodische Checkpoints und bedarfsorientierte Savepoints. Die gleichen Auslöser gelten auch hier: Logikänderungen, Bugfixes, Schema-Evolution und Datenkorrekturen können den aktuellen Zustand ungültig machen.

Allerdings erfordert Flink auch in Situationen ein Rebuild, die bei Kafka Streams in dieser Form nicht auftreten: Zustandskorruption, inkompatible State-Serializer oder verlorene Source-Offsets, die eine saubere Wiederherstellung aus einem Checkpoint oder Savepoint verhindern.

3.1. Point-in-Time-Rebuilds

Ein Vorteil von Flink ist die Möglichkeit, einen Job mithilfe eines Savepoints auf einen bestimmten Zeitpunkt zurückzusetzen. Statt die gesamte Historie erneut abzuspielen, starten wir den Job von einem Savepoint neu, der zu diesem Zeitpunkt den vollständigen Operator- und Keyed-State enthält. Ereignisse nach dem Savepoint werden dann unter der neuen Logik neu bewertet.

Das ist besonders nützlich, wenn wir:

• Ein Anwendungsupgrade sicher ausrollen möchten
• Einen Hotfix anwenden wollen, ohne die gesamte Historie neu zu verarbeiten
• Nur ein kürzliches Datenfenster nach einer Korrektur nachverarbeiten müssen

3.2. Backpressure während Rebuilds

Flink-Rebuilds haben dasselbe Grundproblem wie Kafka Streams: Das Replay historischer Daten hebt die natürliche Ratenbegrenzung der Live-Ingestion auf. Der Durchsatz steigt stark an, zustandsbehaftete Operatoren und Sinks werden zu Engpässen, und Backpressure propagiert stromaufwärts.

Der Unterschied bei Flink liegt im Checkpointing. Backpressure verlängert die Barrier-Alignment-Zeit und die Gesamtdauer von Checkpoints, wodurch das Risiko von Timeouts oder vollständigen Fehlschlägen steigt. In der Praxis bedeutet ein stabiler Rebuild, die Source-Consumption zu drosseln, Checkpoint-Intervalle zu verlängern und Backpressure-Metriken genau zu überwachen.

Wir können den Prozess auch beschleunigen, indem wir vorübergehend horizontal skalieren. Eine Erhöhung der Parallelität verteilt die Replay-Last auf mehr Task-Slots und verkürzt das Rebuild-Fenster. Sobald der Job aufgeholt hat, skalieren wir wieder zurück.

3.3. Rebuilds vermeiden mit der State Processor API

In einigen Fällen können wir ein Rebuild ganz vermeiden. Die Flink State Processor API erlaubt es, Zustand direkt in einem Savepoint zu lesen und zu verändern. Statt Ereignisse erneut abzuspielen, korrigieren oder migrieren wir den Zustand offline und starten den Job vom angepassten Savepoint neu.

Das eignet sich besonders für:

• Das Entfernen oder Korrigieren korrupter Zustände für bestimmte Keys
• Die Migration von State-Schemata beim Upgrade eines Jobs

Der Nachteil: Wir bearbeiten den Zustand außerhalb des normalen Verarbeitungsflusses, daher ist eine gründliche Validierung unerlässlich. Wenn jedoch ein Source-Replay teuer ist oder die Quelldaten nicht mehr verfügbar sind, kann dieser Ansatz erheblich Zeit und Infrastrukturkosten sparen.

4. Fazit

In diesem Artikel haben wir betrachtet, wie Kafka Streams und Apache Flink mit State-Rebuilds umgehen. Wir haben analysiert, was sie auslöst, welche Backpressure- und Latenzeffekte auftreten und welche Strategien beide Frameworks bieten, um Rebuilds zu steuern oder zu vermeiden.

Kafka Streams koppelt Zustand eng an lokale Stores und Changelog-Topics, wodurch Rebuilds zu einer vollständigen Replay-Operation werden. Flinks Checkpoint- und Savepoint-Modell ermöglicht hingegen Point-in-Time-Rebuilds und Offline-State-Patching über die State Processor API und bietet damit mehr Flexibilität, wenn ein Rebuild unvermeidlich ist.