01本版内容可以支持什么结论
| 证据类型 | 可以支持 | 不能证明 |
|---|---|---|
| 源码检查 | 本指南所描述的拓扑、SQL 定义和配置 | 所有机器均可成功执行，或所有工作负载下连接器都兼容 |
| 保存的静态契约检查 | 验证文件记录的八项配置断言及对应源码文件哈希 | 在线链路健康、SQL 实际执行或数据正确性 |
| 案例中的预期观察 | 可复现的步骤和解释方式 | 一次真实运行中测得的结果 |
| 运行实验记录 | 该次运行明确保存的输出、环境与断言 | 普遍的 exactly-once、性能或生产就绪保证 |
02历史运行证据
原仓库包含脚本和指南，但没有提交可证明过去端到端成功运行的结果包。因此公开课程不会把旧 README 描述的预期行为直接当成测量结果。
发布验证是独立产物，请查看其范围、状态与时间戳。页面构建、链接检查或 shell 测试成功，只能证明相应的项目检查通过，不能替代实际运行数据链路。
当前保存记录显示八项静态检查通过；Docker daemon 不可用，因此 runtime_tested = false。SQL 版本表达式的修正经过静态检查，未在真实 Flink 作业中执行。
03让下一次运行可核查
- 记录源码 commit、镜像 tag、操作系统、CPU 架构、Docker 资源和时区。
- 保存命令、退出码、开始与结束时间，以及支持结论所需的最小输出。
- 数据检查记录订单 ID、SQL、查询时间、两侧湖表行数和审计时间。深入比较时使用固定数据集合。
- 恢复实验记录故障组件、作业状态变化、最近完成的 checkpoint，以及恢复后检查的记录。
- 原始日志与配置留在本地。分享前删除凭据、个人目录、内部地址和无关记录。
- 结果标记为通过、失败或未运行；保留异常结果，解释尚未消除的不确定性。
04值得进一步验证的已知局限
- 生成器随机且持续运行，不会在每次运行中产生完全相同的测试数据。
- 行数对账没有共同快照或字段级 checksum；行数相等只是一项较弱的一致性信号。
- Join 状态按 TTL 过期，尚未实现明确的事件时间迟到策略。
- ClickHouse 入库没有将 Kafka tombstone 映射为行删除，TTL 清理不等同于源端删除传播。
- 修订后的宽表版本包含订单、支付和维度时间戳，并保留毫秒精度；同一毫秒内更新或源端时钟不一致仍可能导致并列或错序，它不是事务序列。
- Iceberg 使用本地共享文件系统 catalog，没有定期快照过期或完整七天磁盘保留保证。
- 集群是单机部署，未配置 JobManager 高可用；任务重启与整个集群重启检验的是不同恢复边界。
05让结论与证据强度匹配
合适的结论：“恢复后，这些已记录的订单 ID 在源端与 FINAL 服务查询中一致。”更强的结论：“在这个截止时点，对固定数据集合进行 key 和指定字段比较，检查通过。”
仅凭绿色看板或 count delta 为零，就声称“全链路 exactly-once”“Paimon 比 Iceberg 更快”或“全部数据七天后删除”，都超出了证据支持范围。