题目与使用场景
数据“有值”不等于“新鲜”。面试重点是把业务可用时间转成可计算指标，并能定位延迟发生在采集、传输、处理还是发布环节。
面试官考察什么
- 是否区分事件时间、到达时间、处理完成时间和服务时间。
- 是否按数据集、分区和业务用途定义不同 SLO。
- 是否记录血缘、运行、质量和新鲜度证据。
- 是否避免把单次任务成功当成数据可用。
- 是否设计告警抑制、升级、补数和回放路径。
- 是否把新鲜度违约连接到下游用户影响。
作答前的澄清问题
- 数据集的业务截止时间、更新频率和时区是什么？
- 新鲜度从事件发生、落地还是可查询开始计算？
- 哪些分区、字段和下游报表是关键路径？
- 允许的延迟、缺口和回补窗口是多少？
- 上游是否能提供事件时间、批次 ID 和重试信息？
- 违约时需要冻结报表、标注数据还是继续服务？
30 秒回答框架
“我先按业务截止时间定义可查询新鲜度，并分别记录事件时间、落地时间和发布时间。每个关键数据集按分区计算 freshness SLI，结合血缘、运行状态、行数和质量断言定位延迟来源。告警分为预警与违约，避免任务成功但数据缺口仍被隐藏。恢复路径包括重试、补数、回放和下游标注，并用用户影响和 SLO 预算衡量改进。”
分步骤深入解答
步骤 1：定义时间语义。 明确事件时间与可查询时间，处理迟到事件、时区和夏令时，避免只使用作业结束时间。
步骤 2：定义 SLI/SLO。 例如按分区计算“在截止时间前可查询的比例”，为关键报表与探索性数据设置不同目标和窗口。
步骤 3：收集运行证据。 记录作业运行、输入输出分区、血缘、行数、空值和质量断言；运行元数据应能关联到具体数据版本。
步骤 4：定位延迟。 将端到端延迟拆为采集、传输、排队、计算和发布，区分上游没有数据与下游处理失败。
步骤 5：设计告警。 预警关注剩余时间和趋势，违约关注实际影响；按数据集和分区去重，设置静默、升级和负责人。
步骤 6：恢复与回放。 使用幂等批次、断点和补数范围，修复后重跑受影响分区；对外明确数据状态和更新时间。
步骤 7：复盘改进。 统计 SLO 预算消耗、根因占比和误报，调整调度、容量、分区策略或数据产品承诺。
高质量示范回答
“这张收入报表的业务截止时间是每天 08:00，本地时区。我们把 freshness 定义为当天分区在 08:15 前可查询，并额外记录事件时间到落地时间的延迟。监控从作业元数据读取输入输出分区、血缘、行数和质量断言；如果作业成功但某分区没有到达，仍判为新鲜度风险。08:00 前按剩余时间预警，08:15 后按报表影响升级。恢复时按批次 ID 幂等补数并标记报表状态，复盘时按采集、传输和计算根因统计预算消耗。”
常见错误
- 只监控任务成功 → 隐藏分区缺口 → 检查可查询分区和业务截止时间。
- 只用处理结束时间 → 迟到事件被误判 → 保留事件、落地和发布时间。
- 所有数据集一个阈值 → 业务优先级丢失 → 按用途和关键路径分级。
- 告警没有责任人与升级 → 发现后无人处理 → 绑定负责人、窗口和恢复动作。
- 补数直接覆盖 → 重复或版本不明 → 使用幂等批次、范围和版本记录。
追问及应对
追问 1：上游没有事件时间怎么办？
先使用落地时间作为临时指标并标注局限，推动上游补充事件时间和批次元数据。
追问 2：数据迟到但用户暂时不受影响？
同时记录技术 SLI 与用户影响，按业务承诺决定是否消耗预算，避免只看单一指标。
追问 3：如何避免告警风暴？
按数据集和血缘聚合根因告警，使用预警窗口、去重、静默和升级策略。
追问 4：补数期间下游怎么办？
发布数据状态与更新时间，冻结或标注关键报表，禁止下游把不完整结果当最终值。
追问 5：怎样验证 SLO 真的代表业务？
回访报表使用者，比较违约与决策延误、客户影响等结果，并定期校准窗口。
追问 6：迟到数据会改变历史分区怎么办？
定义回补窗口和版本语义，记录重算范围，通知下游缓存与增量模型。
追问 7：最有价值的改进是什么？
优先修复占用最多预算且能影响关键用户路径的根因，而不是只追求更多仪表盘。