大型数据仓库的治理(2)- 数据质量不可靠

文/通贯

【导读】数据仓库治理系列文章，本文是第二篇，你可以回复数据仓库(当然需要先关注微信号alibabatech)查看整个系列。作者从实际经验中，总结出了一些大型数据仓库治理中，可能会遇到的问题。本文谈到了“数据质量不可靠”的问题，大数据时代，你值得关注。

 

    对于程序员来说，最头疼的就是听到：“大兄弟，你这个程序有BUG吧”，那么对于数据开发人员来说，最头疼的问题应该莫过于：“哥们/姐们，你这数据不靠谱啊.....”，这是让数据开发人员最头疼的问题，这其实说的就是数据质量的问题。

 

    数据质量不可靠体现在两个个方面：数据不一致，数据不可信。

 

一 、数据不一致

    有时候经常接到这样的消息：

 

    亲，今天UV怎么暴涨这么多？什么原因？

    亲，这里的XX指标与XX数据的不一致，那个靠谱？什么原因？

 

    第一种情况，数据出现异常波动，属于数据指标自身纵向不一致。造成此问题的原因多为ETL程序健壮性不够，由于数据源发生变化，ETL程序不能兼容次变化，导致结果数据异常波动。

    

    防止此类问题发生的办法，一是要做好上下游变更通知机制，让下游能预知上游的变更，以便做好准备和处理。另一方面，ETL程序要有一定的兼容性，尽可能避免一些异常数据导致结果数据错误。

 

    从数据仓库建模角度，通过分层能有效控制这类问题的发生。在ODS层统一处理LOG的变化和异常；或者在DW层中，设一个适配层，专门适配上游的各种变化。

 

     第二种情况，属于数据统计口径问题。不同的数据团队，或统一团队的不同人员，对同一个业务指标的理解不一致，各自在统计的时候做了特殊的过滤或者其他处理，导致数据结果不一致。还有一种可能就是开发人员为了满足某个特定需求，做个特别的处理，而下游引用此数据的成员不知情，导致数据不一致的产生。

    

    解决这一问题，首先要有全局意识。个人生产的数据不是仅仅为自己服务，不仅仅是为某个需求服务。而要把数据看做公司的，集体的资产，开发人员要对本数据正确性负责，也要对下游能简单明了地理解本数据负责。要做好团队间和团队内部的工作协同，能互通有无，有变化有情况能即时周知。

    

    另一方面就是工作的标准化、专业化。除了上层应用可以有个性化，可以有锦上添花，数据仓库中下层一定要是标准化的，规范化的，应该有统一的规划和设计，不要因人而异。还要加强数据仓库建模技术的培训，让新人能掌握建模技术和规范，也要让团队成员达成一致，采用相同的建模技术和方法。具体到仓库模型，ODS和FACT层不要面向具体数据需求，不要做特别的处理。如果有特别口径的指标怎么办？那就新建一个指标。

     

    有很多的数据仓库工具，用于辅助标准化、专业化。元数据管理非常重要。元数据一方面描述数据仓库的系统信息。更重要的的方面是描述数据本身，描述数据仓库包含什么数据，数据如何组织，数据在什么地方；还有每个指标的统计口径，数据口径的描述功在当代，利在千秋，一定不要偷懒。举个简单的例子，在大系统里边，可能几百个表里涉及到成交金额，但是都没有文档化描述金额单位是元还是分，每次开发的时候都需要去询问责任人，后者一层一层翻代码，真的很累，很低效，而且还有看错的风险。

 

二、数据不可信

有如下场景：

    老板拿着一份报表问：这个数据靠谱吗？我要拿去和客户讲....

两种回答

 

A：没问题。......

B：我回去核实一下......

    如果是你，你能否做出坚定的回答呢？

  

    这个例子和数据可靠性有什么关系呢？每次听到这个问题，都是对数据仓库的一次检验，也是对数据仓库工程师的一次考验。

    

    要做出坚定的回答不容易。一方面，要对业务要有认识，要经常看数据，保持对数据的敏感。例如：你看到某天成交额是10亿，根据你的业务认识，结合近期的数据，你肯定能做出一个肯定的回答。如果有人告诉你某天成交额是100亿，你很难做出肯定回答。

    

    另一方面，良好的数据仓库设计，能让你对数据质量充满信心。面对数据正确性的质疑，尽管90%的case，数据都是正确的，但总得花很多时间去验证正确性。所以数据便于追溯验证非常必要。

    

    为了便于验证数据，数据流不能太复杂，每个指标都有统一的数据来源，而不是N个近似来源；数据流层次要清晰，从ODS到RPT层，最好不要超过5层，云梯上很多表，依赖层次都是20层以上，这是有非常大的风险的。如果数据流程清晰，因此数据验证效率高代价低，会带来一系列的良性循环。如果有别要的话可以开发一套数据指标监控和验证的程序，来做系统性的保障。

 

    总之，数据质量问题归根结底是数据仓库治理的问题。从管理上要做好协同、规范、标准；从数据仓库设计上要层次分明、数据流程简洁；同时要用数据仓库的元数据管理、数据质量监控验证系统等组件来辅助解决问题。