首页/数据/数仓建模速查/跨层对账:ODS 与 DWD 行数金额核对
分层与规范64 条

跨层对账:ODS 与 DWD 行数金额核对

每层产出后做跨层对账:行数、去重后行数、金额合计三项差异要在阈值内;差异超阈值阻断下游并告警,避免错误数据一路流到看板。

数仓建模速查数据更新于 2026-10-13

跨层对账是什么

跨层对账是在每一层产出后,用同一套指标与上游比对,确认数据在层间流转时没有多、没有少、口径没有漂移。常用对账项是行数、去重后行数、金额合计和主键覆盖率四项,差异落在阈值内才放行。它的作用是阻断而不是报警:差异超阈值时宁可拦住下游、让当天看板空着,也不要让错误数据一路流到业务侧,事后反查的成本比停一次任务高得多。

基本信息

对账维度行数、去重后行数、金额合计、主键覆盖率
执行时机每层产出完成后立即执行,先于下游启动
阈值设定绝对差值加相对比例,按业务波动范围定
放行动作阈值内继续下游,超阈值阻断并告警
差异分类正常口径差异(过滤测试单、只含已支付)与异常差异要分开
结果留存对账结果落表,保留历史便于看趋势
定位顺序先看分层总量差异,再下钻到键级别抽样

典型使用场景

  • ODS 到 DWD:核对过滤规则带来的正常差异,确认没有漏单,重点看主键覆盖率
  • DWD 到 DWS:同一过滤条件下金额合计必须一致,是最直接的口径校验
  • 源系统到 ODS:核对行数与主键集合,能发现同步任务被截断或增量位点错位
  • 补数之后:重跑对账确认结果与首次一致,顺带验证脚本的幂等性
  • 看板发布前:把对账当门禁,不通过就不发版,避免错误数字对外

跨层对账脚本

跨层对账脚本
-- 行数与金额同时比对,两个层级放在一张结果里
SELECT 'ods' AS layer, count(1) AS rows_cnt,
       sum(cast(pay_amt AS decimal(18,2))) AS amt
FROM ods_order
WHERE dt = '2026-10-12'
UNION ALL
SELECT 'dwd', count(1), sum(pay_amt)
FROM dwd_trade_order_di
WHERE dt = '2026-10-12' AND order_status = 'PAID';

-- 差异率判断:正常口径差异先显式扣除,再与阈值比较
-- 通过条件示例:abs(dwd_amt - ods_amt) / ods_amt <= 0.001

对账项与判据

对账项比较对象通过标准异常含义
行数上游与下游总行数差异在阈值内同步截断或过滤过量
去重后行数去重前后计数等于维度组合数主键重复
金额合计同一口径下求和一致或在阈值内口径不一致或漏数
主键覆盖率上游主键集合与下游缺失键可解释丢数
对账脚本必须把正常口径差异显式写出来(如剔除测试单、只统计已支付),否则阈值只能靠拍脑袋定,要么天天误报,要么完全拦不住问题。
对账只看总数不分层,一旦出现差异就要人工翻整条链路找原因,定位时间经常比修数据本身更长。

易错点

  • 对账只比总量不分层:差异出现后无法快速定位是哪一段链路出的问题
  • 阈值设成 0 或设得极大:前者正常业务波动天天误报,后者等于没有校验
  • 口径差异散落在多个脚本里且写法不一致:改一处过滤条件就引发连锁误报
  • 对账失败只发告警不阻断下游:错误数据继续流到看板,业务先看到错误数字
  • 不保存历史对账结果:无法判断当前差异是突变还是长期缓慢累积

数据来源与参考

  • 阿里《大数据之路:阿里巴巴大数据实践》
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌