01开始前
建议先掌握 SELECT、GROUP BY、主键和 Left Join。阅读只需要浏览器。本地实验还需要终端、Docker 以及源码访问权限。
用四列记录学习过程：预测、动作、观察、解释。本指南中的“预期观察”是需要检验的假设，不是已经保存的运行结果。
02记录与变更
问题：一笔订单被更新三次，业务上有几笔订单，变更流中又有几个事件？在查看源表和服务表之前先写下答案。
阅读 MySQL 表结构与 CDC SQL，再完成订单追踪。解释为什么初始表快照必须衔接持续变更日志中的位置。
- 学习目标：区分当前表、只追加事件历史和带 key 的变更流。
- 自测：重复回放一次变更，与插入两笔不同订单，有什么区别？
- 下一步：观察同一订单在支付前后的状态。
03状态与时间
问题：订单先于支付到达时，Join 需要记住什么？追踪最先输出的行，以及后续被更新的字段。
本项目的常规 Left Join 也会响应客户和商品更新，它不是保留历史“当时值”的时态维表 Join。不要在阅读 SQL 前，就假设旧订单始终保留购买时的维度字段。
- 学习目标：解释 Join 状态、按 key 更新和状态 TTL 带来的取舍。
- 自测：状态过期后才到达的支付，还能按预期关联吗？
- 拓展：单独设计 watermark/窗口练习；当前 SQL 尚未实现这些机制。
04存储与服务
问题：为什么同时需要传输日志和分析表？比较 Kafka 中同一订单的消息更新与 ClickHouse 按唯一订单查询的结果。
再比较 Fluss/Paimon Union Read 与独立 Iceberg 读取，考虑每次查询在其读取时点包含了什么。不要用小规模本地实验推断哪种格式性能更优。
- 学习目标：区分计算、传输、表存储与查询服务的责任。
- 自测：为什么 ClickHouse 原始行数可能与 FINAL 行数不同？
- 拓展：对固定 key 集合进行字段级比较，再判断一致性。
05恢复与证据
问题：Worker 重启后，什么可以证明作业正确恢复？容器变绿只是一个现象，还要检查 checkpoint 历史、作业进度和输出结果。
先获取健康基线。在受控的本地故障中，记录最近完成的 checkpoint、受影响的作业和少量订单 ID。恢复后检查同一批记录，并重新执行批对账。
- 学习目标：区分服务可用、计算恢复和结果验证。
- 自测：行数相同能证明行内容相同吗？两个 sink 可能同时漏掉什么？
- 拓展：定义共同截止时点，比较 key 和金额，并单独验证删除。
06你的学习成果
写下对一笔订单完整旅程的解释，附上实际查询，记录代码版本和运行时间，并说明至少一条证据局限。当另一个人能够沿着你的观察复现检查时，你就完成了这条学习路线。