数据质量与对账：在用户发现之前发现问题

指标算得对，前提是数据本身对；数据对不对，不能靠用户来告诉你

前几篇聊了指标定义、指标引擎和展示层。到这里，一条统计链路看起来已经闭环了：定义清楚、引擎统一、页面稳定。

但还有一个问题没解决：数据本身错了怎么办？

指标引擎可以保证“同样的输入算出同样的输出”，但它保证不了输入是对的。采集漏了一条、状态同步晚了、关联键用错了，算出来的数字依然是错的——而且看起来完全正常。

这篇聊聊数据质量和对账：怎么在用户发现之前，发现数据的问题。

一、数据质量的五个维度

聊数据质量，先要有一把尺子。通常从五个维度看：

维度	含义	典型问题
完整性	该有的数据有没有	漏采、漏同步、字段为空
准确性	值对不对	金额错、状态错、时间错
一致性	多处数据是否一致	报表和业务库对不上
及时性	数据是否按时到达	延迟、积压、任务失败
唯一性	有没有重复	重复事件、重复写入

五个维度里，完整性和一致性最容易出问题，也最难靠肉眼发现。

二、数据问题通常从哪来

统计链路很长，每一段都可能出问题：

1	业务库 → 变更采集 → 消息队列 → 文档拼装 → 搜索索引 → 指标查询 → 页面

常见的出错点：

采集漏了：消费端重启、消息丢失、过滤条件写错；
重复了：消息重投、补偿任务重叠、幂等没做好；
拼装错了：关联键用错、某张表没查到、字段默认值不对；
同步晚了：任务积压、依赖服务超时；
口径细节错了：排除条件漏一个、时间字段选错、去重方式不对；
索引结构变了：字段类型不匹配，值被静默截断。

这些问题的共同点是：不报错。系统照常运行，页面照常出数，只有数字悄悄变了。

所以数据质量不能靠“出问题再修”，要靠主动发现。

三、对账：用另一条路径验证同一条结论

对账的本质，是用独立的另一条路径算同一个数，然后比较。

常见的对账对象有三类：

3.1 和业务库对

直接从业务库写查询，算出“应该有的数”，再和统计平台的结果比。

适合对：

总量类指标：下单量、支付量、退款额；
明细类数据：某个区间有哪些单；
状态分布：各状态各多少单。

注意：业务库是“当前状态”，统计平台可能保留历史快照，两者对账时要明确按哪个时间点比。

3.2 和财务、第三方对

财务口径、支付渠道账单、物流回单，是天然的第二数据源。

适合对：

金额类指标：营收、退款、手续费；
结算类数据：已结算、待结算、差异单。

这类对账的价值在于：它不依赖你自己的链路，能发现“整条链路一起错”的问题。

3.3 和页面抽样对

从报表里挑几个数，点开明细，核对条数、金额、订单号。

这是最朴素的方法，但非常有效。很多问题就是靠“点开看一眼”发现的。

四、对账工具应该长什么样

对账不能靠人工导表格。一个能长期用的对账工具，至少要能回答四个问题：

差多少：同一区间、同一指标，两边各是多少，差值是正还是负；
差在哪：差异落在哪些维度、哪些单号上；
为什么差：是缺数据、多数据，还是字段值不同；
能不能复现：同样的参数再跑一次，差异是否稳定。

所以对账结果至少要有三层：

1
2
3

第一层：指标级  —— 两边总值、差值、差异率
第二层：维度级  —— 按店铺、渠道、品类拆开，看差异集中在哪
第三层：单据级  —— 差异单号、缺失/多余、字段对比

只有指标级差异，排查等于大海捞针；只有单据级差异，又看不出影响面。三层结合，才能快速定位。

对账工具还要有一个能力：差异分类。

只在 A 侧存在的单：可能是漏采、漏拼装；
只在 B 侧存在的单：可能是多采、重复、过滤条件不同；
两侧都有但值不同：可能是字段口径、时间口径、关联键不同。

分类之后，排查方向就清楚了。

五、监控：让问题自己冒出来

对账是“主动检查”，监控是“持续守夜”。统计平台至少要监控这几类信号：

延迟：数据从产生到可查，用了多久；超过阈值就告警。

失败率：采集、拼装、写入的失败比例；偶发失败可以重试，持续失败必须告警。

空值与零值：某个指标突然全是 0，或者关键字段大面积为空。

突变：日环比、周同比超过阈值。业务真的涨了是好事，但也要确认不是数据问题。

重复：同一单号出现多条、同一批次重复写入。

口径漂移：同一个指标，两次计算结果不一致（排除数据更新因素）。

监控的难点不是“加告警”，而是减少误报。阈值太松，问题发现不了；阈值太紧，天天告警，最后没人看。

比较稳妥的做法是：

先监控“绝对异常”（全 0、全空、任务失败），这类几乎不会误报；
再监控“相对异常”（环比突变），按业务分品类设置不同阈值；
告警要带上下文：哪个指标、哪个区间、差多少、可能原因。

六、数据质量规则：在入口就把脏数据挡住

除了事后对账，入口的规则也很重要。常见的规则：

必填字段：订单号、金额、时间、状态不能为空；
枚举范围：状态、类型、渠道编码必须在已知集合内；
时间合理性：不能是未来时间，不能是 1970 年；
金额合理性：不能为负（退款类除外），不能超过业务上限；
关联完整性：订单必须能关联到商品、会员、渠道；
唯一性：同一单号、同一类型只能有一条有效记录。

规则命中时，不要直接丢数据，而是：

记录到质量问题表；
按严重程度决定“阻断写入”还是“放行并标记”；
让问题可查询、可统计、可回溯。

直接丢数据最危险：表面看系统很干净，实际丢了多少没人知道。

七、修复流程：发现之后怎么办

数据问题被发现后，修复流程要固定下来：

确认影响面：哪些指标、哪些区间、哪些页面受影响；
定位根因：采集、拼装、写入、查询，哪一段的问题；
回补数据：按区间或按主键重跑，回补必须幂等；
验证：回补后重新对账，确认差异消失；
复盘：为什么会发生、怎么预防、监控要不要补。

回补是最容易出二次事故的环节：

回补任务和实时任务同时写同一批数据，可能互相覆盖；
回补范围算错，漏掉一部分；
回补没有幂等，重复执行产生重复数据。

所以回补前要想清楚三件事：回补哪些、按什么顺序、怎么验证。

八、常见坑

只对总量，不对明细：总量对上了，明细可能还是错的；
只对一天，不对边界：月初、月末、跨年、时区边界最容易出问题；
对账区间含今天：今天数据还没跑完，差异是正常的；
差异不分类：只知道差多少，不知道差在哪；
监控只看失败率：数据错了但任务成功，监控发现不了；
告警没有上下文：收到告警也不知道该查什么；
质量问题直接丢数据：丢了什么没人知道；
回补不幂等：补一次多一批；
回补和实时任务打架：互相覆盖，数字反复横跳；
问题修完不复盘：同一个坑踩第二次。

九、结语

数据质量不是“加几个校验”，而是一套闭环：

1	入口规则 → 持续监控 → 定期对账 → 差异定位 → 幂等回补 → 复盘改进

指标定义决定“算得对不对”，数据质量决定“算的是不是真的”。