当前位置：首页 > news >正文

Flink 2.0 解耦状态管理（Disaggregated State）ForSt + 异步 State API V2 + SQL Async-State 上手与调优

news 2026/3/26 22:13:11

1. 解耦状态管理到底解决什么

把“状态放远端”这件事做成生产级，必须同时解决三类痛点：

状态容量：本地盘不够时，状态无法继续增长
稳定性：checkpoint/compaction 带来的尖刺资源消耗会让尾延迟很难看
恢复速度：大状态作业恢复时拉取状态，恢复耗时太长 (Apache Nightlies)

Flink 2.0 的目标收益（按官方定位总结）：

状态规模近似“无限”：上限取决于外部存储系统（S3/HDFS） (Apache Nightlies)
checkpoint 更轻量：状态在远端，checkpoint 过程更接近“确认点/元信息”，而不是“搬运大文件”（实际仍需看配置与实现路径） (Apache Nightlies)
恢复更快：不再需要把全部状态下载到本地再跑，恢复与状态规模的耦合被显著削弱（更偏向“元信息 + 缓存预热”） (Apache Nightlies)
计算与存储可独立扩缩：你可以单独加算力或换更高吞吐的对象存储，而不用跟着换本地盘 (Apache Nightlies)

需要强调：这套能力目前仍被标注为experimental，API/配置未来可能变化，生产落地要按“灰度 + 回滚预案”来做。(Apache Nightlies)

2. 三大组成：ForSt + State API V2 + SQL 支持

解耦状态管理由三块拼起来：

2.1 ForSt State Backend：把 SST 放到远端

ForStStateBackend是面向解耦状态的后端，它基于 ForSt（LSM-tree，构建在 RocksDB 之上），关键能力是可以把 SST 文件放到 Flink 支持的远端文件系统（S3/HDFS 等），本地盘只做缓存与缓冲。(Apache Nightlies)

2.2 新状态 API：State API V2（异步读写）

远端访问必然有网络延迟，所以 Flink 2.0 引入了State API V2，核心是支持异步状态读写，用非阻塞执行模型去“隐藏”远端延迟。(Apache Nightlies)

2.3 SQL 支持：Async-State SQL Operators

SQL 侧把一批关键算子重写为异步状态访问模式，开启后在高延迟状态访问场景可以显著提升吞吐（非阻塞执行）。(Apache Flink)

同时也要知道边界：当状态规模较小，本地同步访问往往更快更简单；解耦状态与异步访问主要是给“大状态”准备的。(Apache Nightlies)

3. 快速开始

3.1 SQL 作业启用（推荐从 SQL 先试水）

核心开关：

state.backend.type: forst
table.exec.async-state.enabled: true(Apache Nightlies)

示例（S3 为例）：

state.backend.type:forsttable.exec.async-state.enabled:true# 必须启用 checkpoint，并配置目录execution.checkpointing.incremental:trueexecution.checkpointing.dir:s3://your-bucket/flink-checkpoints# 当前异步 state 访问下暂不支持 mini-batch 与两阶段聚合（建议关闭/改策略）table.exec.mini-batch.enabled:falsetable.optimizer.agg-phase-strategy:ONE_PHASE

SQL 的现实情况是：并不是所有算子都完整支持 async-state；不支持的算子会自动回退到同步实现（能跑，但性能可能不理想）。(Apache Nightlies)

当前文档列出的支持算子包括：Rank(Top1/Append TopN)、RowTime 去重、非 distinct 聚合、Join、Window Join、Tumble/Hop/Cumulative 窗口聚合等。(Apache Nightlies)

3.2 DataStream 作业启用（需要配合 State V2 改代码）

两步走：

第一步：配置 ForSt + checkpoint（增量建议开启）

Configurationconfig=newConfiguration();config.set(StateBackendOptions.STATE_BACKEND,"forst");config.set(CheckpointingOptions.CHECKPOINTS_DIRECTORY,"s3://your-bucket/flink-checkpoints");config.set(CheckpointingOptions.INCREMENTAL_CHECKPOINTS,true);env.configure(config);

或在flink-conf.yaml：

state.backend.type:forstexecution.checkpointing.incremental:trueexecution.checkpointing.dir:s3://your-bucket/flink-checkpoints

第二步：把作业中关键状态访问点逐步迁移到State API V2的异步接口（否则你只是“换了 backend”，但没有真正启用远端异步访问的优势）。(Apache Nightlies)

4. 一个很关键的“真相”：ForSt 默认并不会强制所有状态都上远端

文档里的一个设计点非常重要：ForSt 默认仅在你使用异步 API（State V2）时才真正“解耦”状态。当你用同步 state API 时，ForSt 会更像“本地状态存储”。这样同一个作业里可以混合：

同步算子：本地状态，吞吐高、延迟低
异步算子：远端状态，突破容量限制

如果你想让同步 API 的算子也把状态放远端，可以设置：

state.backend.forst.sync.enforce-local:false

并指定本地目录：

state.backend.forst.local-dir:/path/to/local-dir

这通常用于“状态大到本地不够，但短期又没法把所有算子迁移到 State V2”的过渡期策略。

5. ForSt 的高级调优项（大状态必看）

ForSt 的大多数调优思路与 RocksDB 类似（内存、cache、写缓冲、compaction 等），但它有一些“解耦状态特有”的参数。

5.1 Primary Storage Location：主状态目录（谨慎使用）

默认情况下，ForSt 把状态放在 checkpoint 目录，这样更容易实现轻量 checkpoint 和快速恢复。

你也可以指定主状态目录：

state.backend.forst.primary-dir:s3://your-bucket/forst-state

但注意：如果 primary-dir 与 checkpoint-dir 分离，checkpoint/恢复期间可能需要在两者之间做文件拷贝，反而削弱“轻量 checkpoint / 快速恢复”的优势（更像传统“复制式”流程）。

5.2 本地文件缓存（File Cache）

ForSt 用本地盘做文件级缓存（粒度是“整文件”）。常用的是两类限制策略：

大小上限：超过就淘汰最老文件
预留空间：磁盘剩余空间不足就淘汰最老文件

配置示例：

state.backend.forst.cache.size-based-limit:1GBstate.backend.forst.cache.reserve-size:10GBstate.backend.forst.cache.dir:/tmp/forst-cache

建议你把 cache 盘位当成“关键资源”来规划：cache 太小会导致远端读放大、吞吐抖动；cache 太大又会挤占 TM 本地盘空间。

5.3 异步线程池（通常默认够用）

ForSt 的异步 I/O 有读线程、写线程、协调线程。默认一般够用，特殊场景（例如对象存储高延迟、读放大严重）再调：

state.backend.forst.executor.read-io-parallelism:3state.backend.forst.executor.write-io-parallelism:1state.backend.forst.executor.inline-write:truestate.backend.forst.executor.inline-coordinator:true

把inline-*设为 false 可能提高并发但会明显抬 CPU，用之前最好压测。

6. 什么时候该用解耦状态：一张实战决策表

更适合上 ForSt + async state 的典型信号：

状态规模逼近或超过本地盘容量，或者云上本地盘成本过高
恢复耗时成为 SLO 的最大风险点（大状态恢复太慢）
checkpoint/compaction 的周期性尖刺导致尾延迟不可控
你愿意接受 experimental 带来的版本迭代与灰度成本 (Apache Nightlies)

更适合继续用本地状态（HashMap/RocksDB）的信号：

状态不大，业务更关注极致低延迟与稳定吞吐
对象存储延迟/带宽不可控，网络抖动会直接影响状态访问
你无法短期改造 DataStream 作业去使用 State API V2

7. 落地建议：从“可控试点”开始

优先从 SQL 作业试点
SQL 一行配置就能打开 async-state，改造成本低，且支持的算子集合已经覆盖很多典型 OLAP/实时数仓场景。(Apache Nightlies)
明确试点指标
至少盯三类指标：checkpoint 时长与长尾、恢复时长、端到端延迟/吞吐波动（尤其是远端读放大时的抖动）。
DataStream 走“混合策略”迁移
先让 ForSt 跑起来，关键热点算子逐步迁到 State V2 异步接口；同步算子先留本地，避免全链路一次性改造导致风险扩散。(Apache Nightlies)
预留回滚路径
因为 feature 仍是 experimental，建议在切换前先用 savepoint 规划好回滚（例如回到 RocksDB），并把关键 operator uid 固定好。

查看全文

http://www.jsqmd.com/news/397011/