如何用科学的方法，保障数据准确性

|0x00 问题描述

上周收到一位读者的询问：怎么保证数据的正确性?

以下是原文：

上游，会遇到根源性问题，比如客户端在数据上报时就传错的情况，比如手抖把下单时间不小心上报成了用户点击商品详情的时间.

中游，指标的计算正确与否完全依赖于开发人员对于指标含义的理解以及业务方对于数据结果的敏感程度，一旦有一方出现问题即使指标统计错误也无人可以发现，甚至开发人员写错统计代码，或者由于字段的值异常, 代码没有处理好异常等等导致计算脚本异常中断，都会导致计算结果的偏差.

下游，业务方看到指标时，可能也对指标的统计口径理解上有偏差，经常需要问技术人员为啥这两个指标是跟他预期不一致的，技术人员就总是要反复排查统计逻辑和解答业务人员的疑惑，很耗时.

关于这三个典型问题，我们分开来看。

|0x01 上游数据的保障

针对上游数据的保障，我的看法是，错误的发生是不可避免的，甚至一些隐藏的问题始终无法被发现，但我们要做的不是100%杜绝问题，而是及时发现95%的可疑问题。

因此，，针对ODS层，不论是数据同步任务、视图还是其他形式，保障数据的准确性的核心有两点：一是及时监控问题的发生；二是保障一个流畅的上下游沟通方法。

但是，在防范问题发生之前，工程端也是要参与到数据准确性保障的工作中来，也就是尽可能在埋点平台上做好保障，这个需要有比较好的功能测试。

其次，我们得有一套合理的埋点规范，不论是SPM，还是其他一些自定义的方法，合理的规范不仅能够减少上下游的信息误差，同时也会避免因为扯皮导致的一些数据问题，问题中的上报错误也会少很多，至少我们能够加一层规范校验来检查出部分的问题，这还是比较关键的。

最后，要有可靠的数据同步工具，前一阶段Sqoop下线了，但其他的工具，比如DataX，都可以来尝试使用。当然，我们可以对一些具有典型特征的字段格式，做基本的校验规则，比如日期、正数、手机号等。

其实数据出现错误是难免的，世界本就是概率的、而非永恒不变的，网络波动、编码错误、人工处理，都有很多可能导致问题。因此，在ODS接入阶段，我们的建议是以发现问题为主。

但发现问题的方式，是有技巧的。比如，波动性监控就是一种非常不错的方法，通过检测总条数、金额总数等具备统计学特征的指标，我们可以发现一些问题的端倪。如果波动在5%左右，需要确认原因；如果是10%，就可能是某些系统节点问题；如果是30%，就可能是面上的问题了。

发现问题后，及时跟上游反馈，一起看原因。解析失败的数据不要丢，记录下来，方便后续分析原因。

如果这个阶段发现问题，建议直接阻断，因为如果下游很多的话，刷新和解释的成本还是很高，比如晚一点产出，确保没问题。

|0x02 中游指标的计算

中游的保障思路，是通过强规范来约束行为，同时通过一些工具来保障强规范的落地。按照维度建模和一些数据治理的理论，当这一层严格执行规范时，发生问题的概率，其实是非常小的。

中游，即CDM层，包括了DWD、DWS、DIM，是我们经常强调的公共层，需要强规范和一些工具的保障来落地。强规范，代表分层、命名、编码、CodeReview等规范，很多文章有详细介绍，这里不再赘述。工具保障，是利用技术的力量，包括规则检查、数据质量、数据对比、数据验证等工具。可以说，仅仅依靠规范是不够的，我们需要工具来检查规范的落地。

最典型的工具有这么几种，一种是规则检查，在Dataphin等开发工具上有内置，在命名上就加以规范；一种是报警设置，常规的开发工具也都会集成，比如编码正确性校验、权限检测、冒烟测试、循环依赖检查等，工具可以帮助避免大多数的低级错误；还有一种是数据对比工具，一些重构任务不确定会不会影响结果，通过对比工具则能快速实现这一目的。对于任务本身，需要检查调度参数、依赖关系、定时设置等属性。

重点介绍下DQC，也就是质量保障工具。比如检查主键唯一、数据是否为空、波动性监控等，从各个角度可以衡量今天产出的数据是否大体正常，一旦出现明显不符合逻辑的数据，则证明今天的数据可能有脏数据，同样会及时通知相关责任人进行排查修复，从某个方面确保数据准确性。从这个角度看，所有的核心任务节点，都需要配置DQC。当然，某些节点不需要了，需要及时下线，省去很多维护的成本。

除去工具检查规范外，任务本身也需要一些保障工具。

当任务开发完成后，在提交和发布前，建议进行冒烟测试。比如校验SQL规范、检查权限、校验调度方式，等等。节点发布之后，需要在运维中心，查看节点每个周期的运行情况，是否出错、运行时间、所耗费的资源、上下游节点的运行情况，然后根据业务需求优化调整代码或者配置。UDF函数需要有统一管理，不能一个功能有多个节点。

除此之外，定期进行慢任务治理，也是必不可少的。慢任务治理不仅仅是数据质量要关心的事情，对于数据准确性而言，时效性也是一个考核因素，这一点比较关键。

凡此种种，其实会非常拖累开发的节奏，但往往是做的越快，错的越多，一些繁琐的规定，还是很有必要的。

|0x03 下游指标的使用

下游保障思路有两点，一个是做好测试，另一个是写好文档和注释，当然，如果有系统性介绍指标的说明，就更好了。

下游使用数据前，需要有数据测试的接入。数据测试，包括三种：自测、测试同学验证、线上任务验证。因为任务的细节只有自己知道，因此自测是必须且有必要的。很多时候，我们还需要相信数据测试的同学，大一点的需求需要有专业人的介入。最后是任务验证，跑一次真实的数据，保证整个环节是通常的。至于线上任务，在上线前、修改后，都需要手动来触发一次，确保修改是正确的，不会对第二天值班的同学造成影响。

做好测试，特指针对ADS层，即数据组合和输出的规范。因为ADS通常开发比较迅速、逻辑比较复杂、变化比价快速，因为很多逻辑只有开发自己清楚，这种情况下，自测显得非常重要。当然，打好与测试同学的配合，也很重要。

另外，指标体系也是必须要有的，这是一个老生常谈的问题。指标体系，大体要有如下的内容：

指标定义；
度量目的；
度量方法；
度量维度；
统计周期；
数据来源；
数据范围。

如果有可能的话，需要针对某个场景的分析思路，写系统的介绍文档，包括流程图、漏斗图、分析目的、分析指标、牵引意义等各种角度的说明。麻烦吗？非常麻烦，但这就是看你愿意把成本花在解释上，还是花在文档上。

最后，要有数据可视化工具，一些很常见的问题，通过可视化工具，可以轻松发现，比如金额是负数，比如波动非常大，这些都有助于发现问题。

|0xFF 六西格玛

出一个题目：假设一个工作需要100道工序完成，如果每一道工序的合格率都达到99%，经过100道工序后，产品的总合格率是?

答案是，36.6%。

其实，数据开发有些时候与工厂类似，加工的工序很多，我们又无法保障每个环节100%准确。

这时候，我们用六西格玛的思想，来武装自己，就最合适不过了。企业可以用西格玛的不同等级作为对比，来衡量自身的流程管理水平。

比如，六西格玛背后的原理，是如果你检测到你的项目中有多少缺陷，你就可以找出如何系统地减少缺陷，使你的项目尽量完美的方法。一个企业要想达到六西格玛标准，那么它的出错率不能超过百万分之3.4。

如果我们利用数据规范 + 保障工具，确保每个环节出错率，在一个相当低的水平上，与六西格玛标准相当，那么我们就可以拍着胸脯说，我们的数据，是准确的。

完美通常不存在，尽可能低，已经是一种极限了。