五个实验，同一套完整系统。

01先建立基线

完成本地安装，在修改任何配置前运行 ./stream-lab smoke。打开本地查询控制台，选择对应引擎，使用已有只读预设或下方 SQL。由于生成器持续运行且包含随机性，具体行数与时间会变化。

每个案例都记录订单 ID、查询时间与输出。下文的“预期”描述设计行为，不表示你的环境已经通过验收。

02追踪一笔订单

问题：一笔业务记录在哪里变成多次变更？执行下方 ClickHouse 查询，选定一个 order_id，在 MySQL 预设中找到同一订单，再在 Kafka UI 的 dwd-order-wide 中查看对应 key。

预期：源表、Kafka key 与服务层记录由相同 order_id 串起来，后续消息可能代表不同版本。结合 Flink 作业 records-in/out 观察传播与计算的关系。

解释：消息数不等于订单数。这个案例验证选定记录的路径，不能证明全部记录都完整。

SELECT order_id, order_status, payment_status,
       order_amount, updated_at
FROM analytics.dwd_order_wide FINAL
ORDER BY updated_at DESC
LIMIT 10;

03观察延迟支付更新 Join

问题：没有支付时，Join 为什么已经能产生一行？执行下方 MySQL 查询，找到尚无支付的新订单并刷新，再与 ClickHouse 订单视图比较。

预期：源端最初没有支付行，Join 视图用 PENDING 表示。模拟生成器稍后补入支付，结果可能是 PAID 或 FAILED。配置的延迟只是生成器输入，不是测得的端到端延迟保证。

解释：常规 Left Join 保留状态并更新相同 key 的结果。错过变化时换一笔新订单观察；不要推断每笔订单最终都必须支付成功。

SELECT o.order_id, o.order_status, p.payment_status,
       o.created_at, p.paid_at
FROM orders o
LEFT JOIN payments p ON o.order_id = p.order_id
ORDER BY o.updated_at DESC
LIMIT 10;

04比较持续明细与有界汇总

问题：最新小时汇总为什么可能还没有包含一条新明细？记录最新订单及分类，执行 ./stream-lab batch，再查询 ClickHouse 小时表。

预期：有界作业按订单创建小时和商品分类聚合。gmv 汇总所有选中订单的 order_amount；paid_gmv 只汇总 payment_status = PAID 的订单，二者口径不同。

解释：批作业执行完并被下游摄入后，汇总才更新。后台循环每次尝试结束后等待五分钟，不代表严格的五分钟刷新 SLA。比较前应确认作业完成与结果版本。

-- 随后在 ClickHouse 控制台执行：
SELECT hour_bucket, category, order_count,
       paid_order_count, gmv, paid_gmv
FROM analytics.ads_hourly_sales FINAL
ORDER BY hour_bucket DESC, gmv DESC
LIMIT 20;

05对比两条湖表路径的行数

问题：行数对账能说明什么？执行 ./stream-lab batch，再查看最新审计行。输入分别是 Fluss/Paimon Union Read 表和独立 Iceberg 表。

预期：count_delta 等于 paimon_fluss_count 减去 iceberg_count。当 sink 暴露的处理进度不同，差值可能非零。记录两侧行数和 audit_time，待链路追上后重复检查。

解释：零差值只说明这些读取返回相同行数，不证明 key 集合或字段值一致。持续差异需要排查 checkpoint、sink 提交和 tiering。更强验证应选择固定数据集合或共同截止时点，并进行字段级比较。

SELECT audit_time, paimon_fluss_count, iceberg_count, count_delta
FROM analytics.lake_consistency_audit FINAL
ORDER BY audit_time DESC
LIMIT 1;

06受控中断 Worker 并恢复

问题：恢复后的计算是否产生预期记录？先确认流作业运行且存在完成的 checkpoint。只在本地实验环境内操作，并记录故障前的基线。

使用下方命令短暂中断 TaskManager 后重启。在本地 Flink UI 观察作业状态和 checkpoint 历史，再执行 smoke 与 batch 检查，并回看此前记录的订单。

预期：配置的重启策略会尝试恢复。同一个运行会话内的任务故障，与重建整个集群不同。当前部署未配置 JobManager 高可用，仅保留 Docker 数据卷并不能证明每次重新打开作业都会从旧 checkpoint 接续。

解释：记录实际恢复结果，包括失败。不能把进程健康或行数差为零描述为全链路 exactly-once 的证明。

./stream-lab compose stop taskmanager
# 在本地 Flink UI 查看故障状态。
./stream-lab compose start taskmanager
./stream-lab smoke
./stream-lab batch