数据质量体系结构介绍

《数据质量体系结构介绍》由会员分享，可在线阅读，更多相关《数据质量体系结构介绍（6页珍藏版）》请在装配图网上搜索。

1、数据质量体系结构介绍2008-05-12作者:杜绍森编译来源:IT168导读: 本文提供一个在数据仓库项目的实施过程中，可增量添加的、可扩展的数 据质量体系结构，它可以保证以最小的对前期投资的影响，并增加到存在的数 据仓库和数据集成环境中。使用这个架构，也可以实现项目系统化的向 6Sigma 质量管理体系的扩展。这个架构的设计也是针对数据仓库领域缺乏的公开的、 一致的说明数据质量的问题来进行组织的。本文提供一个在数据仓库项目的实施过程中，可增量添加的、可扩展的数 据质量体系结构，它可以保证以最小的对前期投资的影响，并增加到存在的数 据仓库和数据集成环境中。使用这个架构，也可以实现项目系统化的向

2、6Sigma 质量管理体系的扩展。这个架构的设计也是针对数据仓库领域缺乏的公开的、 一致的说明数据质量的问题来进行组织的。有三股力量已将对将数据集成、数据质量的关注呈现在组织管理层优先执 行活动中。它们是：一、普遍地认为如果仅能看到数据，而无法确定其质量等 级，就无法更好的管理的业务的认识，正在持续增长。绝大多数的知识工作者 相信对自身的工作职能来说，数据是至关重要的;二、绝大多数的全球化的，分 布式的组织机构逐步形成共识，集成分散在全球各地的业务数据是企业竞争力 的必要因素;三、急剧增长法律符合性的要求也是一个重要的因素。仅这三个方面的驱动力，对于强调数据质量的问题显然还并不充分。幸运 的是

3、，还有一股强大的动力正来自除了 IT部门以外的业务人员。业务人员正 在逐步的认识到数据质量问题是一个严重的，需要高昂的成本的问题，这样， 组织主动性地提供数据质量就有了更大的动力。但是，多数的业务人员可能并 不能完全了解数据质量问题产生的原因，找到提高数据质量的方法。有时他们 认为数据质量问题主要是IT部门操作层面的问题。在这样的情况下，IT部门就 应该更加认识到：数据质量问题不可能仅通过IT部门来单独改善，更需要业务 部门的积极、主动参与。事实上，数据质量领域一个极端的看法认为： 数据质 量问题几乎和IT没有任何的关联。在关注数据质量时，如果仅仅要求前台的操作人员在输入数据时保持足够 的细心

4、，或要求销售人员在录入订单的客户和产品信息时保持足够的仔细显然 都是不够的。我们还可以通过在数据的录入界面上附加更加严格的技术性约束 来避免和修复数据的质量问题。这些方法提供了一些修复或避免数据质量问题 的线索，但是在采取这些技术性措施之前，我们需要用一个更大的视野关注数 据质量问题。例如：在一个零售银行，身份证号码是空白的或者是填入了一些 垃圾信息。一个不错的想法是增加一个诸如必须满足 999-99-9999的技术限 制，系统不接受任何不满足格式约束的输入信息。在这种约束下，身份证号码 可能不再为空或者任何字符数据，但前台的数据录入人员就会由于完成后续工 作的需要而被强迫录入有效的身份证号码

5、，但在并没有客户有效身份证号码的 情况下，他们只好使用了自己的身份证号码。1. 建立质量传统、重建运行过程众所周知，如果没有来自组织高层对建立企业范围的数据质量体系的承 诺，技术人员说明的数据质量问题尝试往往很难发挥作用。在日本，汽车制造 商通常将控制数据质量的态度渗透到组织的各个层面，从CEO到一线的生产线 人员，从而保证了其准确、高效的决策效率。为了说明管理层对建立数据质量 文化的重要性，我们使用一个大型的连锁药店作为例子来说明，在这家药店， 采购部门和数量庞大的供应商保持合作、供应关系。在采购部，采购助理将每 一个采供来的药物录入到IT系统当中，这些信息包含大量的属性。这样采购助 理会面

6、对巨大的工作量，他们不得不评估一个小时他们可以录入多少的数据， 多长时间才可以将这些信息录入完毕。同时，采购助理也没有清晰的概念，谁 将使用那些数据，那些数据对那些使用者更加重要。有时，采购助理会由于明 显的输入错误受到指责，但更麻烦的情况是，采购助理拿到的数据本身就是不 完整或不可靠的。例如：对药物的毒性水平，没有规范化的标注，长期以来， 不同的药品，不同的品类，这个指标都是各不相同的。那么，这个药店应该如 何提高数据质量呢?这里有一个9步骤的数据质量模版，它不仅可以用到这个 药店，也可以应用到其他任何一个希望对数据质量进行管理的组织。这9个步 骤包括： 获得来自组织高层对数据质量文化的承诺

7、 在执行层面上，形成保证数据质量的工作流程 对提高数据录入的环境有所投资 提高应用间集成性 需要投入成本来改变存在问题的工作流程 提高 end-to-end 的团队理解 提升部门间的协作 公开的表彰数据质量提升的事件 提供持续的过程，不断的量度和提升数据质量从上面我们可以看到，在这个药店，需要一些资金用于修改数据数据录入系 统，为采购助理提供一些录入时的选择和上下文提示。公司的管理层也需要明 确地强调采购助理工作的重要性，指明采购助理的工作是公司各个层面决策正 确、有效性的基础。采购助理的辛勤工作应该受到来自管理层的公开的表彰， 并进行奖励。从而达到实现团队的 end-to-end 互相了解和

8、欣赏。在执行层的支持和组织框架就需之后，就需要选用特定的技术方案。后 面，我们将讨论如何选择、使用恰当的技术来支持数据质量目标。这些技术目 标包括： 早期的诊断和治疗数据质量问题 明确对源系统的需求，集中力量提供更高质量的数据 明确地描述在抽取、转换和加载过程中遇到的数据的错误问题 提供捕捉数据质量问题的框架 提供精确的度量数据质量的框架 为最终的数据提供质量信心度量2. 数据质量探查的角色数据质量探查是一种描述数据上下文、一致性、数据结构的分析技术。某 种意义上说，当使用SELECT DISTINCT对某些字段数据查询时，就在完成一 个数据质量探查的工作。现在，已经有很多功能强大的工具可以帮

9、助完成数据 质量探查的工作。一般来说这些工具已经提供了非常方便的接口来帮助用户了 解数据和数据间的关系。在数据仓库项目中，数据质量探查可以同时在战略和 战术的的层面上扮演重要角色。在 DW 项目开始时，一个数据源确定之后，就 需要首先对它进行一次快速的数据质量探查过程来评估数据质量，为是否才用 其作为有效的数据源作为策依据。理想的情况下，这种战略性的评估应该在 1， 2 天内完成。早期的了解数据、揭示数据的问题是一个负责任的步骤。几个 月后才进行这项工作，对项目的目标有可能会是致命的。从战略的角度决定将这个数据源纳入到项目中后，还需要有一个详细的战 术性的数据质量探查来尽可能揭示更多的数据问题

10、。在这个阶段揭示的问题最 终需要呈现在详细的规格说明中来处理，处理的方式包括：1) 将这些数据反馈 给源系统，提请修正这些问题;或2)将这些问题数据的处理融合到ETL过程 中。我们相信绝大多数的数据问题都可以在这两个过程中揭示出来，并得到解 决。3. 质量 Screen质量Screen是数据仓库ETL架构的心脏，在数据流图中它担负着数据质量 医生的作用。质量Screen简化了在ETL或数据迁移过程中测试工作实践。如果 测试通过，一般不需要记录任何事情;但是如果测试失败，Screen必须要完成： 将错误事件记录到错误事件主题中，并 选择中止处理过程，将用于恢复的数据放到的临时存储中或者仅仅标记

11、错误的数据所有的质量Screen在架构上是相似的，参照Jack Olson的分类方式，分为 三个简单类型：列Screen、结构Screen和业务规则Screen。列 Screen 用于测试单一列中的数据。列 Screen 过程通常比较简单，进行一 些比较明显的测试，如：某个列包含不希望的NULL，列值超过了定义的列的 精度，或列值不满足格式的要求。结构Screens测试跨列的数据间关系。例如：列间的层次关系、一对多的关 系。结构Screens包括测试两个表域间的主外键关系，也包括对邮政地址的整 个数据块的测试。业务规则Screens实现更加复杂的、不适合列和结构Screens的测试。例 如：客

12、户的 Profile 可以进行依赖时间的业务规则进行测试。如：白金卡的常旅 客要求至少5年，并每年至少 2万公里的飞行距离。业务规则测试也可以进行 聚合规则的阕值的测试等。4错. 误事件主题模型错误事件主题模型是一个集中式的维主题模型，它用来在保存质量 Screens 过程中抛出的错误事件。这个方法可以方便应用在通常的数据集成应用中。这个模型的主表是错误事件事实表。它的粒度是在ETL或数据迁移时质量 Screens 中抛出的错误事件。事实表的粒度是事实表纪录内容的物理描述。即， 每一个质量 Screen 错误在这表中产生一条记录，表中每一条记录对应一个发现 的错误。错误事件的主题模型包含的维表

13、包括错误发生的日历日期、Screen和Batch 工作维。日历日期不是用分秒表示的时间戳信息，而是提供了一种通过通用的 日历日期属性对错误事件提供约束和聚合的有用信息，例如：工作日、财年的 最后一天等这样的描述信息。事实表中的Time-of-day列则是一个完整的时间 戳，用于精确的描述错误发生的时间。这样格式在希望用时间做一些计算方面 是非常有用的，例如计算两次错误发生的时间间隔等。Batch维不仅能处理批操作，也可包含持续的操作过程。Screen维精确的描 述了 Screen的标准是什么，当错误发生时我们应当做什么?（中断处理、发出信 息挂起某些操作或者仅仅对数据进行标记等）。错误事实表包

14、含一个唯一的主键Error Event Key。和维表的主键一样，这 是一个用整数序列生成的代理键。这个键域是非常有必要的，保证大量的错误 在一次操作中同时发生时，将其加入到这个事实表当中的时候。当然，这种错 误情况最好不要发生。这个错误事件主题还包含另外一个事实表，以更加详细的粒度纪录这个发 生的问题。在这个表中的每一条记录标示了数据记录中发生错误的每一个域。 这样，就可以记录和处理诸如复杂的结构或者业务规则在更高的层面上发生的 问题。这样的错误有可能在Event Detail事实表中产生多条记录。两个事实表通 过Error event域间的主外键关系进行关联。这样Error Event D

15、etail表就可以从 表、记录、域的角度精确的描述发生的问题，同样在这个表中通过主外键关系 继承来自高粒度事实表的 Date、Screen、Batch 的信息。到目前为止，我们已经 拥有了一个可以处理复杂的多域、多错误的主题模型。错误事件细节表也可以包含精确的时间戳用于提供完整的、精确的描述在 一段时间内错误多个纪录的聚合阕值问题。5. 响应质量事件从上面，已经注意到对每一个质量 Screen 都需要有所应对。可能的选择包 括：1）终止处理过程; 2）设置防御性标志挂起进程用于后续的附加操作;3）标记问 题内容，继续后续的处理。这三个选项都可能不是的最佳选择。中断处理是一 个明显的痛苦的选项，

16、中断之后，我们还不得不进行手工的干预、诊断，选择 重新启动、从断点处处理或者完全的结束这次的工作，进行异常恢复。选择挂 起也不是一个很好的选择，因为没有人清楚什么时间问题可以被修复，甚至是 否可以被修复。一般的推荐，对很小的数据问题，尽量不要使用挂起的策略。 第三个选择，标记问题数据继续进行处理往往是比较好的。错误事实表的数据 在下面的审计维中会有所讨论。错误的维数据也可以借鉴审计维的方式，同时 为了以防万一，对数据丢失或者产生垃圾数据，也可以用域本身对错误进行标 记处理。6. 建立审计维审计维和其他维类似，在ETL后台处理中与事实表关联。Shipment是一个 典型的事实表，包含一大串的外键

17、用来与维表关联，还有三个用DD标示的退 化维和 6个数字的域。这是数据仓库维模型设计中是一个典型的结构。审计维包含事实表创建过程的元数据描述。数据质量系统的设计人员可以 选择在错误发生时，保存获得或多或少的元数据记录。用上面的例子说明审计 维表的产生产生过程。假如Shipment事实表每天以批操作的方式处理一次。今 天运行的非常好，没有任何的错误纪录或标记。在这种情况下，只需要在审计 表中生成一条审计纪录。这样，所有的错误信息对每一条事实记录将是相同 的，它的作用仅是表明今天的工作一切正常。如果上面的假设不存在，运行进程或者数据常常发生问题，例如，折扣数 据有问题，触发了一个Out-of-Bo

18、und错误。就需要在审计维表中用一些信息来 记录发生的问题，需要考虑如何对错误条件和版本号选择恰当的值，将错误问 题的主外键关系进行恰当的关联。更多的关于这方面的详细信息请参阅The Data Warehouse ETL Toolkit 2004。在完成最终的审计报告时，看看下面的审计报表，会发现一些可爱的地方。7. 应用 Six Sigma 质量标准借鉴制造业成功的质量管理实践，这些经验在数据仓库的领域也是非常有 用的。在制造商的世界里，6 Sigma质量实践已经在帮助他们取得了具体、明显 的质量进步，甚至将缺陷率降低到百万分之 3到 4的水平。而错误事件主题模 型是一个非常好的基础，可以用

19、来才采用6 Sigma标准来指导数据仓库领域的 质量的实践。在错误事实主题中记录的所有的错误事件使得我们有机会通过使 通过特定的机制对质量问题进行监控、评估，用于未来的改善。本文中描述的数据质量框架，提供了一种可以以较小的代价，增量的添加 到已有的数据仓库和数据集成环境中。一旦错误事件主题模型成功地建立之 后，我们可以根据实际的环境确定质量Screen实施进度。需要完成的就是后面 两个具体的两个工作：记录每一次发生的问题;决定对特定问题的特定的处理方 式。错误Screen的实现并不拘泥于特定的技术，可以嵌入自己的代码中，也可 以借助于特定的专业化的 ETL 工具。当然，数据质量管理过程是一个没有终点的过程，也没有统一架构原则。 这里提供的是一种针对数据仓库项目可以简单实现的、可扩展的、一种相对比 较完善的捕捉数据质量事件，同时对其进行量度和控制的方法。