数据质量体系结构介绍

　　数据质量探查是一种描述数据上下文、一致性、数据结构的分析技术。某种意义上说，当使用SELECT DISTINCT对某些字段数据查询时，就在完成一个数据质量探查的工作。现在，已经有很多功能强大的工具可以帮助完成数据质量探查的工作。一般来说这些工具已经提供了非常方便的接口来帮助用户了解数据和数据间的关系。在数据仓库项目中，数据质量探查可以同时在战略和战术的的层面上扮演重要角色。在DW项目开始时，一个数据源确定之后，就需要首先对它进行一次快速的数据质量探查过程来评估数据质量，为是否才用其作为有效的数据源作为策依据。理想的情况下，这种战略性的评估应该在1，2天内完成。早期的了解数据、揭示数据的问题是一个负责任的步骤。几个月后才进行这项工作，对项目的目标有可能会是致命的。

　　从战略的角度决定将这个数据源纳入到项目中后，还需要有一个详细的战术性的数据质量探查来尽可能揭示更多的数据问题。在这个阶段揭示的问题最终需要呈现在详细的规格说明中来处理，处理的方式包括：1) 将这些数据反馈给源系统，提请修正这些问题;或2) 将这些问题数据的处理融合到ETL过程中。我们相信绝大多数的数据问题都可以在这两个过程中揭示出来，并得到解决。

　　3. 质量Screen

　　质量Screen是数据仓库ETL架构的心脏，在数据流图中它担负着数据质量医生的作用。质量Screen简化了在ETL或数据迁移过程中测试工作实践。如果测试通过，一般不需要记录任何事情;但是如果测试失败，Screen必须要完成：

　　● 将错误事件记录到错误事件主题中，并

　　● 选择中止处理过程，将用于恢复的数据放到的临时存储中或者仅仅标记错误的数据

　　所有的质量Screen在架构上是相似的，参照Jack Olson的分类方式，分为三个简单类型：列Screen、结构Screen和业务规则Screen。

　　列Screen用于测试单一列中的数据。列Screen过程通常比较简单，进行一些比较明显的测试，如：某个列包含不希望的NULL，列值超过了定义的列的精度，或列值不满足格式的要求。

　　结构Screens测试跨列的数据间关系。例如：列间的层次关系、一对多的关系。结构Screens包括测试两个表域间的主外键关系， 也包括对邮政地址的整个数据块的测试。

　　业务规则Screens实现更加复杂的、不适合列和结构Screens的测试。例如：客户的Profile可以进行依赖时间的业务规则进行测试。如：白金卡的常旅客要求至少5年，并每年至少2万公里的飞行距离。业务规则测试也可以进行聚合规则的阕值的测试等。

4. 错误事件主题模型

　　错误事件主题模型是一个集中式的维主题模型，它用来在保存质量Screens过程中抛出的错误事件。这个方法可以方便应用在通常的数据集成应用中。在下图可以见到错误事件的ER模型：

　　图1： 错误事件主题模型

　　这个模型的主表是错误事件事实表。它的粒度是在ETL或数据迁移时质量Screens中抛出的错误事件。事实表的粒度是事实表纪录内容的物理描述。即，每一个质量Screen错误在这表中产生一条记录，表中每一条记录对应一个发现的错误。

　　错误事件的主题模型包含的维表包括错误发生的日历日期、Screen和Batch工作维。日历日期不是用分秒表示的时间戳信息，而是提供了一种通过通用的日历日期属性对错误事件提供约束和聚合的有用信息，例如：工作日、财年的最后一天等这样的描述信息。事实表中的Time-of-day列则是一个完整的时间戳，用于精确的描述错误发生的时间。这样格式在希望用时间做一些计算方面是非常有用的，例如计算两次错误发生的时间间隔等。

　　Batch维不仅能处理批操作，也可包含持续的操作过程。Screen维精确的描述了Screen的标准是什么，当错误发生时我们应当做什么?(中断处理、发出信息挂起某些操作或者仅仅对数据进行标记等)。

　　错误事实表包含一个唯一的主键Error Event Key。和维表的主键一样，这是一个用整数序列生成的代理键。这个键域是非常有必要的，保证大量的错误在一次操作中同时发生时，将其加入到这个事实表当中的时候。当然，这种错误情况最好不要发生。

　　这个错误事件主题还包含另外一个事实表，以更加详细的粒度纪录这个发生的问题。在这个表中的每一条记录标示了数据记录中发生错误的每一个域。这样，就可以记录和处理诸如复杂的结构或者业务规则在更高的层面上发生的问题。这样的错误有可能在Event Detail 事实表中产生多条记录。两个事实表通过Error event域间的主外键关系进行关联。这样Error Event Detail表就可以从表、记录、域的角度精确的描述发生的问题，同样在这个表中通过主外键关系继承来自高粒度事实表的Date、Screen、Batch的信息。到目前为止，我们已经拥有了一个可以处理复杂的多域、多错误的主题模型。

　　错误事件细节表也可以包含精确的时间戳用于提供完整的、精确的描述在一段时间内错误多个纪录的聚合阕值问题。

5. 响应质量事件

　　从上面，已经注意到对每一个质量Screen都需要有所应对。可能的选择包括：1)终止处理过程; 2)设置防御性标志挂起进程用于后续的附加操作;3)标记问题内容，继续后续的处理。这三个选项都可能不是的最佳选择。中断处理是一个明显的痛苦的选项，中断之后，我们还不得不进行手工的干预、诊断，选择重新启动、从断点处处理或者完全的结束这次的工作，进行异常恢复。选择挂起也不是一个很好的选择，因为没有人清楚什么时间问题可以被修复，甚至是否可以被修复。一般的推荐，对很小的数据问题，尽量不要使用挂起的策略。第三个选择，标记问题数据继续进行处理往往是比较好的。错误事实表的数据在下面的审计维中会有所讨论。错误的维数据也可以借鉴审计维的方式，同时为了以防万一，对数据丢失或者产生垃圾数据，也可以用域本身对错误进行标记处理。

上一页  [1] [2] [3] 下一页

【责编:Ken】