Flink 流式计算的状态之道从 Table/SQL 语义到算子状态与 TTL 精准控制

原创已于 2025-11-06 10:27:48 修改 · 977 阅读

18 ·

CC 4.0 BY-SA版权

文章标签：

#sql #flink #linq

于 2025-11-06 09:10:23 首次发布

flink 专栏收录该内容

95 篇文章

订阅专栏

1. 统一语义的起点：动态表与变更流

Flink 的 Table API & SQL 对批流语义统一：无论输入是否有界，都视为动态表，以 变更日志（Changelog） 体现结果演进（RowKind：INSERT/DELETE/UPDATE_BEFORE/UPDATE_AFTER）。
有界流可启用 Batch Runtime Mode 获得更优算子（如 sort-merge join、阻塞交换），但同样的查询在 Streaming 模式也能跑，最终结果一致（批模式通常折叠为 insert-only）。

2. 显式 vs 隐式：哪些查询会“吃状态”？

2.1 显式有状态（典型：聚合、Join、去重）

下面这个词频统计需要按 word 维护计数，自然是Keyed State（见图 1）：

CREATE TABLE doc (word STRING) WITH ('connector'='...');
CREATE TABLE word_cnt (
  word STRING PRIMARY KEY NOT ENFORCED,
  cnt  BIGINT
) WITH ('connector'='...');

INSERT INTO word_cnt
SELECT word, COUNT(*) AS cnt
FROM doc
GROUP BY word;

Key 空间随新词增多而增长，状态体量持续上涨——需要窗口、TTL 或业务限界来兜底。

<!-- FIG:STATEFUL_FROM_QUERY -->
![图 1：按查询派生的有状态算子（词频聚合，含 Keyed State 与 RowKind）](path/to/fig-stateful-from-query.png)
> 注：状态算子对相同 key 进行累加，向下游产生 +I/-U/+U。

2.2 隐式有状态（输入/下游契约触发）

即便是看似“无状态”的 SELECT *，也可能因为上游/下游的变更契约被 Planner 插入Changelog 归一化算子（ChangelogNormalize），从而自动变成有状态（见图 2）：

CREATE TABLE upsert_kafka (
  id INT PRIMARY KEY NOT ENFORCED,
  message STRING
) WITH ('connector' = 'upsert-kafka', ...);

SELECT * FROM upsert_kafka;

若下游需要完整变更（含 UPDATE_BEFORE），而上游仅提供 INSERT/UPDATE_AFTER/DELETE，Planner 会在中间加一个状态化归一化算子补齐 BEF/AFT。

<!-- FIG:STATEFUL_FROM_TRAIT -->
![图 2：由输入特征隐式派生的有状态算子（upsert-kafka → ChangelogNormalize）](path/to/fig-stateful-from-trait.png)
> 注：上游仅 INSERT/UPDATE_AFTER/DELETE，算子补齐 UPDATE_BEFORE 以满足下游完整变更。

3. DataStream × Table 融合：怎么“进出两界”更顺手？

常用桥接是 StreamTableEnvironment：

StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
StreamTableEnvironment tEnv = StreamTableEnvironment.create(env);

// DataStream -> Table（插入流，自动推导 schema）
DataStream<String> ds = env.fromElements("Alice","Bob","John");
Table t = tEnv.fromDataStream(ds);
tEnv.createTemporaryView("InputTable", t);

// SQL 清洗后再回 DataStream
Table result = tEnv.sqlQuery("SELECT UPPER(f0) AS name FROM InputTable");

// 仅 append-only 用 toDataStream；有更新请选择 toChangelogStream
DataStream<Row> out = tEnv.toDataStream(result);
out.print();
env.execute();

只插入（append-only）：toDataStream。
带更新：toChangelogStream（产出 RowKind，可对接 Upsert Sink 或自定义算子）。
事件时间/水印：可在 fromDataStream(..., Schema) 中声明 rowtime 与 WATERMARK，或继承 DataStream 的 source watermark（SOURCE_WATERMARK()）。

4. 事件时间与水印：三种声明姿势

字段派生 rowtime + 策略

Table t = tEnv.fromDataStream(ds,
  Schema.newBuilder()
    .columnByExpression("rowtime","CAST(event_time AS TIMESTAMP_LTZ(3))")
    .watermark("rowtime","rowtime - INTERVAL '10' SECOND")
    .build());

继承 DataStream 的水印

Table t = tEnv.fromDataStream(ds,
  Schema.newBuilder()
    .columnByMetadata("rowtime", "TIMESTAMP_LTZ(3)")
    .watermark("rowtime", "SOURCE_WATERMARK()")
    .build());

回流 DataStream 时携带时间戳

toDataStream(table)：单一 rowtime 会写入 record timestamp，水印继续传播。
也可将时间戳作为 metadata 输出，不占物理列。

5. 状态保留（TTL）：从全局到“算子×输入边”的精细化

5.1 全局 TTL（管道级）

SET 'table.exec.state.ttl' = '30 d';

某 Key 在 TTL 内没有更新即被清理；再次到达视为新 Key（计数从 0 开始）。
适合长尾 Key 多且允许“遗忘”的聚合场景。

5.2 算子级 TTL（更细粒度）

适用：同一作业有多个状态且保留期不同（例如去重 1h、聚合 7d）。

三种设置方式（优先级从低到高）：

全局：table.exec.state.ttl

SQL Hint（仅“常规 Join / Group Agg”）：

SELECT /*+ STATE_TTL('6 h') */ user_id, COUNT(*) FROM t GROUP BY user_id;

Compiled Plan JSON（最通用，逐算子逐输入边）：见 5.3

注：窗口/区间 Join/Agg/Top-N 不靠 table.exec.state.ttl 控制状态，依据窗口边界自然清理。

5.3 用 Compiled Plan 精准改 TTL

生成 JSON 计划：

CompiledPlan plan = tEnv.compilePlanSql(
  "INSERT INTO enriched_orders " +
  "SELECT a.order_id, a.order_line_id, b.order_status " +
  "FROM orders a JOIN line_orders b ON a.order_line_id = b.order_line_id");
plan.writeToFile("/path/to/plan.json");

修改 Join 节点的 state 字段（单位 ms）：

"state": [
  {"index": 0, "ttl": "3000 ms", "name": "leftState"},
  {"index": 1, "ttl": "9000 ms", "name": "rightState"}
]

执行计划：

EXECUTE PLAN '/path/to/plan.json';

经验法则：下游算子 TTL ≥ 上游算子 TTL，避免“下游先忘、上游还在”的语义问题。
通过 EXECUTE PLAN 提交的作业，以文件中的 TTL 为准，不会再读取全局 table.exec.state.ttl。

6. 批运行模式（Batch Runtime Mode）：同一逻辑，两种执行

env.setRuntimeMode(RuntimeExecutionMode.BATCH); // 或 STREAMING
StreamTableEnvironment tEnv = StreamTableEnvironment.create(env);

BATCH：不产生增量更新，最终折叠成 insert-only；可启用阻塞交换、禁用 checkpoint，资源占用更低。
STREAMING：持续产生 +I/-U/+U/-D。
使用事件时间 + 水位线语义时，两模式最终表一致（只是输出方式不同）。

7. 运维观测：你至少要盯的 6 件事

状态体量：key/bytes、RocksDB 指标（若使用）。
Checkpoint：对齐耗时、大小、失败率。
水位线：推进速率与滞后分布。
算子健康：Busy/BackPressured/Idle、Records In/Out、Shuffle 延迟。
TTL 效果：清理速率/被清理 key 数，长尾是否受控。
计划核验：EXPLAIN/table.explain() 确认是否引入了意料之外的状态化归一化节点。

8. 升级与演进：保存点不是“万能药”

任何查询变更或 Planner 规则升级，都可能改变拓扑或中间状态 schema，导致** Savepoint 不兼容**。
建议：
- 小版本（补丁版）一般安全；跨小版本/大版本不保证兼容。
- 变更前后做 EXPLAIN Diff；必要时用**历史数据热身（warm-up）**新作业，再切实时流。
- 关键任务优先走灰度 + 双写对比。