流式数据处理 — 系列规划

本文是写作规划，不是可发布正文。拆解对象分两层：消息日志与流式传输（Kafka 主线）与流计算引擎（Flink 主线，Kafka Streams / Spark Structured Streaming / RisingWave 对照）。不写 SQL 语法教程，不写云托管 Flink/Kafka 定价与内部实现。

关联文档：index.md（读者入口）。本文件聚焦逐章大纲、来源台账、实验台账与写作顺序。

续作关系：承接 lakehouse 第 19 章——该章只讲入湖侧（sink、CDC upsert、小文件）；本系列讲引擎侧（事件时间、watermark、窗口、状态、checkpoint、背压、端到端语义）。

一、为什么写这个系列

1.1 数据平台栈的缺口

结论：lakehouse 闭合了「批式数据在对象存储上怎么当表用」；但实时链路里 Kafka 怎么保证顺序与持久、Flink 怎么在有乱序的情况下算对窗口、状态存在哪、checkpoint 怎么对齐 exactly-once——全站没有系统拆解。读者把 CDC 写进 Iceberg 之后，仍会卡在「作业为什么背压、状态为什么膨胀、重启为什么重复消费」。

1.2 为什么选 Kafka（主）+ Flink（主）

选 Kafka + Flink 作主线：2024–2026 数据平台实时链路的事实默认组合；对照章各用一章讲清边界，不做排名。

1.3 系列定位

流式数据平台 = 持久日志（Kafka）+ 有状态计算（Flink）+ 交付语义（EOS）+ 下游衔接（湖 / OLTP / 服务）

不写：

• Flink SQL / Kafka Streams DSL 语法大全
• Spark Streaming DStream 遗留 API
• 云厂商 Managed Flink / MSK 内部调度与定价
• Flink CE 商业特性

写：

• 事件时间与 watermark 如何在乱序下仍保证窗口正确性
• Kafka 分区、ISR、consumer group 与事务 producer 各自保证什么
• Flink checkpoint 如何把算子状态与 source offset 绑在同一一致性点
• RocksDB state backend 的读写路径与增量 checkpoint
• 端到端 exactly-once 如何把「引擎 checkpoint」与「Iceberg 提交」对齐（深化 lakehouse/19）
• 背压、数据倾斜、状态膨胀等生产故障模式

二、核心问题与目标读者

2.1 六个关键问题

1. 流处理与批处理/微批的本质差异是什么？延迟、语义、状态各差在哪？ → 第 1 章：全景、Lambda/Kappa 边界、流表对偶。

2. 事件时间、watermark、窗口如何在乱序到达时仍算对？ → 第 2、3 章：三种时间语义、watermark 生成与迟到数据处理、滚动/滑动/会话窗口。

3. Kafka 的分区、副本、consumer group 各自保证什么，不保证什么？ → 第 4、5、6 章：日志结构、ISR、rebalance、事务 producer。

4. Flink 的状态存在哪，checkpoint 如何把状态与 offset 绑在一起？ → 第 9、10、11、13 章：KeyedState、CheckpointCoordinator、RocksDB state backend、savepoint。

5. at-least-once 与 exactly-once 的边界在哪，端到端怎么做到？ → 第 12、14 章：语义层级、两阶段提交 sink、与 lakehouse 提交协议的对齐。

6. 流作业怎么运维——背压、倾斜、状态膨胀、入湖小文件？ → 第 15、16、17 章：背压传播、Debezium CDC 管道、入湖深化、故障模式清单。

2.2 目标读者

• 数据平台 / 实时工程师，维护 Kafka + Flink 管道，或从 batch ETL 转 stream。
• 后端工程师，要把 CDC、实时聚合、实时特征接到业务或湖仓。
• 先修：基本分布式概念（建议 distributed/ 日志复制相关篇）、lakehouse 第 19 章或同等入湖直觉。
• 不假设：写过 Flink 算子或调过 Kafka 副本。

三、篇目结构（全 18 篇）

第一部分：流处理基础（第 1–3 篇）

第 1 篇：流处理全景：从日志到有状态计算

• 批 vs 流 vs 微批：延迟、吞吐、语义、状态四个维度对比。
• 数据流作为「可重放日志」的心智模型；与 lakehouse「不可变文件 + 元数据指针」的对称。
• Lambda / Kappa 边界：本系列站在 Kappa「日志即真相」侧，但不否定批式回补。
• 全系列地图：Kafka 传输层 → Flink 计算层 → 语义层 → 入湖/服务衔接层。
• 来源：Kafka 设计文档、Flink 论文（Dataflow Model）、Vijay 流处理书籍（标注章节）。

第 2 篇：事件时间、处理时间与 Watermark

• 三种时间语义：event time / processing time / ingestion time。
• Watermark 定义：\(W(t)\) 表示「认为 \(\leq t\) 的事件已到齐」的进度标记。
• Watermark 生成策略：bounded out-of-orderness、periodic vs punctuated。
• 迟到数据：侧输出（side output）、allowed lateness、truncate vs 更新结果。
• 来源：Flink Documentation Timely Stream Processing、Dataflow Model 论文。A 级。
• 实验：构造乱序事件流（Python 脚本生成带 timestamp 的 JSON），Flink 作业对比 event-time 与 processing-time 窗口输出（标注 Flink 版本、并行度）。

第 3 篇：窗口：滚动、滑动与会话

• WindowAssigner 三类：Tumbling / Sliding / Session（gap 参数）。
• 窗口触发（Trigger）与清理（Evictor）对结果的影响。
• GlobalWindow + 自定义 Trigger 的适用边界。
• 与批式 GROUP BY 时间分桶的对照：状态驻留 vs 每批重算。
• 来源：Flink Documentation Windows、源码 WindowOperator。A 级。
• 实验：同一 keyed 流上三种窗口的 state 大小与输出条数对比（真实 metrics，≥3 轮）。

第二部分：Kafka 内核（第 4–6 篇）

第 4 篇：Kafka 日志模型与分区

• Topic → Partition → Log Segment：.log + .index + .timeindex 文件布局。
• Offset 单调性、顺序写、页缓存与 zero-copy（sendfile）读路径。
• 分区键与有序性保证：分区内有序、分区间无序。
• KRaft 与 ZK 模式边界（版本锚定 Kafka 3.x+，KRaft 为默认方向）。
• 来源：Kafka Documentation Design、apache/kafka LogSegment、RecordBatch。A 级。
• 实验：本地 KRaft 单节点，用 kafka-dump-log.sh dump segment，记录 offset/ltimestamp/baseOffset。

第 5 篇：副本、ISR 与 Consumer Group

• Leader/Follower、HW/LEO、ISR 收缩与 min.insync.replicas。
• 生产者 acks=0/1/all 与 durability/latency 取舍。
• Consumer group、分区分配（Range/Sticky/Cooperative）、rebalance 代价。
• Offset 提交：auto commit vs 手动 commit；与 Flink checkpoint 的分工。
• 来源：Kafka Documentation Replication、Consumer；KIP 相关。A 级。
• 实验：停 follower 观察 ISR；consumer group rebalance 日志与 lag 变化。

第 6 篇：Kafka 事务与幂等 Producer

• 幂等 producer：pid + sequence number 去重。
• 事务 producer：initTransactions / beginTransaction / commitTransaction / abortTransaction。
• transactional.id、__transaction_state 内部 topic、与 consumer isolation.level=read_committed。
• Kafka EOS 与 Flink EOS 的衔接点（为第 14 篇铺垫）。
• 来源：Kafka Documentation Transactions、KIP-98。A 级。
• 实验：事务 abort 后 read_committed consumer 看不到未提交消息；对比非事务重复 send。

第三部分：Flink 运行时与状态（第 7–11 篇）

第 7 篇：Flink 运行时模型

• JobManager / TaskManager / Slot / Pipeline 与 ExecutionGraph。
• Operator chain 与 task 合并：减少序列化与线程切换。
• 并行度、SlotSharingGroup、资源隔离边界。
• 与 Spark driver/executor 的对照（点到为止，详见第 18 篇）。
• 来源：Flink Documentation Architecture、源码 StreamGraph → JobGraph。A 级。

第 8 篇：DataStream 与算子语义

• Source / Transformation / Sink 数据流图；One-to-One vs Rebalance / KeyGroup / Broadcast shuffle。
• keyBy 如何决定 KeyGroup 与 state 分片。
• ProcessFunction / TimerService：事件时间与 processing 时间定时器。
• 算子状态（Operator State）vs 键控状态（Keyed State）初探。
• 来源：Flink Documentation DataStream API。A 级。
• 实验：不同 shuffle 策略下 subtask 接收记录数分布（验证 keyBy 倾斜前兆）。

第 9 篇：键控状态与状态 TTL

• ValueState / ListState / MapState / ReducingState / AggregatingState 语义。
• StateBackend 抽象：HashMapStateBackend vs EmbeddedRocksDBStateBackend 选型。
• State TTL：过期策略、可见性、与 checkpoint 的交互。
• 状态大小估算：窗口 state + RocksDB 实际磁盘占用。
• 来源：Flink Documentation State、State TTL。A 级。

第 10 篇：Checkpoint 机制

• Chandy-Lamport 快照在流管道中的变体：aligned vs unaligned checkpoint。
• CheckpointCoordinator 生命周期：trigger → barrier 注入 → ack → complete。
• Source 参与：Kafka source 如何把 offset 写入 checkpoint。
• checkpoint 超时、最小间隔、并发 checkpoint 数调优。
• 来源：Flink Documentation Checkpointing、Flink 源码 CheckpointCoordinator。A 级。
• 实验：调 execution.checkpointing.interval，观察 end-to-end latency 与 checkpoint duration（Flink REST metrics）。

第 11 篇：Savepoint 与升级恢复

• Savepoint vs Checkpoint：手动触发、格式保留、跨版本升级。
• 状态兼容：新增/删除算子、改并行度、rescale 的规则与限制。
• 作业 cancel with savepoint、从 savepoint 启动、状态不可读时的排查。
• 来源：Flink Documentation Savepoints、State Evolution。A 级。

第四部分：RocksDB 状态后端（第 12–13 篇）

第 12 篇：RocksDB State Backend 内核路径

• EmbeddedRocksDBStateBackend：每个 subtask 独立 RocksDB 实例、ColumnFamily 与 KeyGroup 映射。
• 写路径：memtable → WAL → flush → compaction；与 db/lsm-tree 系列对照。
• 读路径：block cache、iterator 开销；大 state 下的读放大。
• 增量 checkpoint：SST 文件上传 vs 全量 snapshot 的 IO 差异。
• 来源：Flink Documentation RocksDB State Backend、rocksdb-statebackend 源码；RocksDB Wiki。A 级。
• 实验：同一作业 HashMap vs RocksDB backend 的 checkpoint 大小与 duration 对比（标注 state 规模）。

第 13 篇：状态放大、Compaction 与调优

• 窗口 state + 长 TTL 导致的磁盘膨胀。
• RocksDB 写放大与 compaction 压力；write-buffer-size、max-background-jobs 在 Flink 场景的取舍。
• 状态访问倾斜（hot key）与 subtask 负载不均。
• 何时该换 state 设计而不是只调 RocksDB 参数。
• 来源：Flink ops 文档、RocksDB Tuning Guide；生产复盘（B 级，标注来源）。A/B 级。
• 实验：构造大窗口 state，观察 RocksDB live-sst-files 与 checkpoint 体积随时间曲线。

第五部分：交付语义与 CDC（第 14–15 篇）

第 14 篇：交付语义：从 at-most-once 到 exactly-once

• Source / 引擎 / Sink 三层语义组合；端到端语义由最弱环决定。
• Flink：AT_LEAST_ONCE vs EXACTLY_ONCE checkpoint 模式。
• 重复消费、重复写入、幂等 sink 三类修复手段。
• 来源：Flink Documentation Fault Tolerance Guarantees、distributed/ 一致性相关篇（引用，不重复证明）。A 级。

第 15 篇：两阶段提交与端到端 Exactly-Once

• GenericTwoPhaseCommitSink 协议：beginTransaction / preCommit / commit / abort。
• Kafka sink、JDBC sink、Iceberg sink 各自 2PC 落点。
• 与 lakehouse 第 11 章 Iceberg catalog CAS、第 19 章 checkpoint 提交的对称叙述（深化，不重复入湖全文）。
• 失败场景：commit 前崩溃、commit 后崩溃、下游重复 commit 的幂等。
• 来源：Flink Documentation Two-Phase Commit、Iceberg Flink sink 源码。A 级。
• 实验：Flink Kafka → Kafka EOS pipeline，杀 TaskManager 后验证无重复无丢失（计数器 sink，标注环境）。

第六部分：CDC、入湖与运维（第 16–17 篇）

第 16 篇：Debezium 与 Change Data Capture

• CDC 事件结构：op（c/r/u/d）、before/after、source metadata、schema change。
• Snapshot 阶段 vs streaming 阶段；initial / never / when_needed 语义。
• Kafka Connect + Debezium 架构：connector task、offset topic、schema history topic。
• 与 lakehouse 第 19 章 upsert 的衔接：引擎侧如何保证顺序与幂等键。
• 来源：Debezium Documentation；MySQL binlog / PG logical replication 官方文档。A 级。
• 实验：本地 MySQL + Debezium → Kafka topic，dump 一条 u/d 事件 JSON（真实输出，可删减）。

第 17 篇：流式入湖深化（与 Lakehouse 第 19 章对读）

• 从引擎侧重述：checkpoint 间隔 ↔︎ 提交频率 ↔︎ 小文件；背压如何传导到提交延迟。
• Flink 写 Iceberg/Hudi 的并行 writer 与 commit 冲突；与 lakehouse/11 乐观并发重试。
• 写端预聚合、bucket 分区、异步 compaction 调度——引擎参数与表治理的配合。
• 明确分工：lakehouse/19 讲表格式提交协议；本篇讲「作业侧旋钮」。
• 来源：Iceberg Flink 文档、lakehouse 系列第 17/19/20 章（内部链接）。A 级。

第 18 篇：背压、故障模式与引擎对照

• 背压：credit-based flow control、反压传播链、如何读 Web UI/backpressure 比例。
• 常见故障：数据倾斜、checkpoint 超时连锁、Kafka rebalance 风暴、状态 backend OOM、savepoint 不兼容。
• 引擎对照表（带口径）：Flink vs Kafka Streams vs Spark Structured Streaming vs RisingWave——状态模型、语义、运维复杂度、入湖成熟度。
• 选型决策树，不做排名。
• 来源：各引擎官方文档；公开事故复盘（B 级）。A/B 级。

四、依赖关系

1 → 2 → 3
1 → 4 → 5 → 6
1 → 7 → 8 → 9 → 10 → 11
9 → 12 → 13
6,10 → 14 → 15
5,15 → 16 → 17
3,13,17 → 18

跨系列：

db/lakehouse/19 ──→ 15, 17（入湖语义深化）
db/lsm-tree/    ──→ 12, 13（RocksDB 对照）
distributed/    ──→ 5, 14（复制与一致性直觉）

五、阅读路径

六、来源台账

A 级

• Apache Kafka Documentation（Design、Replication、Consumer、Transactions、KRaft）。
• Apache Flink Documentation（Architecture、DataStream、Timely Stream Processing、Windows、State、Checkpointing、Savepoints、RocksDB State Backend、Fault Tolerance、Two-Phase Commit）。
• apache/kafka、apache/flink 源码（标注 release 版本）。
• Debezium Documentation（含 MySQL/PostgreSQL connector）。
• Apache Iceberg Documentation Flink Writes（与 lakehouse 系列交叉引用）。
• RocksDB Wiki / Tuning Guide。
• Dataflow Model 论文（Akidau et al.）。

B 级

• Confluent / Ververica 工程博客（须标注版本与日期）。
• 公开事故复盘（Kafka rebalance 风暴、Flink checkpoint 失败连锁等）。

禁止

• 无版本上下文的「Flink 比 Spark 快 N 倍」营销页单独支撑结论。
• 未实测的吞吐/延迟数字写进正文。
• 伪造 kafka-console-consumer / Flink Web UI 截图输出。

七、实验台账

每个 benchmark：CPU、内存、OS、组件版本、数据规模、采样轮次（≥3，取中位数）；无法在本机执行的实验按 lakehouse/19 惯例写清环境限制，给出可复现步骤但不伪造输出。

八、系列联动

九、边界

不承诺

• 替代 Kafka / Flink 官方文档。
• 云厂商 Managed Service 内部实现。
• Flink SQL 优化器、Calcite 集成全文。
• Pulsar / Redpanda 独立成篇（可在第 18 篇对照表一句带过）。

承诺

• 以「日志 + 有状态计算 + 交付语义」内核视角组织。
• 关键结论锚定官方文档、源码或实测。
• 与 lakehouse/19 明确分工，避免重复粘贴。

十、写作顺序

1. index.md（已完成则随 PLAN 同步）
2. 第 1 篇（全景，不依赖实测）
3. 第 4、5、6 篇（Kafka 层，Docker 环境可共享）
4. 第 2、3 篇（时间语义，需 Flink）
5. 第 7、8、9 篇（Flink 基础）
6. 第 10、11 篇（checkpoint/savepoint）
7. 第 12、13 篇（RocksDB state）
8. 第 14、15 篇（语义与 2PC）
9. 第 16、17 篇（CDC 与入湖深化，回调 lakehouse）
10. 第 18 篇（背压、故障、对照收束）

十一、已确认决策（2026-07-01）

1. 系列规模：18 篇（与 zero-trust/agent-identity 体量接近，比 lakehouse 精简；Kafka 4–6 合并为 3 篇而非单独 4 篇）。
2. 版本锚定：Kafka 3.x（KRaft）；Flink 1.20+ / 2.x 主线，API 变更处标注版本边界。
3. 引擎主线：Flink DataStream；SQL 仅作示例，不单独成篇。
4. 入湖边界：第 17 篇与 lakehouse/19 对读，不重复表格式提交协议全文。
5. RocksDB：第 12–13 篇衔接 db/lsm-tree，不另开 RocksDB 独立系列（该系列留作可选后续）。

规划版本：v1，2026-07-01（全 18 篇）
目录：post/stream-processing/