题干与适用场景
支付系统说昨天有 1,000 笔订单，但数仓报表只有 998 笔。请设计一条对账流水线，找出源系统、落地层、转换模型和报表之间的差异。
回答不要求绑定 dbt、Airflow 或某个仓库产品；重点是可重复的证据链。要区分记录缺失、重复、金额不一致、迟到和业务口径不同。
面试官考察点
对账粒度
候选人应先定义业务键、时间语义和金额精度，再决定按订单、商户、日或批次对账。只比较总数会掩盖抵消错误。
可解释校验
规则应同时检查条数、金额、状态分布、主键唯一性和抽样明细，并保留规则版本与输入快照。
异常闭环
差异要分级、分派 owner、记录证据、支持重放和人工结案；告警不能只发一条无法追踪的邮件。
稳定运行
流水线要支持迟到数据、幂等重跑、分区范围、schema 变更、数据新鲜度和审计留痕，避免修复动作再次制造差异。
回答前需要澄清的问题
- “昨天”按哪个时区和事件时间计算？
- 订单的业务键是什么，退款和取消如何计入？
- 源系统是否允许迟到、更新或删除？
- 数仓是批处理、流处理，还是两者并存？
- 金额使用哪种币种和小数精度？
- 差异需要自动修复、回补，还是先人工审批？
30 秒回答框架
“我会先冻结同一时间窗和快照版本，按订单业务键做条数、金额和状态对账，再下钻到缺失、重复、更新未到和转换错误。每条差异保存规则版本、源记录摘要、数仓记录摘要和 owner。迟到数据用 watermark 与重试窗口处理；修复通过幂等回补任务完成，最后重新对账并关闭工单。所有运行、输入范围、结果和人工操作都写入审计表。”
分步骤深入解答
第一步：固定范围与快照
记录源端抽取批次、事件时间范围、处理时间、时区和快照 ID。对账结果必须能回到同一批输入，避免源系统继续变化导致结果漂移。
第二步：建立规范化键
统一订单 ID、商户 ID、状态映射、币种和金额精度。源记录与数仓记录保留哈希或摘要，敏感字段只保留最小必要信息。
第三步：运行多层校验
先检查条数和总金额，再按商户、日期、状态分组比较；随后做主键唯一性、null、重复、金额容差和明细 anti-join。总额相等不代表明细正确。
第四步：识别迟到与修订
以事件时间和 watermark 区分尚未到达与真正缺失。对账窗口允许补数，超过窗口仍有差异才升级；更新、退款和删除要使用版本或变更时间重算。
第五步：分级与修复
按金额、订单数、业务影响和持续时间分级。自动修复只执行幂等的回补或重放；涉及财务口径的差异先人工批准，并记录前后值和原因。
第六步：重跑与审计
任务按快照 ID、分区和规则版本幂等运行。保存输入范围、查询版本、指标结果、差异明细、告警、owner、重试次数和关闭时间，支持复盘。
高质量示范回答
“我会为每个源批次生成 snapshot_id，并固定 UTC 事件时间窗。规范化层把订单 ID、状态、币种和金额精度统一后，先做条数、金额和状态分布对账，再用主键 anti-join 找出源有数仓无、数仓有源无、重复和金额不一致的记录。
迟到事件由 watermark 和两小时补数窗口区分；窗口内标记 pending，窗口后才升级。差异表保存规则版本、双方记录摘要、金额差、owner 和证据链接。自动回补任务以 snapshot_id 加业务键幂等重放，财务差异需要审批。每次修复后重新跑同一快照，结果连同输入范围、代码版本、告警和关闭时间写入审计表。”
常见错误
- 只比较总条数 → 抵消错误被掩盖 → 按业务键做 anti-join 并保存明细差异。
- 把处理时间当作事件时间 → 跨时区和迟到记录错位 → 固定事件时间、处理时间和时区字段。
- 没有定义退款、取消、更新和删除 → 各层口径无法解释 → 在状态映射和版本规则中明确它们。
- 用浮点数比较金额 → 小数误差制造假差异 → 使用整数最小货币单位、币种和容差。
- 迟到数据一律告警 → 噪声导致误修复 → 用 watermark 与补数窗口先标记 pending。
- 回补任务非幂等 → 重跑后产生重复记录 → 以快照和业务键做幂等 upsert。
- 差异没有 owner、证据和关闭状态 → 无法追责或复盘 → 建立差异工单和审计字段。
- 只保存最终数字 → 无法重现当时结果 → 保存输入快照、规则版本和代码版本。
追问及应对
追问一：总额相同但记录不同怎么办？
使用业务键 anti-join、重复键检查和分组分布比较，找出一增一减的抵消错误；把明细差异保存在差异表。
追问二：如何避免迟到数据误报？
用事件时间、watermark 和明确的补数窗口。窗口内状态为 pending，超过窗口仍不一致才升级，并记录窗口配置版本。
追问三：修复任务如何安全重跑？
以 snapshot_id、分区和业务键作为幂等键，写入采用 upsert 或去重，重跑前后比较计数与金额，失败可安全重试。
追问四：如何验证对账规则本身？
用已知缺失、重复、迟到、退款和币种样本做 fixture，测试规则版本、容差、边界日期和时区，并监控误报率。
追问五：如何安排告警和责任？
按金额、数量、持续时间和业务等级路由到 owner；告警链接到差异批次、证据和修复动作，关闭必须填写原因并可审计。
来源一：dbt sources 与来源测试
dbt Developer Hub 的 sources 文档说明 source 可用于定义来源、建立 lineage、添加数据测试并检查 freshness，适合作为对账输入的治理参考。
来源二：freshness 与 SLA
dbt Developer Hub 的 source freshness 文档展示了用 loaded-at 字段、warn/error 阈值和快照结果管理数据新鲜度，可用于设计迟到数据与升级窗口。
来源三：数据质量检查
dbt Labs 的数据质量文章涵盖唯一性、关系、空值和 freshness 等检查，说明自动化校验应与版本化模型和告警结合。