题目重点：从数据生产到可消费数据集拆解批流链路，讨论事件幂等、晚到、schema 变化和质量故障。
题意与假设
这道练习题保留了面经中值得训练的核心约束，并将需要澄清的条件单独列出。现场拿到变体时，先和面试官确认这些条件。
- 训练场景为多个手机应用事件进入分析仓库，支撑日报和近实时指标；原题可能是其它业务数据，须在面试中先确认。
- 目标设为最终可重算的指标数据，不默认每条事件恰好一次到达；以稳定 event_id 和版本标记支撑幂等。
解题路线
- 先问 producer、事件量、峰值、schema、保留期限、可接受延迟、数据权限与消费者 SLA，再确定批处理、流处理或混合。
- 摄入入口做身份验证、限流与 schema/version 检查，把原始不可变事件持久保存；确认接收仅表示已持久入队，不能等同已进入最终看板。
- 转换层基于 event_id 去重，按事件时间和处理时间处理晚到，校验字段缺失/异常，生成有版本的数据集；错误记录入隔离队列并有修复/回放流程。
- 批处理可以重算历史真值，流处理服务较低延迟指标；两条链路要共享定义并定期对账。血缘记录输入版本、代码版本与输出分区，支持回滚和重放。
- 监控摄入吞吐、积压、端到端延迟、去重率、坏行率、分区缺失和消费者 SLA；定义数据事故时的影响范围与告警责任人。
手动走一遍
手机离线两小时后补发同一 event_id 两次：入口可接收重试，但下游只计一次，并按原事件时间写入正确日期分区。若晚到超过实时窗口，批回填修正日报并记录重算版本。
规模与取舍
处理 E 条事件至少 O(E)，原始与规范化双份存储按保留天数与压缩率增长；峰值 QPS、event 大小和时效决定分区/队列容量。题目无规模，不能给固定 broker 数量。
易错点与追问
容易失分的边界
- 把消息队列投递成功误说成业务指标已准确入仓。
- 没有 event_id，离线重试导致重复计数。
- 只按处理时间分区，晚到数据被归错天。
- 改 schema 无版本策略，旧客户端事件突然解析失败。
- 流式和批式指标口径不同却不对账。
继续深挖
- 历史数据修复时如何不重复触发下游副作用？
- 怎样在不丢数据的情况下变更事件 schema？
- 何时需要流式，何时按小时批处理足够？
- 如何追踪一个看板数字来自哪批原始事件和代码版本？
