这是【数据中台】系列第5篇。上篇讲维度变更拉链表,这篇讲质量校验。


凌晨2点,所有调度任务全绿。

早上9点,运营群里炸了:昨天销售额少了1000万。

我盯着屏幕查了半小时——调度没问题,质检没问题,到底哪出的问题?

最后查到源表,order_amount全是0。

源系统改了代码,空值不写null了,写0。我配的空值检测压根没触发。

那一刻我才明白:质检报告全绿,不代表数据没问题。


触发了

没触发

不能

数据出了问题

质检规则触发?

强依赖?

阻断下游

告警通知

人工排查

人工介入修复

发现规则漏洞

补规则+分级

能自动修?

自动修复

人工修正

任务继续


一、200多条规则,覆盖了什么?

我们质检平台配了200多条规则,覆盖了所有核心表。

空值检测、总和检测、行数检测、SQL对比——该有的都有。

-- 空值检测
SELECT SUM(IF(order_amount IS NULL, 1, 0)) FROM dw.order

-- 行数对比
SELECT COUNT(*) FROM dw.order WHERE ds = '${today}'
-- 和昨天对比,波动不超过10%

每天早上看报告,全绿。我觉得挺稳的。

直到那个1000万的坑,我才发现:这些规则只测"有没有",不测"对不对"。

字段不是null,但值是错的——空值检测管不了默认值。
行数没波动,但历史数据被删了——行数对比管不了业务动作。


二、三个坑,三种漏法

坑一:默认值偷渡

order_amount那个坑之后,我开始查其他表。

果然,源系统有个习惯:改代码时不通知数仓,悄悄改默认值。

上次是金额变0,下次可能是状态变-1,或者时间变1970-01-01。

我后来加了范围检测:金额不能为0,状态必须在已知列表里,时间不能早于2020年。

-- 范围检测:金额不能为0
SELECT COUNT(*) FROM dw.order 
WHERE order_amount = 0 AND ds = '${today}'

加了这条规则之后,三个月内触发了4次,全是源系统改默认值。

坑二:业务悄悄加字段

status那个坑更隐蔽。

业务加了个新状态6,代表"部分退款"。质检规则配的是status in (1,2,3,4,5),没覆盖6。

质检过了,但下游报表没写状态6的逻辑,退款订单被漏统计了。

这件事让我意识到:质检规则和下游报表必须同步更新。

后来我们定了个规矩:业务改字段枚举值,必须同时通知数仓和BI,两边同步改。

坑三:历史数据被删

第三个坑最隐蔽。

源系统推全量表,每天覆盖。质检规则配了行数对比:今天vs昨天,波动不超过10%。

那天源系统清理了一批历史数据,行数刚好少了10%——卡着阈值过了。

但下游报表用了那些历史数据,数据缺了一块。

我后来把行数对比改成了绝对值+趋势双重检测

-- 绝对值检测:行数不能低于历史最低
SELECT COUNT(*) FROM dw.order WHERE ds = '${today}'
-- 低于历史最低值的90%就告警

-- 趋势检测:连续3天下降就告警
-- 用LAG函数看最近3天的趋势

三、强依赖和弱依赖

踩完这三个坑,我开始重新设计质检规则的分级。

强依赖:失败就停

核心表的质检规则设成强依赖,失败就阻断下游。

比如:ods层主表空值超过5%,说明源系统出了大问题,下游不跑。

代价是延迟——但比错误数据流下去好。那次1000万的坑,如果强依赖拦住了,最多耽误半天;没拦住,下游报表全错,运营骂了我一天。

弱依赖:失败告警

非核心表设成弱依赖,失败只告警,任务继续。

比如:某字段平均值波动大,可能是业务变化,先告警让人看。

通知分级

  • 钉钉:日常告警,我早上统一看
  • 短信:强依赖失败,我得马上看
  • 电话:影响面大的问题,半夜也得起来

别什么问题都发短信,发多了会被无视。


四、业务规则:数仓配不了的东西

技术质检我能配,但业务质检——数仓不知道业务逻辑。

比如:

  • 订单金额不能为0 → 这个我知道
  • 退款金额不能大于订单金额 → 这个我也知道
  • 某个渠道的订单占比突然从5%涨到30% → 这个我不知道正不正常

业务规则要业务方配。

后来我们和业务方定了个机制:每个核心业务字段,业务方出校验规则,数仓配到质检平台上。

业务方一开始不愿意,觉得"多一事不如少一事"。

直到那次1000万的坑影响到了他们的KPI,他们才意识到:数据出了问题,最后背锅的不只是数仓。


写在最后

质检规则写了一百条,还是漏掉了问题——不是规则不够多,是覆盖不全。

空值检测测不出默认值,值域检测测不出新增枚举,行数对比测不出历史删除。

这些规则只能测"有没有",测不出"对不对"。

真正的问题是:谁来定义"对的"标准?

数仓定义不了——我们不知道业务逻辑。
业务方不想定义——觉得多一事不如少一事。

最后出了问题,两边互相甩锅。

质检平台是工具,不是保险箱。工具能帮你发现问题,但定义不了什么是问题。


下一篇:数据资产管理

更多推荐