企业大数据质量管理的一些经验 - 知乎专栏 https://zhuanlan.zhihu.com/p/25309728
将各产品线的用户标识统一，然后统一对用户行为log进行统一定义，所有的log在录入DT平台时，均需要按照统一的schema来录入。
除了客户端的统一定义之外，数据平台方对数据表的schema设计也很重要，这直接决定了数据录入之后的数据质量。
//
因为百度内部有很好的wiki系统，这套系统设计完成之后，所有log的定义、User Data Warehouse中的fact tables和dimension tables都在wiki上有明确的记录，方便后来者对知识的继承。
后来系统上线之后，我们通过对数据的diff工作，将数据处理环节中可能导致数据异常的问题全部排查了一遍（这些大部分都是一次性工作），最终保证了最后分析平台上线时数据的质量。
//
总结起来就只有几点：
– 定义明确
– 策略清晰
– 规范统一
– 知识继承
– 误差可解释
当然，不论前期做得多么好，数据diff的工作要认真做，这将是最佳的全盘检查的机会。
这几年一直在互联网公司从事数据分析数据产品相关的工作，因此主要从过去工作中碰到的数据质量的问题中引申出来的一些想法和执行情况。
Google最早建立了网站的数据质量标准
最早入门做数据分析的时候，我主要依赖google analytics来做网站的流量分析。这个时期是没有数据质量问题的——因为全部是用的google的标准和定义，我要做的就是学习它的规则。
移动产品的数据质量须从客户端开始，且越早越好
我第一次遇到数据质量问题，是在百度做一个行业分析数据产品的时候。这个时期的数据质量的问题主要来自于移动设备数据上传的不稳定性。当时的产品需要应用调用系统的某些接口来获取数据来进行统计，数据在采集和上传的时候会有一部分数据丢失，导致部分数据记录不全或者纪录丢失的情况。
从这里我得到的经验就是在做移动端相关产品的数据分析和产品时，第一要务就是保证客户端采集和上传数据的稳定性和一致性——确保不同版本客户端发布的时候原始数据采集的口径一致，以及在复杂网络状况以及用户行为情况下数据上传策略合理。
当然有些时候我们不可能保证数据完全的正确。毕竟数据上传的时候用户的移动网络断掉，以及跨天行为统计所产生的误差是不可避免的。移动客户端的数据总会有那么百分之零点几的差异，但是只要在可控的范围内，就可以保证后续生产数据的质量。
多产品线最重要的是用户标识的一致
2012年的时候有幸参与到百度公司级别的一次大数据平台建设浪潮中。当时基础架构部与移动云事业部联合开展了一个针对移动云所有产品线的大数据平台落地计划。
因为历史原因，当时移动云的数据治理以及数据应用的状况不太理想。各个产品线各自为战，自己打自己的产品log，然后自己从log中取出自己想要的计算字段算出结果来分析产品。这种方式不仅效率低下，而且同一个事业部的不同产品数据不能打通分析，更妄谈同其他事业部甚至PC端的搜索数据打通了。
解铃还需系铃人
当时最需要做的事是将各产品线的用户标识统一，然后统一对用户行为log进行统一定义，所有的log在录入DT平台时，均需要按照统一的schema来录入。这样做会导致很多的历史数据丢失，但是让后续所有的产品线依赖公司统一大平台资源（比如后来做推广时，整体可以用同一套推广系统和质量管控系统等）。
这个过程中，以什么为规范来做统一的定义是一个比较麻烦的事情，如果重新定义一套，会导致数据没有延续性，对自身内伤严重。所以当时产品部门内部商定了以搜索产品为核心来制定整体标准，简单来说就是所有的产品采用搜索产品历史沿袭的log定义规则来进行修改。最终达成客户端日志的统一性。
除了客户端的统一定义之外，数据平台方对数据表的schema设计也很重要，这直接决定了数据录入之后的数据质量。
因为百度内部有很好的wiki系统，这套系统设计完成之后，所有log的定义、User Data Warehouse中的fact tables和dimension tables都在wiki上有明确的记录，方便后来者对知识的继承。
后来系统上线之后，我们通过对数据的diff工作，将数据处理环节中可能导致数据异常的问题全部排查了一遍（这些大部分都是一次性工作），最终保证了最后分析平台上线时数据的质量。
更多的问题来自对数据的定义
继续下去的经历中，基本上客户端的数据质量问题都比较容易的解决掉了。反而是业务需求端定义不明确的问题一而再的发生——特别是业务流程比较复杂的时候。比如当时在滴滴打车有这么一个指标：订单完成数。这里有个问题，订单是结束计算完成还是支付算完成？然后你就发现：
– 如果按照订单结束，不论支付来看，那么一个跨越12点的订单会在第一天计算成一个未完成订单，第二天多一个完成订单。数据回溯可以解决这个问题，但是你会发现当你回头看历史数据时，数字总是在变的。
– 如果按照订单支付结束来计算——数据回溯都解决不了跨天的问题了，因为好几天之后再支付的用户比比皆是。
这种情况在周五以及节假日前出现的情况尤其多，导致那时候的数据基本不可用，而且很多策略出现问题——当时有个政策是对一天拉满N单的司机进行奖励，那么到了凌晨的时候，有些忙着完成任务的司机会拒绝接受长途订单，然后用户就不开心了。
之后我们就将这一个指标拆解成订单完成数和订单支付支付完成数，这两个数据不进行数据回溯，只是按照订单最终状态发生的时候来计算。但是在计算订单完成率和订单支付成功率时，我就比较烦恼了，然后这个问题直到我最终离职也没有比较好的解决办法（求高手支招）。
絮絮叨叨说了这么多，其实总结起来就只有几点：
– 定义明确
– 策略清晰
– 规范统一
– 知识继承
– 误差可解释
当然，不论前期做得多么好，数据diff的工作要认真做，这将是最佳的全盘检查的机会。
欢迎大家扫码关注数据产品经理公众号，如想加入《数据产品经理会》群，请加 刘洋 微信：liuyangfjnu 。
