Processing individual events in isolation is straightforward. However, complex streaming applications require context. Whether calculating a running average or joining user activity streams, the system must retain information about previous events. This retained information is state. Managing this data in a distributed cluster is difficult because the system must guarantee correctness even during hardware failures or network partitions.
This chapter examines the mechanisms Flink employs to provide fault tolerance and consistent state access. You will analyze the available state backends, comparing the performance characteristics of storing objects on the Java heap versus using the embedded RocksDB key-value store. The choice of backend dictates performance and stability when the total state size exceeds available memory, often requiring data to spill to disk.
We also cover how Flink coordinates distributed snapshots using the Asynchronous Barrier Snapshot algorithm to ensure exactly-once guarantees. You will implement optimization techniques such as incremental checkpointing to minimize the data written to stable storage. Finally, the content addresses the operational procedures for evolving state schemas when application logic changes, ensuring that updates do not corrupt existing data.
3.1 State Backends: HashMap versus RocksDB
3.2 Asynchronous Barrier Snapshots
3.3 Incremental Checkpointing
3.4 State Schema Evolution
3.5 Hands-on Practical: State Migration with Savepoints