题干与适用场景
这是数据平台与分析工程岗位常见的质量治理题。重点是把“数据可靠”拆成可测量的维度，连接到下游用途和处置动作，而不是只列出几个检查脚本。
面试官考察什么
- 能否区分新鲜度、完整性、有效性、准确性、一致性和唯一性。
- 能否按数据产品和消费者定义不同的时间与质量目标。
- 能否设计检测、分级告警、暂停下游和恢复后的补算流程。
- 能否保留质量证据、版本和血缘，避免把警报变成噪音。
回答前需要澄清的问题
先确认数据是批处理还是流式，业务时间与到达时间分别是什么；哪些表或字段面向客户、财务或模型；允许多长时间的延迟；是否存在回填、迟到分区和时区；以及异常时下游应阻断、降级还是显示最近一次可信快照。
30 秒回答框架
我会先按消费者用途定义数据契约，再为每个数据集配置新鲜度、数量、完整性和有效性规则。采集与转换过程中写入质量结果和血缘，按警告与阻断分级通知负责人；下游读取质量状态，必要时阻止发布并保留上一份可信快照。恢复后通过回填、重算和对账关闭事件。
分步骤深入解答
1. 把质量维度绑定到用途
新鲜度回答“最近一次可用数据何时产生”，完整性回答必需字段或分区是否齐全，数量检查预期行数或字节量，合法性检查格式与范围，一致性检查跨表关系，唯一性检查重复。不要给所有表套同一阈值；支付结算、运营看板和离线训练的容忍度不同。
2. 定义可执行的 SLA 与 SLO
为每个数据集记录业务截止时间、最大延迟、允许缺失比例、阻断条件、责任人和升级时间。区分“数据已到但未通过质量检查”和“上游根本没有新数据”，分别统计。对迟到数据给出允许回填窗口，超过窗口后明确标记不可用，避免把无限等待当成 SLA。
3. 将检查结果作为带版本的证据
每次运行保存规则版本、数据批次或分区、观测值、阈值、运行时间、输入输出血缘和结果。规则可用 Expectation 或同类声明式定义，并把结果写入可查询的质量账本。规则变更要评估历史基线，防止仅因阈值调整就掩盖退化。
4. 设计告警、阻断与降级
告警按影响范围和严重度路由给数据负责人、平台值班和业务消费者。可恢复的单分区缺失先标记延迟并保留上一份可信快照；会污染财务或模型的完整性、有效性失败应阻断发布。每个阻断都要有超时升级、手工批准和解除条件，避免消费者绕过检查。
5. 用回填和对账完成闭环
修复上游后按分区或业务时间回填，重跑相同版本的转换与质量规则，记录补算批次，避免重复写入。用输入行数、输出行数、拒绝数、迟到数和下游消费数对账；恢复后检查质量指标回到基线，并在复盘中调整规则、阈值或责任边界。
高质量示范回答
我会先按消费者定义数据契约。结算表要求在每日截止后一小时内到齐，核心字段完整率必须达到阈值；探索性看板可以容忍更长延迟。每个数据集配置新鲜度、分区数量、必填字段、范围和跨表一致性检查，保存规则版本、观测值、批次、血缘和责任人。新鲜度超时先发警告，财务表的完整性失败则阻断发布并提供上一份带时间戳的可信快照。上游修复后按业务时间回填，复用同一转换和检查版本，用输入、输出、拒绝和消费计数对账，确认指标恢复后关闭事件。这样消费者知道数据是否可用，团队也能区分延迟、质量失败和规则变更。
常见错误
- 只监控任务是否成功，不检查数据是否新鲜、完整和有效。
- 给所有数据集设置一个全局阈值，不考虑消费者和业务截止时间。
- 把质量结果写在日志里，无法关联批次、规则版本和血缘。
- 所有失败都阻断全部下游，导致局部问题扩大成全局停摆。
- 修复后直接覆盖历史，没有回填批次、对账和重复写入保护。
- 只报一个质量分数，消费者不知道具体哪一维不可用。
追问及应对
上游没有新数据，但任务仍然成功怎么办？
用到达时间和业务时间分别检查，并以最后可信分区和预期更新频率判断新鲜度。任务成功只能说明代码运行，不代表数据满足 SLA；超时应产生质量事件。
质量规则本身误报怎么办？
保留观测值、阈值和规则版本，先在影子模式观察基线，再使用分层阈值和异常比例触发。误报事件要记录消费者影响，经过评审后调整规则，不能静默关闭告警。
是否应该阻断所有下游？
按血缘和用途分级。会污染结算或模型的失败可阻断相关发布，独立的探索性数据可以继续使用带警示的上一版本；阻断范围和解除条件都要可审计。
如何证明恢复后没有漏数？
对账批次、分区、输入输出行数、拒绝记录、迟到记录和下游消费数，并抽样核对主键集合。回填批次必须可重放、可追踪，重复执行应得到相同结果。