这几年一直在互联网公司从事数据分析数据产品相关的工作，因此主要从过去工作中碰到的数据质量的问题中引申出来的一些想法和执行情况。
最早入门做数据分析的时候，我主要依赖google analytics来做网站的流量分析。这个时期是没有数据质量问题的——因为全部是用的google的标准和定义，我要做的就是学习它的规则。
我第一次遇到数据质量问题，是在百度做一个行业分析数据产品的时候。这个时期的数据质量的问题主要来自于移动设备数据上传的不稳定性。当时的产品需要应用调用系统的某些接口来获取数据来进行统计，数据在采集和上传的时候会有一部分数据丢失，导致部分数据记录不全或者纪录丢失的情况。
从这里我得到的经验就是在做移动端相关产品的数据分析和产品时，第一要务就是保证客户端采集和上传数据的稳定性和一致性——确保不同版本客户端发布的时候原始数据采集的口径一致，以及在复杂网络状况以及用户行为情况下数据上传策略合理。
当然有些时候我们不可能保证数据完全的正确。毕竟数据上传的时候用户的移动网络断掉，以及跨天行为统计所产生的误差是不可避免的。移动客户端的数据总会有那么百分之零点几的差异，但是只要在可控的范围内，就可以保证后续生产数据的质量。
2012年的时候有幸参与到百度公司级别的一次大数据平台建设浪潮中。当时基础架构部与移动云事业部联合开展了一个针对移动云所有产品线的大数据平台落地计划。
因为历史原因，当时移动云的数据治理以及数据应用的状况不太理想。各个产品线各自为战，自己打自己的产品log，然后自己从log中取出自己想要的计算字段算出结果来分析产品。这种方式不仅效率低下，而且同一个事业部的不同产品数据不能打通分析，更妄谈同其他事业部甚至PC端的搜索数据打通了。
解铃还需系铃人。
当时最需要做的事是将各产品线的用户标识统一，然后统一对用户行为log进行统一定义，所有的log在录入DT平台时，均需要按照统一的schema来录入。这样做会导致很多的历史数据丢失，但是让后续所有的产品线依赖公司统一大平台资源（比如后来做推广时，整体可以用同一套推广系统和质量管控系统等）。
这个过程中，以什么为规范来做统一的定义是一个比较麻烦的事情，如果重新定义一套，会导致数据没有延续性，对自身内伤严重。所以当时产品部门内部商定了以搜索产品为核心来制定整体标准，简单来说就是所有的产品采用搜索产品历史沿袭的log定义规则来进行修改。最终达成客户端日志的统一性。
除了客户端的统一定义之外，数据平台方对数据表的schema设计也很重要，这直接决定了数据录入之后的数据质量。
