面试题:如何验证指标结果准确？

问题

昨日群内发起一项比较有意思而且开放性的问题：在日常工作当中，大家开发完指标后，是如何验证结果是准确的？

这里把大佬们的思考分享出来，同时也做一下汇总，笔者能力和水平有限，如有错误之处，请多多指点。如果同学有更好的想法欢迎一起加入讨论。

大佬解答

以上大佬们的解答相信也是很多同学日常的操作，可以说是丝毫没有半点毛病。

总结

这里需要把该问题和保障数据一致性问题区分开来，本文讨论的是数据的准确性问题(DQC范畴)。

笔者结合前面大佬们的讨论并查询了一些资料，做出一些总结供大家参考。主要分为以下几个部分：
1、验证指标结果准确的几个方向
2、确保指标结果准确的几项措施

验证方法

口径对齐、数据源统一

做过数据开发的同学应该都有过因为口径理解不一致或者使用数据源不同出现返工的情况，这种情况的出现就会和需求方心中所预期的结果有所偏差。所以笔者这里把口径对齐和数据源统一作为指标结果准确的前提，否则无论经过后续的多少种验证方法都无法完成交付。

直接核对

这种校验方式如前面大佬所提，比如对于统计当日新增用户数这类简单指标，可直接通过明细比对。这种方式也是最简答粗暴的。

参照对比

对于无法直接通过明细比对的情况，可以跟历史数据或者同类数据进行对比，通过观察是否有大幅度的波动差异来验证合理性，比如历史日活在30w左右，新统计的日活数据只有几w，这种大幅度的升高或者降低的现象，要么是出现业务异常或者进行了一些业务操作，要么就是数据统计错误。当然参照对比的方式只能接近需求方的容忍程度，并不能完全保证准确性。

勾稽关系验证

先来介绍下勾稽关系的定义：指账簿和会计报表中有关数字之间存在的，可据以相互考察、核对的关系。举个简单的例子：公司发了1000 的薪资给A，那么A就会有1000 的收入，这两者间可互相验证，互相勾稽，就是勾稽关系了。一般对于指标之间有逻辑或者计算关系的时候，可以采用该种方式。比如B指标值=A指标+C指标值。

穿行测试

穿行测试（walk through testing）是指追踪交易在财务报告信息系统中的处理过程，这里所指的是通过一个实际的数据来串联整个业务逻辑进而检查每个环节是否符合业务逻辑。通常这种方式是由测试人员介入验证，也是验证开发逻辑最好的一个方式。

合理判断

合理判断的方法就需要开发同学要对业务有深刻的理解，和前面介绍的参照对比有点类似，这里的合理需要结合企业当前业务情况进行评估判断，心里清楚的知道自己统计出的指标值应该在什么样的一个范围。

简单为大家介绍以上几种验证方法，当然通常还会通过检查结果空值率、是否存在无效值、格式类型、离散分布等等指标来验证结果的准确度。笔者这里找了一份关于统计数据准确评估方法列表供大家参考

注：该图来自于《王华 金勇进. 统计数据准确性评估：方法分类及适用性分析[J]. 统计研究, 2009, 26(1): 32-39.》

如果大家有其他好的验证方式，欢迎一起讨论。

保障措施

要想保障数据准确，那么我们需要知道数据出错可能会在哪几个环节上，要想知道数据可能会出错在哪几个环节上，那么我们就要知道数据的流转是怎样的。大家都知道数据的整个生命周期包括：生产、存储、清洗、加工处理、对外服务。

那么要想保障最终结果的准确，那么就要保障每个环节的准确。这里引入一个数学题：假设一个工作需要100道工序完成，如果每一道工序的合格率都达到99%，经过100道工序后，那么产品的总合格率就是36.6%。可想而知，要保障数据准确性，涉及到的因素非常多，出错率也是非常高的，但我们仍需要各种措施来提高准确度。

笔者这里以数仓为例，对于数据流转抽象成入仓、仓内加工、出仓三块
1、首先要保障源头准确，入仓采集质量要严格把关，比如日志采集是否丢失、数据漂移、主备库延迟等问题。对于核心数据必须要配置稽核以此来保证贴源。

2、对于仓内清洗加工处理环节，需要确认清洗规则、按规范行事，该统一类型的要统一掉，该填充数据的地方要填充，同时也要注意调度周期、依赖关系、稽核等配置。

3、最后一公里也是要注意数据的正确使用，要跟数据责任人确认其使用方式及适用场景，避免出现引用表错误、限定条件设置错误、关联错误等，同时要保证口径对齐，这里涉及到OneData体系建设，内容比较多的，以后有机会再分享。

只有上游数据源统一、中游加工配置无误、下游使用得当，最后才能得到可靠、有用的数据价值。

当然前面也提到必须要保证每个环节都能达到99%以上的准确率，最终的交付物合格率才有可能达到99%。因此数据出错不可怕，只要能做到及时发现问题、保证沟通流畅，减少数据影响范围，降低损失，如此往复循环，数据可靠性也会越来越高。