告别混淆！一文讲透 Flink State Backend 与 Checkpoint Storage

大大大大晴天
0 阅读3分钟

一、引言

在 Flink 1.13 版本之前，StateBackend 接口是一个“大杂烩”，它同时负责两件事：

  1. 状态的本地访问与存储（Task 运行时状态存在哪？内存还是 RocksDB？）
  2. Checkpoint 数据的持久化（做快照时，状态备份到哪？JobManager 还是 HDFS？）

这种设计导致了概念上的混淆（例如 FsStateBackend 运行时其实使用的是 TaskManager 的堆内存，但名字却带有 Fs）。为了让职责更清晰，Flink 1.13+ 正式将这两者解耦。

概念职责类比
State Backend管理运行时状态的存储与访问方式相当于"内存/磁盘"——决定你在工作时把数据放在哪里
Checkpoint Storage管理检查点快照的持久化存储位置相当于"备份仓库"——决定你把备份数据存到哪里

二、State Backend

State Backend 决定了运行时状态数据的存储介质和访问方式，目前主推两种 State Backend。

1.HashMapStateBackend

  • 状态以 Java 对象形式直接存储在 TaskManager 的 JVM 堆内存中
  • 读写速度最快（直接内存访问，无序列化/反序列化开销）
  • 状态大小受限于 JVM 堆内存容量
  • 不支持增量 Checkpoint（每次 Checkpoint 需要全量序列化整个状态）

2.EmbeddedRocksDBStateBackend

  • 状态存储在 TaskManager 本地磁盘上的嵌入式 RocksDB 实例中
  • 读写涉及序列化/反序列化（Java 对象 ↔ byte[]），有一定性能开销
  • 状态大小仅受限于本地磁盘容量，可以管理超大规模状态（TB 级别）
  • 支持增量 Checkpoint（基于 RocksDB SST 文件的增量上传）
  • RocksDB 的 Block Cache 和 Write Buffer 会占用 堆外内存（Off-Heap）

3.两种StateBackend对比

维度HashMapStateBackendEmbeddedRocksDBStateBackend
存储介质JVM 堆内存本地磁盘（RocksDB）
访问速度⚡ 极快（直接内存访问）🐢 较慢（涉及序列化 + 磁盘I/O）
状态规模上限受限于堆内存（通常 GB 级）受限于磁盘（可达 TB 级）
增量 Checkpoint❌ 不支持✅ 支持
内存管理JVM GC 管理Flink Managed Memory 管理
典型吞吐量影响对吞吐量影响小约降低 30%~50%（取决于状态访问频率）
适用场景小状态、高吞吐大状态、超大 Key 数量

三、Checkpoint Storage

Checkpoint Storage 决定了Checkpoint 快照数据的持久化位置，目前主推两种 Checkpoint Storage。

1.JobManagerCheckpointStorage

  • Checkpoint 数据通过 RPC 发送至 JobManager，存储在其堆内存中
  • 每个独立状态的大小上限默认为 5 MB（可配置 MAX_STATE_SIZE）
  • 仅适用于本地开发/测试，生产环境绝不应使用
  • 作业失败时如果 JobManager 也崩溃，Checkpoint 数据丢失

2.FileSystemCheckpointStorage

  • Checkpoint 数据写入分布式文件系统，具备高可用性和持久性
  • 小状态（默认阈值 20KB）仍会内联存储在 _metadata 文件中，避免创建过多小文件
  • 生产环境唯一推荐的 Checkpoint Storage
  • 支持与 EmbeddedRocksDBStateBackend 配合实现增量 Checkpoint

3.Checkpoint完整流程

步骤说明涉及组件
①CheckpointCoordinator 按配置的间隔周期性触发JobManager
②Checkpoint Barrier 作为特殊事件插入数据流Source → 下游
③多输入算子等待所有 Channel 的 Barrier 到齐（对齐模式）Operator
④同步阶段：创建状态快照的引用（非常快，通常 ms 级）State Backend
⑤异步阶段：将状态数据写入持久化存储（可能耗时较长）Checkpoint Storage
⑥TaskManager 向 JobManager 报告该算子的 Checkpoint 完成TM → JM
⑦所有算子 Ack 后，Checkpoint 被标记为完成JobManager

四、State Backend与Checkpoint Storage关系

旧版 (< 1.13，已废弃)等价的新版组合 (≥ 1.13)
MemoryStateBackendHashMapStateBackend + JobManagerCheckpointStorage
FsStateBackendHashMapStateBackend + FileSystemCheckpointStorage
RocksDBStateBackendEmbeddedRocksDBStateBackend + FileSystemCheckpointStorage

在Flink现在新版本的使用中，两者结合的组合矩阵建议如下：

组合State BackendCheckpoint Storage适用性
AHashMapStateBackendJobManagerCheckpointStorage⚠️ 仅开发/测试
BHashMapStateBackendFileSystemCheckpointStorage✅ 生产推荐（中小状态）
CEmbeddedRocksDBStateBackendJobManagerCheckpointStorage❌ 不推荐（无实际意义）
DEmbeddedRocksDBStateBackendFileSystemCheckpointStorage✅ 生产推荐（大状态）

以下是大多数生产环境下的推荐配置（适用于大状态、高可用场景）：

# ===== State Backend =====
state.backend: rocksdb
state.backend.incremental: true
state.backend.rocksdb.localdir: /data1/flink/rocksdb,/data2/flink/rocksdb
state.backend.rocksdb.memory.managed: true
state.backend.rocksdb.predefined-options: FLASH_SSD_OPTIMIZED

# ===== Checkpoint Storage =====
state.checkpoint-storage: filesystem
state.checkpoints.dir: hdfs:///flink/checkpoints
state.savepoints.dir: hdfs:///flink/savepoints

# ===== Checkpoint 行为 =====
execution.checkpointing.interval: 2min
execution.checkpointing.mode: EXACTLY_ONCE
execution.checkpointing.timeout: 10min
execution.checkpointing.min-pause: 1min
execution.checkpointing.max-concurrent-checkpoints: 1

# ===== 保留策略 =====
state.checkpoints.num-retained: 3

# ===== 内存配置 =====
taskmanager.memory.managed.fraction: 0.4
avatar
文章
阅读
粉丝