01一个业务故事，多种数据视图
订单先产生，支付稍后到达，客户还可能修改所在城市。分析系统需要持续跟上这些变化。本项目用合成电商数据，把变化在完整本地链路中的传播过程呈现出来。
MySQL 保存业务记录，Flink CDC 将变更写入 Fluss；Flink SQL 持续维护订单宽表，并写入 Kafka、Fluss/Paimon 和 Iceberg。ClickHouse 提供查询服务，独立批任务重算小时汇总并比较两侧湖表的行数。
02选择你的学习入口
- 刚接触流计算：按“记录与变更 → 状态与时间 → 存储与服务 → 恢复与证据”的路线学习。
- 想理解架构取舍：先看组件职责和一致性边界，再跟踪案例中的一笔订单。
- 准备实际运行：先确认源码权限和机器条件，执行环境诊断，再完成验证步骤。
03在线阅读，本地实验
| 在线阅读 | 获得源码后的本地实验 |
|---|---|
| 双语课程、架构图、SQL 片段和验证说明 | 容器、合成订单、查询控制台和组件原生界面 |
| 可分享、可反复阅读的静态页面 | 使用自己的 CPU、内存、磁盘和 Docker 环境 |
| 不连接在线数据库或管理端点 | 启动、检查、运行案例，停止时保留数据卷 |
04你将能回答的问题
- 流式 Join 为什么在输出一行之后还要保留状态？
- 查询当前表、变更日志和已提交的湖表快照，有什么不同？
- 两个健康的 sink 为什么可能暂时不一致？怎样判断差异值得排查？
- Checkpoint 保护了什么？要证明端到端正确性，还需要哪些证据？
05说明清楚边界的学习项目
这是使用合成数据的单机实验，不是吞吐量基准、生产部署范本或财务对账系统。公开站提供基于源码的说明及明确标注的验证证据，不模拟在线集群。
实现仓库目前是私有仓库。可以访问网页不代表可以 clone 源码。已获授权的协作者可按本地指南运行；其他读者可以直接学习架构、SQL 片段和上游文档。
继续探索
01
先理解概念，再操作组件。
02从问题出发，先预测，再看实现，最后收集证据。每一步都为下一步建立所需的认知。
一条链路，由多个数据契约组成。
03逐层理解它负责什么、保存什么形态的数据，以及在哪个边界上实现一致性。
五个实验，同一套完整系统。
04每个案例包含问题、具体操作、预期观察与结论边界。SQL 在你的本地控制台执行，不在这个网站上运行。
在自己的机器上运行完整实验。
05阅读网站不需要安装。启动组件与完整管理控制台，需要先获得私有实现仓库的访问权限。
清楚知道哪些内容已经检查。
06有用的实验应区分源码检查、实际执行的验证、预期行为和待回答的问题。本页明确这些边界。
回到原始技术说明。
技术说明以实际实现和项目官方文档为依据，优先使用带版本的链接，避免新版手册悄悄改变本实验的含义。