[转]ETL随笔（三）

http://www.alidw.com/?p=781 

记得自己曾经实施的第一个数据仓库的项目上线后，我的师傅问我的第一个问题是“你认为数据仓库这种类型的项目什么才是最重要的？”我当时毫不犹豫的回答“是供数的效率，从源系统抽取完数据经过ETL并加载到目标表到给下游系统供完数据的时间间隔越短越好”，当时我的师傅告诉我最重要的应该是数据质量，一个数据仓库出来的数据最起码你应该保证你的数据可以被别人使用，它不需要绝对的数据准确，但是你必须要知道为什么不准确。确实，对绝对的数据准确谁也没有把握，不仅是系统集成商，包括客户也是无法确定。准确的东西需要一个标准，但首先要保证这个标准是准确的，至少现在还没有这样一个标准。客户会提出一个相对标准，例如将你的OLAP数据结果和报表结果对比，这是一个很痛苦的事情，因为这个完全就是一种不公平的比较，因为造成数据不准确的原因有太多了，但是没办法，你只能认了，但是不可否认，这种方法还真的是对于数据仓库的数据准确行的最直接有效最快捷的验证方式。

 

          现在我们来谈谈究竟有哪些原因可能导致数据质量的问题，粗略的归纳了一下，个人觉得应该可以分为如下几个方面：

1）数据格式错误，例如缺失数据、数据值超出范围或是数据格式非法等。要知道对于同样处理大数据量的数据源系统，他们通常会舍弃一些数据库自身的检查机制，例如字段约束等。他们尽可能将数据检查在入库前保证，但是这一点是很难确保的。这类情况诸如身份证号码、手机号、非日期类型的日期字段等。

2）数据一致性，同样，数据源系统为了性能的考虑，会在一定程度上舍弃外键约束，这通常会导致数据不一致。例如在帐务表中会出现一个用户表中没有的用户ID，在例如有些代码在代码表中找不到等。

3）业务逻辑的合理性，这一点很难说对与错。通常，数据源系统的设计并不是非常严谨，例如让用户开户日期晚于用户销户日期都是有可能发生的，一个用户表中存在多个用户ID也是有可能发生的。对这种情况，有什么办法吗？

       构建一个BI系统，要做到完全理解数据源系统根本就是不可能的。特别是数据源系统在交付后，有更多维护人员的即兴发挥，那更是要花大量的时间去寻找原因。以前曾经争辩过设计人员对规则描述的问题，有人提出要在ETL开始之前务必将所有的规则弄得一清二楚。我并不同意这样的意见，倒是认为在ETL过程要有处理这些质量有问题数据的保证。一定要正面这些脏数据，是丢弃还是处理，无法逃避。如果没有质量保证，那么在这个过程中，错误会逐渐放大，抛开数据源质量问题，我们再来看看ETL过程中哪些因素对数据准确性产生重大影响，应该有如下几个方面：

1）规则描述错误。上面提到对设计人员对数据源系统理解的不充分，导致规则理解错误，这是一方面。另一方面，是规则的描述，如果无二义性地描述规则也是要探求的一个课题。规则是依附于目标字段的，在探求之三中，提到规则的分类。但是规则总不能总是用文字描述，必须有严格的数学表达方式。我甚至想过，如果设计人员能够使用某种规则语言来描述，那么我们的ETL单元就可以自动生成、同步，省去很多手工操作了。

2）ETL开发错误。即时规则很明确，ETL开发的过程中也会发生一些错误，例如逻辑错误、书写错误等。例如对于一个分段值，开区间闭区间是需要指定的，但是常常开发人员没注意，一个大于等于号写成大于号就导致数据错误。

3）人为处理错误。在整体ETL流程没有完成之前，为了图省事，通常会手工运行ETL过程，这其中一个重大的问题就是你不会按照正常流程去运行了，而是按照自己的理解去运行，发生的错误可能是误删了数据、重复装载数据等。

        唧唧歪歪了半天，大家如果也有自己的见解，可以相互讨论一下，下一节我将会发表一些个人对于如何保证数据质量的看法。