二、 原因分析和解决思路
  数据质量存在问题的根本原因在于数据源，保证数据质量是很困难的事情。这是事实，但是那一些潜在的问题会带来数据质量问题呢？可以归为以下几类：
1. 数据格式问题,l例如数据缺失，超出数据范围，无效数据格式等等。
2. 数据一致性问题，处于数据库性能考虑，有时候可能会有意的去掉一些外间或者检查约束。
3. 业务逻辑问题，这个很难说正确还是错误，通常是由于数据库设计得不够严格或者谨慎。

  构造数据仓库系统时，完全理解业务系统的业务逻辑和整体情况是不可能的。我们不能完全去研究那些详细的设计文档，同时后来的很多需求变更也并不完全放映到文档上来，因此需要花费大量的时间去定位和分析其中的原因和变化。用户要求在进行ETL之前必须了解所有的业务逻辑和规则，显然也是不现实的。个人认为我们只需要了解和处理那些可能遭遇问题的数据。我们必须决定这些数据是拒绝呢还是处理。假如数据质量得不到保证的话，在后续的处理过程中，这样的错误将逐渐被放大。
正是因为数据质量问题贯穿于项目的整个生命周期，而且不能避免，我们必须面对而且给出解决办法，尽量把影响减小到最少。
通常情况下，当我们遇到错误数据，ETL一般提供以下4种解决办法：
1. 没有任何处理的通过记录
2. 通过记录，打上错误标记
3. 拒绝记录
4. 停止ETL任务

下面就这几种情况进行一下分析：
首先选项1明显不能保证数据质量，并将最终影响报表质量。
其次选项3也不能保证数据完整性，因为数据将发生遗弃，也将会影响报表质量。
再次选项4会影响ETL处理，导致数据仓库不能正常运行下去。
所以，最常见的处理方式就是选项2，首先保证这些记录顺利通过，然后记录一些错误标志，并通过报表反映出来。

这样做有以下四种好处：
1. 通过特殊处理确保了数据的完整性
2. 反映了数据仓库的数据源数据质量
3. 对数据质量可以有一个比较准确的度量
4. 确保了数据仓库的顺利实施和任务的正常调度
数据质量应该尽量确保在ETL环节中进行，因为每一点的错误都会导致后续处理的无限放大，同时数据仓库的处理是线性进行的，当发现错误时，很难回过头来对数据进行重新的处理。因此尽量把错误和数据质量问题消除在靠前的位置。