数据质量体系结构介绍.docx

《数据质量体系结构介绍.docx》由会员分享，可在线阅读，更多相关《数据质量体系结构介绍.docx（9页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。

1、数据质量体系结构介绍作者：杜绍森编译出处：171682022-05-12 09:14数据质量管理过程是一个没有终点的过程，也没有统一架构原则。这里提供的是一种针对数据仓库项目可以简单实现 的、可扩展的、一种相对照较完善的捕捉数据质量事件，同时对其进行量度和控制的方法。本文提供一个在数据仓库项目的实施过程中，可增量添加的、可扩展的数据 质量体系结构，它可以保证以最小的对前期投资的影响，并增加到存在的数据仓 库和数据集成环境中。使用这个架构，也可以实现项目系统化的向质量管理体系的扩展。这个架构的设计也是针对数据仓库领域缺乏的公开的、一致的 说明数据质量的问题来进行组织的。有三股力量已将对将数据集成

2、、数据质量的关注呈现在组织管理层优先执行 活动中。它们是：一、普遍地认为如果仅能看到数据，而无法确定其质量等级， 就无法更好的管理的业务的认识，正在持续增长。绝大多数的知识工作者相信 对自身的工作职能来说，数据是至关重要的二、绝大多数的全球化的，分布式 的组织机构逐步形成共识，集成份散在全球各地的业务数据是企业竞争力的必要 因素三、急剧增长法律符合性的要求也是一个重要的因素。仅这三个方面的驱动力，对于强调数据质量的问题显然还并不充分。幸运的 是， 还有一股强大的动力正来自除了 部门以外的业务人员。业务人员正在逐 步的认识到数据质量问题是一个严重的，需要高昂的成本的问题，这样，组织主 动性地提供

3、数据质量就有了更大的动力。但是，多数的业务人员可能并不能彻底 了解数据质量问题产生的原因，找到提高数据质量的方法。有时他们认为数据质 量问题主要是部门操作层面的问题。在这样的情况下，部门就应该更加认识到：数据质量问题不可能仅通过 部门来单独改善，更需要业务部门的积极、 主动参预。事实上，数据质量领域一个极端的看法认为：数据质量问题几乎和 没有任何的关联。在关注数据质量时，如果仅仅要求前台的操作人员在输入数据时保持足够的 细心，或者要求销售人员在录入定单的客户和产品信息时保持足够的子细显然都 是不够的。我们还可以通过在数据的录入界面上附加更加严格的技术性约束来 避免和修复数据的质量问题。这些方法

4、提供了一些修复或者避免数据质量问题 的线索，题。例如：在一个零售银行，身份证号码是空白的或者是填入了一些垃圾信息。 一个不错的想法是增加一个诸如必须满足的技术限制，系统不接受任何不满足格式约束的输入信息。在这种约束下，身份证号码可能再也不为空或 者任何字符数据，但前台的数据录入人员就会由于完成后续工作的需要而被强 迫录入有效的身份证号码，但在并没有客户有效身份证号码的情况下，他们只 好使用了自己的身份证号码。建立质量传统、重建运行过程众所周知，如果没有来自组织高层对建立企业范围的数据质量体系的承诺， 技术人员说明的数据质量问题尝试往往很难发挥作用。在日本，汽车创造商通常 将控制数据质量的态度渗

5、透到组织的各个层面，从到一线的生产线人员，从而保证了其准确、高效的决策效率。为了说明管理层对建立数据质量文化的重要 性，我们使用一个大型的连锁药店作为例子来说明，在这家药店，采购部门和数 量庞大的供应商保持合作、供应关系。在采购部，采购助理将每一个采供来的药 物录入到系统之中，这些信息包含大量的属性。这样采购助理会面对巨大的 工作量，他们不得不评估一个小时他们可以录入多少的数据，多长期才可以将 这些信息录入完毕。同时，采购助理也没有清晰的概念，谁将使用那些数据，那 些数据对那些使用者更加重要。有时，采购助理会由于明显的输入错误受到指责， 但更麻烦的情况是，采购助理拿到的数据本身就是不完整或者不

6、可靠的。例如： 对药物的毒性水平，没有规范化的标注，长期以来，不同的药品，不同的品类 ,这 个指标都是各不相同的。那末，这个药店应该如何提高数据质量呢 这里 有一个步骤的数据质量模版，它不仅可以用到这个药店，也可以应用到其他任何一个 希翼对数据质量进行管理的组织。这个步骤包括： 获得来自组织高层对数据质量文化的承诺 在执行层面上，形成保证数据质量的工作流程 对提高数据录入的环境有所投资 提高应用间集成性 提高的团队理解 提升部门间的协作 公开的表彰数据质量提升的事件 提供持续的过程，不断的量度和提升数据质量从上面我们可以看到，在这个药店，需要一些资金用于修改数据数据录入系 统，为采购助理提供一

7、些录入时的选择和上下文提示。公司的管理层也需要明确 地强调采购助理工作的重要性，指明采购助理的工作是公司各个层面决策正确、 有效性的基础。采购助理的辛勤工作应该受到来自管理层的公开的表彰，并进行 奖励。从而达到实现团队的互相了解和欣赏。在执行层的支持和组织框架就需之后，就需要选用特定的技术方案。后面， 我们将讨论如何选择、使用恰当的技术来支持数据质量目标。这些技术目标包括： 早期的诊断和治疗数据质量问题 明确对源系统的需求，集中力量提供更高质量的数据 明确地描述在抽取、转换和加载过程中遇到的数据的错误问题 提供捕捉数据质量问题的框架 提供精确的度量数据质量的框架 为最终的数据提供质量信心度量数

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

9、责任的步骤。几个月后才进行这项工作， 对项目的目标有可能会是致命的。从战略的角度决定将这个数据源纳入到项目中后，还需要有一个详细的战术 性的数据质量探查来尽可能揭示更多的数据问题。在这个阶段揭示的问题最终需 要呈现在详细的规格说明中来处理，处理的方式包括：将这些数据反馈给源系统，提请修正这些问题或者将这些问题数据的处理融合到过程中。我们相信绝大多数的数据问题都可以在这两个过程中揭示出来，并得到解决。质量质量 是数据仓库 架构的心脏，在数据流图中它担负着数据质量 医生的作用。质量简化了在 或者数据迁移过程中测试工作实践。如果测试通过，普通不需要记录任何事情但是如果测试失败，必须要完成： 将错误事

10、件记录到错误事件主题中，并 选择中止处理过程，将用于恢复的数据放到的暂时存储中或者仅仅标记 错误的数据所有的质量在架构上是相似的，参照的分类方式，分为三个简单类型：列、结构 和业务规则 。列用于测试单一列中的数据。列过程通常比较简单，进行一些比较明显的测试，如：某个列包含不希翼的 ，列值超过了定义的列的精 度，或者列值不满足格式的要求。结构测试跨列的数据间关系。例如：列间的层次关系、一对多的关系。结构包括测试两个表域间的主外键关系，也包括对邮政地址的整个数据块的测试。业务规则 实现更加复杂的、不适合列和结构 的测试。例如：客户的 可以进行依赖时间的业务规则进行测试。如：白金卡的常旅客要 求至少

11、年，并每年至少万公里的飞行距离。业务规则测试也可以进行聚合规 则的阕值的测试等。错误事件主题模型错误事件主题模型是一个集中式的维主题模型，它用来在保存质量过程中抛出的错误事件。这个方法可以方便应用在通常的数据集成应用中。在下 图可以见到错误事件的 模型：Emr evert factScreei dlmeisionError mnt dtUM图：错误事件主题模型这个模型的主表是错误事件事实表。它的粒度是在或者数据迁移时质 量中抛出的错误事件。事实表的粒度是事实表纪录内容的物理描述。即， 每一个质量错误在这表中产生一条记录，表中每一条记录对应一个发现的错误。错误事件的主题模型包含的维表包括错误发生

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

13、误在 一次操作中同时发生时，将其加入到这个事实表之中的时候。固然，这种错误情 况最好不要发生。这个错误事件主题还包含此外一个事实表，以更加详细的粒度纪录这个发生 的问题。在这个表中的每一条记录标示了数据记录中发生错误的每一个域。这样， 就可以记录和处理诸如复杂的结构或者业务规则在更高的层面上发生的问题。这 样的错误有可能在事实表中产生多条记录。两个事实表通过域间的主外键关系进行关联。这样表就可以从表、记录、域的角度精确的描述发生的问题，同样在这个表中通过主外键关系继承来 自高粒度事实表的、的信息。到目前为止，我们已经拥有了一个可以处理复杂的多域、多错误的主题模型。错误事件细节表也可以包含精确的

14、时间戳用于提供完整的、精确的描述在一 段时间内错误多个纪录的聚合阕值问题。响应质量事件从上面，已经注意到对每一个质量都需要有所应对。可能的选择包括： 终止处理过程 设置谨防性标志挂起进程用于后续的附加操作标记 问题内容，继续后续的处理。这三个选项都可能不是的最佳选择。中断处理是一 个明显的痛苦的选项，中断之后，我们还不得不进行手工的干预、诊断，选择重 新启动、从断点处处理或者彻底的结束这次的工作，进行异常恢复。选择挂起也 不是一个很好的选择，因为没有人清晰什么时间问题可以被修复，甚至是否可以 被修复。普通的推荐，对很小的数据问题，尽量不要使用挂起的策略。第三个选 择，标记问题数据继续进行处理往

15、往是比较好的。错误事实表的数据在下面的审计维中会有所讨论。错误的维数据也可以借鉴审计维的方式，同时为了以防万一, 对数据丢失或者产生垃圾数据，也可以用域本身对错误进行标记处理。建立审计维审计维和其他维类似，在后台处理中与事实表关联。下图是针对事实表和与其相关的审计维的例子：Shipments FactOrdef_da!e (FK) Ship dale (FK) Ddivery-date (FK) Shipjrom (FK) Ship Jo (FK) Product (FK) Promotion (FK) Terms (FK)IStatus (FK)IAudtl_key (FK) 1 Ordfr

16、f.num (DD) Ship num (DO) Lmenum (DD) number units gross. dollars disarnntdollars tecmsdoUdfs revenMe_(tollars retufft_dolfars1 record for each shipment line itemAudit Dimensionvalidation outmbouRds screens kiled record modified extrad time stamp clean time stamp 8dorm time stamp EU master version at

17、locatKra version curreficy version error event group (FK)1 record for each distinct audit condition图 审计维样例上图中 是一个典型的事实表，包含一大串的外键用来与维表关联， 还有三个用标示的退化维和个数字的域。这是数据仓库维模型设计中是一 个典型的结构。审计维包含事实表创建过程的元数据描述。数据质量系统的设计人员可以选 择在错误发生时，保存获得或者多或者少的元数据记录。用上面的例子说明审计 维表的产生产生过程。假如 事实表每天以批操作的方式处理一次。今天运 行的非常好，没有任何的错误纪录或者标记

18、。在这种情况下，只需要在审计表中 生 成一条审计纪录。这样，所有的错误信息对每一条事实记录将是相同的，它的作 用仅是表明今天的工作一切正常。如果上面的假设不存在，运行进程或者数据往往发生问题，例如，折扣数据 有问题，触发了一个错误。就需要在审计维表中用一些信息来记录发生的问题，需要考虑如何对错误条件和版本号选择恰当的值，将错误问题的 主外键关系进行恰当的关联。更多的关于这方面的详细信息请参阅。在完成最终的审计报告时，看看下面的审计报表，会发现一些可爱的地方。 如下图：ProductAxonShip FromOut ot Bounds IndicatorQty ShippedReve 械East

19、Abnormal14$2 350EastOK14241232.650WestAbnormal675$144,000WestOK15741336.000Instrumented Report (add Out of Bounds hdicatoc to SELECDProductShip FromShippedRevenueAxonEast1438S235.OOOAxonWe$r2219USO.OOO图利用审计维产生的报表图中上测的那个报告看似是个正常的报表但是下面的报表，可以清晰的揭 示报告中存在的异常。在有审计维的体系结构中，通过一个简单的命令，这些质 量审计报表就可以快速地实现。应用质量标

20、准借鉴创造业成功的质量管理实践，这些经验在数据仓库的领域也是非常实用 的。在创造商的世界里，质量实践已经在匡助他们取得了具体、明显的质量进步，甚至将缺陷率降低到百万分之 到 的水平。而错误事件主题模型是 一个非常好的基础，可以用来才采用标准来指导数据仓库领域的质量的实践。在错误事实主题中记录的所有的错误事件使得我们有机会通过运用特定的 机制对质量问题进行监控、评估，用于未来的改善。本文中描述的数据质量框架，提供了一种可以以较小的代价，增量的添加到 已有的数据仓库和数据集成环境中。一旦错误事件主题模型成功地建立之后，我们可以根据实际的环境确定质量实施进度。需要完成的就是后面具体的两个工作：记录每一次发生的问题决定对特定问题的特定的处理方式。错误的实现并不拘泥于特定的技术，可以嵌入自己的代码中，也可以借助于 特定的专业化的工具。固然，数据质量管理过程是一个没有终点的过程，也没有统一架构原则。这 里提供的是一种针对数据仓库项目可以简单实现的、可扩展的、一种相对照较完 善的捕捉数据质量事件，同时对其进行量度和控制的方法。