一、为什么需要”真正的”流处理

Spark Structured Streaming 用”微批”（把流切成一个个小批）模拟流处理，工程上优雅，但有三个先天限制：

在架构演进上，有两套经典方案：

• Lambda 架构：同一套逻辑写两遍——批层（Spark）保证最终准确， speed 层（Storm/Flink）保证低延迟，最后在服务层合并。缺点显而易见：两套代码、两倍维护成本、口径难对齐。
• Kappa 架构：只保留流处理一条链路，需要重算历史时把 Kafka 的保留期拉长、从 offset 0 重放。Flink 的流批一体让 Kappa 架构真正落地。

二、核心架构：JobManager、TaskManager 与 Slot

2.1 运行时组件

1
2
3
4
5
6
7
8
9

Client（提交作业，生成 JobGraph 后退出）
   │
Dispatcher ── 启动 JobMaster，提供 REST 接口
   │
JobManager（每个作业一个 JobMaster）
   │  调度 Task、协调 Checkpoint
TaskManager × N ── 实际执行算子，汇报心跳与 Slot 状态
   │
ResourceManager ── 管理 Slot 分配，对接 YARN/K8s

• JobManager：把作业的算子编排成可执行的 Task 图（JobGraph → ExecutionGraph），负责调度和 Checkpoint 协调；
• TaskManager：工作进程，启动时注册若干 Task Slot，每个 Slot 是一块固定的内存资源；
• Slot 与并行度：Slot 隔离的是内存而不是 CPU。parallelism 决定算子被切成多少个并行子任务，一个子任务占一个 Slot。

Slot 数量规划：Slot 数 ≥ 作业中并行度最高的算子的并行度即可（默认算子间可共享 Slot，source 和 sink 能落在同一个 Slot 里），生产上常设 TaskManager Slot 数 = 1~2 × 单机核数。

2.2 算子链：减少序列化与网络开销的关键

Flink 会自动把满足条件的相邻算子”链”（Chain）在同一个线程里执行：并行度相同 + 本地转发连接。链内的数据传递是方法调用而非网络序列化，这是 Flink 吞吐高的关键设计之一。

1
2
3
4
5
6
7
8

// 算子链示意：map -> filter 链在同一个线程，keyBy 之后才发生网络传输
env.socketTextStream("host", 9999)
   .map(line -> parse(line))          // ┐
   .filter(e -> e.isValid())          // ┘ 同一 Slot、同一线程（Chain）
   .keyBy(Event::getKey)              // ← 数据按 key 重分区（网络传输）
   .window(TumblingEventTimeWindows.of(Time.minutes(1)))
   .aggregate(new CountAgg())
   .print();

disableOperatorChaining() / startNewChain() 可以手动干预，但先确认瓶颈真的是链结构，而不是盲目拆链。

三、时间语义与 Watermark：乱序问题的正确解法

3.1 三种时间

为什么必须用 Event Time：移动端断网 10 分钟后补传的日志，Processing Time 会把它算进”补传那一刻”的窗口，而业务上它属于 10 分钟前。流计算和批处理最大的认知差异就是：数据的产生顺序 ≠ 数据的处理顺序。

3.2 Watermark：一个”时间可以推进了”的承诺

Watermark 是一条特殊的记录，含义是：时间戳 ≤ W 的数据应该都到齐了（在不考虑迟到数据的前提下）。它把”乱序容忍度”显式地告诉了引擎：

1
2
3
4
5
6

WatermarkStrategy<Event> strategy = WatermarkStrategy
    .<Event>forBoundedOutOfOrderness(Duration.ofSeconds(5))  // 容忍 5 秒乱序
    .withTimestampAssigner((event, ts) -> event.getEventTime())
    .withIdleness(Duration.ofSeconds(30));   // 空闲分区 30s 后不再阻塞水位推进

stream.assignTimestampsAndWatermarks(strategy);

必须理解的四个机制：

1. 周期性生成：默认每 200ms（pipeline.auto-watermark-interval）发出一次，而不是逐条计算，降低开销；
2. 多分区取最小：算子有多个输入时，Watermark 取所有输入的最小值——最慢的分区决定水位，这就是”空闲分区拖死全局”的原因，withIdleness 用来兜底；
3. 乱序容忍度是权衡：设小了迟到数据多（算不准），设大了窗口触发晚（延迟高），按业务 P99 乱序幅度来定；
4. Watermark 单调递增，以分区为单位传播，max(已有水位, 新水位) 保证不回退。

3.3 迟到数据的三级兜底

Watermark 只能”尽量准”，迟到数据的完整处理链是：

1

窗口触发（按 Watermark）→ allowedLateness 宽限期内更新结果 → 超过宽限期 → sideOutput 旁路输出

1
2
3
4
5
6
7
8

SingleOutputStreamOperator<Result> result = stream
    .keyBy(Event::getKey)
    .window(TumblingEventTimeWindows.of(Time.minutes(1)))
    .allowedLateness(Time.minutes(2))            // 触发后 2 分钟内还收，收到就重算更新
    .sideOutputLateData(lateTag)                 // 彻底迟到的走旁路
    .aggregate(new CountAgg(), new WindowResult());

stream.getSideOutput(lateTag).print("late");     // 旁路数据写 Kafka/库另行处理

四、Window：滚动、滑动与会话窗口

窗口本质是把无限流切成有限数据集的机制，每个进入的数据按 (key, window) 分配到独立的窗口实例，触发时按窗口内的数据计算。两个实现层面的关键点：

• 增量聚合优先：reduce() / aggregate() 让数据到来时就聚合，窗口只存一个中间值，内存占用远小于全量缓存的 process(ProcessWindowFunction)；需要”聚合结果 + 窗口元信息”时，把两者结合使用；
• 会话窗口没有固定窗口：每个 key 维护独立的会话，数据到来会触发已有会话的合并，所以会话窗口只能用全量触发语义，开销比滚动/滑动高。

五、状态管理：Keyed State 与 StateBackend

5.1 两类状态

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class DedupFunction extends KeyedProcessFunction<String, Event, Event> {
    private ValueState<Boolean> seen;   // Keyed State：每个 key 独立一份

    @Override
    public void open(Configuration parameters) {
        StateTtlConfig ttl = StateTtlConfig
            .newBuilder(Time.hours(24))                 // 24h 自动清理
            .setUpdateType(StateTtlConfig.UpdateType.OnCreateAndWrite)
            .setStateVisibility(StateTtlConfig.StateVisibility.ReturnExpiredIfNotCleanedUp)
            .build();
        ValueStateDescriptor<Boolean> desc =
            new ValueStateDescriptor<>("seen", Boolean.class);
        desc.enableTimeToLive(ttl);
        seen = getRuntimeContext().getState(desc);
    }

    @Override
    public void processElement(Event e, Context ctx, Collector<Event> out) throws Exception {
        if (seen.value() == null) { out.collect(e); seen.update(true); }
    }
}

• Keyed State：绑定在 key 上（ValueState、ListState、MapState、ReducingState），只能用在 keyBy 之后，是最常用的状态类型；
• Operator State：绑定在算子子任务上（典型如 Kafka Source 的 offset 列表），扩容时有 even-split（均分） 和 union（全量广播） 两种重分配方式。

5.2 StateBackend 怎么选

六、Checkpoint 与 Exactly-Once：分布式快照如何落地

6.1 Barrier 对齐：核心机制

Flink 的容错基于分布式快照（Chandy-Lamport 算法的工程化变体）：

1. JobManager 的 Checkpoint Coordinator 周期性（默认间隔见配置，常 1~5 分钟）向 Source 注入 Barrier；
2. Barrier 随数据流向下游，收到所有输入 Barrier 的算子把当前状态异步快照到远程存储（StateBackend/对象存储），然后向下游转发 Barrier；
3. Source 端同时把 offset 持久化，形成”状态 + 数据源位置”的一致性快照；
4. 全部算子完成快照 → Checkpoint 完成。

Barrier 对齐：某条输入先到 Barrier 时，该输入通道的数据先缓存不处理，等所有通道 Barrier 齐了再做快照——保证快照精确覆盖”Barrier 之前的数据”。代价是背压时对齐会放大延迟，Flink 1.11+ 提供 Unaligned Checkpoint（Barrier 直接越过缓冲区，把 in-flight 数据一并快照），牺牲一点快照体积换取大背压下的稳定出快照。

6.2 端到端 Exactly-Once：两阶段提交

Flink 内部的状态恢复是 Exactly-Once，但结果写出去还要配合 Sink：

• 幂等写入：如写 Redis/数据库按主键 upsert，重放不会产生重复结果；
• 事务写入（两阶段提交）：Sink 在 Checkpoint 前预提交事务，Checkpoint 完成后正式 commit，失败则回滚。配合 Kafka 事务生产者即可实现端到端精确一次（Kafka 事务机制见 Kafka 篇，此处不展开）。

6.3 Checkpoint vs Savepoint

生产铁律：每个算子显式 uid()。不设 uid 时 Flink 按拓扑结构自动生成，代码一改 uid 全变，Savepoint 恢复时状态全部对不上——这是升级作业最常见的翻车点。

七、流批一体与 Table SQL

Flink 的 Table API/SQL 把流和批统一为动态表（Dynamic Table）：流是”不断 INSERT 的表”，查询持续产生更新。用 SQL 写实时任务，代价是某些更新语义会触发回撤流（Retract Stream）——上游一条变更，下游先发撤销再发新值。

1
2
3
4
5
6
7
8
9
10

-- 实时 TopN：一个 SQL 同时搞定窗口聚合和排名
SELECT *
FROM (
  SELECT *,
    ROW_NUMBER() OVER (PARTITION BY window_start ORDER BY pv DESC) AS rn
  FROM TABLE(
    TUMBLE(TABLE page_view, DESCRIPTOR(ts), INTERVAL '1' MINUTE))
  GROUP BY window_start, page_id   -- 聚合在窗口内完成
)
WHERE rn <= 10;

落地建议：简单聚合/维表关联直接 SQL，复杂状态逻辑（异步 IO、自定义清理）用 DataStream API，两者可以在同一作业里混合（toChangelogStream / fromChangelogStream）。

八、流处理引擎专项对比：Flink vs Structured Streaming vs Storm

（Spark 篇的对比表聚焦批处理定位，这里单看流处理能力）

选型结论：实时场景默认 Flink；已有 Spark 体系且延迟要求在秒级以上，Structured Streaming 复用现有平台更省事；Storm 只在存量系统维护中遇到。

九、生产避坑清单

1. Watermark 不推进先查空闲分区：多分区 Source 中某个分区没数据会拖死全局水位，withIdleness 必配，否则窗口永远不触发；
2. 时间戳单位统一成毫秒：业务库里存秒级时间戳是常态，赋值时 ×1000；”窗口延迟一小时才触发”多半是单位错了；
3. 状态必设 TTL：去重、UV 这类状态无界增长，不给 TTL 迟早 RocksDB 膨胀 + Checkpoint 越来越慢；TTL 的清理是惰性的，配合 StateTtlConfig 的 compaction 才真正释放；
4. 每个算子 uid()：从第一个版本就养成习惯，Savepoint 恢复、算子增删改都依赖它；
5. Checkpoint 超时的排查顺序：先看是否大背压（换 Unaligned Checkpoint / 调 buffer debloat）→ 再看状态是否过大（增量 Checkpoint、TTL）→ 最后看 RocksDB 是否在慢盘上；
6. RocksDB 落盘盘型很重要：放系统盘/普通云盘会明显拖慢状态访问，优先本地 SSD（或云主机本地盘）；
7. 反压定位用 Web UI 的 Backpressure 标签：找到第一个”busy 但吞吐低”的算子，它通常就是瓶颈点；逐条 sleep、外部接口慢是常见根因，异步 IO（Async I/O）是标准解法；
8. keyBy 热点倾斜：思路与 Spark 篇加盐聚合同理（先加随机前缀打散局部聚合，再去前缀全局聚合），另外可用 LocalGlobal / MiniBatch 优化内置方案；
9. 升级作业先测 Savepoint 兼容性：改算子、改状态结构前，在测试环境用生产 Savepoint 演练恢复，别在生产上第一次试。

系列阅读：Kafka 核心原理与实战（数据怎么流起来）→ Spark 核心原理与实战（离线怎么算得快）→ 本文（实时怎么算得准）。三篇合起来，就是大数据流式链路的完整拼图。