题干与适用场景
一张日批 factordersettlements 表每天处理约 1000 万条订单事件，来自 12 个源系统。财务团队在 UTC 07:00 开始关账。当前编排系统只汇报任务是否完成，所以绿色状态仍可能对应延迟分区、整个源缺失、订单版本重复，或汇总金额与源端不一致。
请设计数据质量 SLO 以及落实这些目标的控制措施。每个源系统会提供控制清单，其中包含源、币种和业务日期维度的记录数与总金额。原始事件可重放 30 天，修正数据可能在 24 小时内到达。两个消费者的要求不同：财务只能使用已认证数据，分析师可以使用明确标记的预览数据。
回答需要覆盖 SLI、目标值、规则执行位置、发布门禁、责任归属、告警路由、错误预算动作、故障恢复和上线验证。1000 万条事件、12 个源、截止时间、保留期和文中的目标值都是面试假设；生产目标需要消费者共同确认并由历史测量校准。本题的核心能力是为数据产品建立可运行的质量契约，因此归入 data。这套工作从故障发生前开始，一直延伸到认证和策略复审。
面试官考察点
第一，候选人能否把“数据质量高”改写成可观测的消费者结果。新鲜度、完整性、有效性、一致性、准确性和唯一性对应不同故障。一个综合质量分可能用多条通过的规则掩盖一条零容忍的重复记录。
第二，候选人能否选择可信的分母。拿今天行数和昨天比较可以发现大幅异常，却无法证明完整性。源端控制清单、变更日志偏移区间或独立账本更能说明本来应该到达什么。
第三，候选人能否区分 SLI 规格和测量实现。“财务在关账前拿到已认证数据”描述消费者结果；只测调度任务结束时间会漏掉发布、目录、权限和下游读取失败。强回答会在接近消费者的边界测量，并写清测量盲区。
第四，每种失败是否已经对应预定动作。硬性不变量需要阻断发布或隔离数据；警告需要负责人和复核路径；呼叫告警应该代表紧急的消费者影响。“每条规则失败都告警”会把设计责任推给值班人员，并制造噪声。
最后，候选人能否让责任分工真正可执行。生产方、平台工程师、数据集负责人和财务可以共同承担质量责任，但每条规则、每次故障和每项豁免仍需要一个直接负责人和升级路径。
回答前需要澄清的问题
- 财务所说的“就绪”是什么？ 如果关账必须在 07:00 使用已认证数据，就要测量财务何时能查询认证版本，而非最后一个转换任务何时退出。如果预览有价值，应使用独立状态和契约发布。
- 哪项独立证据定义完整性和正确性？ 源端清单可以支持记录数与金额对账。没有清单时，可使用偏移量、源快照或账本总额；统计量波动检查只能标为异常检测，不能当作完整性证明。
- 业务键和更新模型是什么？ 唯一性可能约束
(sourceid, orderid, version)，订单当前状态则需要每个订单选出获胜版本。延迟修正会同时改变检查逻辑和认证生命周期。 - 哪些失败可以降级，哪些必须阻断？ 业务键缺失、版本重复或账本不一致会破坏关账，应该阻断认证。可选营销属性异常时，可以隔离受影响记录并继续认证财务字段。
- SLO 窗口里有多少个质量事件？ 日批管道每月观测点太少，无法有意义地表达 99.9%。滚动 60 个工作日中至少 59 次按时认证，粒度更容易解释。
- 谁可以绕过失败门禁？ 豁免需要审批人、受影响消费者、到期时间、理由和审计记录。值班工程师不能在事故中静默改写财务契约。
- 系统具备什么恢复能力？ 30 天原始数据重放支持确定性重建。如果源端历史可变或不完整，恢复方案和证据要求也要调整。
30 秒回答框架
“我会先从财务要做的决策出发，再分别定义已认证数据的新鲜度、源端清单对账、业务键完整性、有效性和唯一性 SLI。我会在消费者边界测量已认证表，并把零容忍的财务不变量与允许使用错误预算的时效目标分开。
模式检查放在发布前，行级检查放在摄入阶段，业务规则放在转换后，端到端对账负责认证门禁。财务只读带版本的认证视图；分析师可以主动选择带标记的预览视图。每条规则都要有动作、负责人和操作手册。我会先在一个源上影子运行，拿已知事故检验检测效果，调整误报，演练重放；新鲜度错误预算耗尽后，预先商定的策略会改变工程优先级。”
分步骤深入解答
第一步：定义数据产品和消费者结果
为已认证的结算数据集写一份契约，无须罗列所有可能的检查。契约要写明数据集版本、业务日期、消费者、负责人、认证截止时间、修正规则和审计证据。两个消费模式必须清楚：
preliminary：较早可用，可能有已声明的延迟源，禁止用于财务关账；certified：指定版本不可变，所有硬门禁均通过，并带清单和质量结果 ID；superseded：已有修正版本替代当前版本，旧证据仍可查询。
这个状态模型可以防止编排系统的绿色状态意外变成业务保证。财务只查询 certified；探索性消费者可以用确定性换取时效，但不会削弱财务契约。
第二步：把每个 SLI 写成合格事件除以应评估事件
使用消费者可见的结果和定义明确的统计单位。这个场景的新鲜度 SLI 可以从以下版本开始：
freshness_sli =
在 UTC 06:30 前已认证且可查询的工作日分区数
/ 应交付的工作日分区数
初始_slo = 滚动 60 个工作日内至少 59 个合格分区这个目标在财务关账前留下 30 分钟，并在示例窗口中允许一次延迟认证。两个数值都需要与财务协商，并用历史表现验证。在消费者查询结果或目录状态上确认指定版本可读；调度完成时间只作为诊断信号。
其他维度各自使用独立的成功标准：
- 完整性： 所有预期源清单均已到达，记录数和关键键覆盖率完成对账。
- 唯一性： 已认证分区内
(sourceid, orderid, version)重复数为零。 - 有效性： 必填键存在，契约控制字段符合允许的类型、值域和范围。
- 一致性： 聚合前按照源、币种和业务日期核对记录数与金额。
- 修正时效： 已受理修正需要在约定窗口内生成新的认证版本。
只看内部形态很难推断准确性。一条金额记录可以格式有效且业务键唯一，金额本身仍可能错误。源端控制总额、账本对账、业务抽样和下游结果检查比格式规则提供更强证据。
第三步：明确区分硬性不变量、SLO 和诊断指标
把规则分成三类，动作会更容易理解：
- 硬性不变量： 任何违规都阻断认证，例如业务键缺失、版本重复或财务总额未对平。
- 可预算目标： 在书面策略规定的范围内允许偶发失约，例如认证截止时间或修正周转时间。
- 诊断指标： 帮助调查但不直接定义消费者是否成功，例如日环比数据量变化 20%。
不要为了套用错误预算公式，把硬性正确性要求改成“允许一定比例的坏行”。一条高金额重复订单的影响可能大于数千个无害的可选空值。每个目标及其后果需要独立；综合看板分数可以汇总趋势，但不能覆盖阻断规则。
第四步：把检查放在最早且有效的边界
在生产方和转换代码的 CI 中运行模式兼容性与契约示例。摄入阶段检查解析、必填信封字段、源身份、偏移连续性和幂等性；能够明确识别的坏记录按原因码隔离。转换后检查业务键、引用关系、版本选择、币种规则和源级切片。发布阶段执行清单与账本对账，并验证这个认证版本确实可查询。
同一条规则不必到处重复。使用五条固定数据的非空单元测试能验证代码路径，对真实生产源的说明力很弱。生产聚合检查可以发现问题，却可能来不及保护中间消费者。变更前放一个低成本预防检查，数据入口放运行时检查，承诺被消费的位置放端到端检查。
下面是与工具无关的示意伪 YAML，不对应某个产品的具体语法：
dataset: finance.fact_order_settlements
owner: finance-data
consumer: daily-close
certification_deadline_utc: "06:30"
rules:
- name: required_business_key
dimension: completeness
scope: row
pass_ratio: 1.0
action: block_and_quarantine
- name: unique_order_version
dimension: uniqueness
scope: [source_id, order_id, version]
pass_ratio: 1.0
action: block_certification
- name: source_manifest_reconciliation
dimension: consistency
scope: [source_id, currency, business_date]
pass_ratio: 1.0
action: block_certification_and_page_owner第五步：使用独立对账并切片查看结果
从完整的预期源清单出发，把已接收聚合结果左连接上去，才能看见完全没有交付的源。只从已接收数据出发做左连接，会让缺失源直接消失。金额先按原币种核对，避免有损转换。清单 ID、源水位、转换版本、表快照和规则结果应共同记录。
按源、地区、币种、事件类型和管道阶段切片。一项全局 99.99% 通过率可能掩盖一个低流量源完全中断。一个已知的延迟源也不应从摄入、转换和发布三个阶段发出内容相同的呼叫告警。把告警路由到最先出现且可执行的故障边界，同时保留下游诊断信息并抑制衍生告警。
历史区间适合做数据量异常检测，但季节性、促销和新源上线都可能带来合理变化。在独立控制总额确认损失前，异常只是一项调查证据。
第六步：让门禁、豁免和责任归属可执行
每条规则都要声明严重度、动作、直接负责人、备份负责人、升级对象、操作手册和最大响应时间。一种实用分工是：
- 源模式或清单失败：生产方负责修正，摄入负责人控制影响范围；
- 传输、去重或编排失败：数据平台负责恢复；
- 语义转换或对账失败：数据集负责人负责诊断和重建；
- 业务定义有争议：财务数据负责人决定契约，并走可审计的变更评审。
豁免会生成明确的降级版本，或让数据集继续保持预览状态。记录审批人、业务为何接受风险、影响哪些消费者，以及豁免何时到期。禁止覆盖失败结果，也不能静默地让认证别名指向未验证分区。
第七步：让错误预算策略真正改变决策
本例新鲜度 SLO 在滚动 60 个工作日中只有一次延迟分区预算。既要统计消耗量，也要观察消耗速度。一次延迟会耗尽全部预算；发布了错误的财务认证分区则直接触发事故策略，不受剩余新鲜度预算影响。
失约前先商定动作。当消耗速度预测显示唯一一次容许失约已处于风险中时，复查最主要原因并验证恢复能力。预算耗尽后，暂停高风险管道变更、优先安排可靠性工作，并要求负责人批准退出标准。这些后果让 SLO 成为决策工具；没有后果的看板只是报表。
如果检测结果与消费者事故无关，或呼叫告警精度很低，应复审 SLI。可以把测量点移近财务、增加遗漏切片或放宽噪声较大的诊断指标。不能为了消除运行噪声而放宽硬性不变量；需要修复测量实现或路由。
第八步：灰度、演练恢复并证明覆盖率
先在一个源上只评估不门禁，并回放一段有代表性的 14 到 30 天历史窗口。注入受控故障：删掉一个源、复制一个订单版本、破坏模式、延迟发布，以及在行数不变的情况下改金额。确认预期规则、负责人和操作手册只触发一次。
然后先门禁一个低风险源，再按源的重要性扩大，最后保护认证发布。验收条件包括：种子故障检测覆盖、没有错误认证分区、呼叫误报率有上限、消费者能读取证据、原始事件可确定性重放，以及能在财务截止前恢复。在正确性允许时，只扫描变更分区并测量规则成本；质量系统如果经常拖过自己要保护的截止时间，会削弱整条管道。
上线后要复查消费者人工发现而告警遗漏的事故，也要复查没有实际影响的告警。这两组样本分别暴露覆盖缺口和低精度规则。数据模型变更时同步版本化质量契约，要求生产方与消费者评审，并为每次认证保留当时使用的完整规则集。
高质量示范回答
“我会先从财务视角定义服务：指定结算分区已经认证、可查询、完成对账，并在关账前可用。DAG 完成状态只是一项诊断，所以我会探测发布版本，并保存对应的源清单、表快照、代码版本和质量结果。
新鲜度方面，我可以先提议滚动 60 个工作日中至少 59 个分区在 06:30 前认证，再结合财务要求和历史表现校准。正确性使用独立硬门禁：所有源清单必须到齐；按源和业务日期核对记录数与原币种金额；业务键必须完整；(sourceid, orderid, version) 必须唯一。我不会用一个平均分让阻断失败混过去。
检查分布在多个边界。CI 捕获不兼容模式和转换用例；摄入阶段检查信封、偏移与幂等，并隔离可识别问题；转换阶段检查语义和引用规则；发布阶段做独立对账，并确认指定版本可读。财务只能读取认证别名，分析师可以使用带源状态与质量状态的预览视图。
每项失败都映射到一个动作和一位负责人。生产方处理源契约问题，平台团队处理传输，数据集负责人处理转换和认证。豁免有时限、对消费者可见，并由财务负责人审批。即使新鲜度预算还有余额，错误的认证分区也属于事故。
我会先在历史分区上影子运行规则，分别注入缺源、重复键、模式破坏、延迟和行数不变但金额错误的故障，再对一个源启用门禁。只有检测、路由、重放、呼叫误报率和规则耗时达到验收条件才继续扩大。如果唯一一次可容忍的延迟被消耗，约定策略就会把资源从功能开发转向可靠性，直到退出条件满足。”
常见错误
- 只监控任务成功 → 任务结束后仍可能发布不完整或不可读的数据 → 在消费者边界测量认证对象。
- 把昨日行数当作完整性证明 → 正常业务变化和静默丢源表现相似 → 使用清单、偏移、快照或其他受控总额对账。
- 把所有检查合成一个分数 → 多条可选规则通过会掩盖一条财务不变量 → 每个关键维度使用独立阈值和动作。
- 对每月一次的日批事件设置 99.9% → 分母无法表达这种精度 → 选择粒度有意义的统计单位和窗口。
- 给所有坏行分配错误预算 → 行数忽略业务价值和硬性完整性 → 把零容忍不变量与可预算时效分开。
- 每条规则失败都呼叫告警 → 一个源故障会形成无行动价值的告警瀑布 → 只呼叫最先出现且有负责人的边界，并抑制下游衍生告警。
- 让值班人员静默绕过门禁 → 消费者无法判断风险，审计证据也会消失 → 使用已审批、有到期时间且消费者可见的豁免。
- 只测试正常路径 → 关账事故中才发现恢复过程不确定 → 强制执行前注入代表性故障并演练重放。
- 每次都新增昂贵的全表扫描 → 质量检查吃掉自己要保护的新鲜度余量 → 在安全前提下使用增量检查加周期性全量对账。
追问及应对
追问一：源系统无法提供控制清单怎么办？
按独立性给替代证据排序。源快照、数据库日志序列区间、消息偏移、带校验和的文件清单和独立生成的账本，都比目标表自己的行数更强。历史区间可以发现异常，但要明确它无法证明完整性；对关键源，应把控制清单或控制总额交付写入生产方契约。
追问二：财务要求永远不允许延迟怎么办？
隐含的 100% 目标无法为可靠性工作提供优先级机制，也可能无法运营。量化接近这一要求所需的冗余、重放时间、源依赖和成本。财务正确性继续使用硬门禁；新鲜度使用可测目标，并增加更严格的期望目标。业务、工程和运维需要明确同意响应策略。
追问三：分区认证后又收到修正数据怎么办？
生成新的不可变认证版本，把它与旧版本和修正清单关联，重跑所有受影响的对账规则，审批通过后再原子切换认证别名。旧证据继续保留供审计。修正周转时间应单独测量，因为原始新鲜度 SLI 无法描述已知错误修复速度。
追问四：数百个数据集如何避免告警疲劳？
按消费者影响给数据集分级，规则没有直接负责人就不能呼叫告警，只对可执行的 SLO 风险或硬门禁失败呼叫。相关规则失败按最早故障依赖聚合，警告进入复核队列，并定期把呼叫告警与真实消费者事故对照。长期低精度规则应该停用或重写。
追问五：流式管道需要改什么？
把每日一次认证机会换成事件时间窗口或消费者分钟数。新鲜度从事件时间量到可查询状态，完整性使用关闭水位或源偏移，延迟事件另有修正策略。短窗口和长窗口同时监控错误预算消耗速度；需要立即隔离的逐行或逐键硬性不变量继续保留。
追问六：如何评估数据质量工具？
先看契约适配，再看功能数量。验证行级与聚合规则、复合键唯一性、增量执行、失败记录证据、结果版本化、编排门禁、责任元数据、API、告警路由和生产规模成本。把同一套种子故障跑过各候选工具；精美看板无法弥补端到端对账缺失或发布门禁无法执行。