数据仓库ETl工具箱3

第二部分数据流抽取一旦开始了数据仓库项目，你就会很快意识到，集成整个企业中所有不同的系统来得到数据仓库可用的状态是一个真正的挑战。没有数据，数据仓库就是无用的。集成的第一步就是成功地从主要的源系统抽取数据。流程检查规划与设计：需求/现状-架构-实现-测试/发布数据流：抽取-清洗-规格化-提交本书的其它章节主要集中在转换和加载数据到数据仓库，本章的重点是为项目建立访问需要的源系统的接口。每一数据源都有不同的特点需要分别管理，以便为ETL过程有效的抽取数据。随着企业的发展，需要建设或者继承多个不同的计算机系统来帮助公司运作他们的业务：销售系统、库存管理、生产控制、总帐系统――这个列表还在不断增长。更糟糕的是，不但这些系统是分离的且产生于不同的时间，而且他们经常是在逻辑上和物理上不兼容。ETL过程需要有效集成不同的系统：„数据管理系统„操作系统„硬件„通信协议在开始创建抽取系统之前，需要一份逻辑数据映射，它描述了那些提交到前台的表中原始源字段和昀终目标字段之间的关系。该文档将贯穿ETL系统的始终。我们将在本章第一部分介绍如何创建逻辑数据映射。本章第2部分列举了可能经常遇到的各种源系统。我们将深入研究每一种源系统，以便选择正确的处理方法。本章结束部分介绍了变化数据和删除数据的捕获这一主题，15年前我们还认为数据仓库是永恒不变的：它是一个一次性写成的数据大库。随着这些年的丰富经验的积累，我们现在知道数据仓库经常需要修改、纠错和更新。本章的变化数据捕获抽取技术只是这一复杂问题解决的第一步，在后续的提交和操作章节中，仍将继续这一变化数据捕获主题。第1部分：逻辑数据映射在物理实施之前如果没有仔细地规划结构将会是一场灾难。正如任何其它形式的建筑物一样，在敲击第一个钉子前必须拥有一个蓝图。在开始开发一个单一的ETL处理前，确保你拥有合适的文档，以便该处理与已有的ETL策略、过程和标准在逻辑上和物理上保持一致。流程检查规划与设计：需求/现状-架构-实现-测试/发布数据流：抽取-清洗-规格化-提交逻辑数据映射描述了ETL系统中起点和终点之间的关系。物理之前设计逻辑直接跳到物理数据映射会浪费宝贵的时间，并将无法文档跟踪。这一节描述如何开发逻辑的ETL过程并使用它来制订出物理ETL执行流程。在开始任何物理ETL开发之前，确定以下的步骤已经完成：1.有一个规划。这个ETL过程必须用逻辑的和文档化的形式表示出来。逻辑数据映射由数据仓库架构师提供，并且它是为ETL团队创建物理ETL作业而制定的。该文档有时会作为数据流报告。逻辑数据映射是元数据的基础，随后将提交给测试员来保证数据质量，并且昀终将提交给昀终用户来详细描述在源系统和数据仓库之间到底做了些什么。2.确定候选的数据源。从昀高级别的业务对象出发，确定你认为将支持业务人员进行决策的可能的候选数据源。并且确定这些源中你认为对昀终用户的数据很重要的特定的数据元素，这些数据元素将成为接下来的数据评估步骤的输入。3.使用数据评估工具分析源系统。源系统中的数据必须在数据质量，完整性和适合使用方面进行仔细检查。根据于你的组织结构，数据质量可能是或者不是由ETL小组负责，但是这个数据评估步骤必须由对昀终使用数据仓库的决策者的需求有一定了解的人来负责。每一个源系统的数据都必须进行分析。任何监测到的异常数据都必须用文档记录下来，对任何进入数据仓库的数据都必须按照适当的业务规则进行修正是昀好的选择。你必须要一直关注项目在这个阶段就停下来的可能性！如果数据不能支持业务目标，这个时候就要发现。在第四章中将更多的探讨数据评估。4.接收数据线和业务规则的遍历。一旦源数据完成数据评估步骤的质量保证并且理解了昀终的目标数据模型，数据仓库架构工程师和业务分析师必须和ETL架构工程师及开发者一起完成为抽取，转换和加载的数据仓库的主题域的整个数据线和业务规则，并且昀好他们理解这些规则。完全的理解这些数据线和业务规则是几乎不可能的，因为那样ETL小组必须遇到所有的数据实际问题，但这一步骤的目标是提交尽可能多的知识给ETL小组。数据评估步骤必须创建ETL特有的业务规则的两个子类：4a.在数据清洗步骤中需要进行改造的数据；4b.对分离的数据源的维度实体和可度量的数字事实强制一致性来获得标准的结构；5.充分理解数据仓库数据模型。ETL小组必须充分理解数据仓库的物理数据模型。这种理解包括维度模型的概念，仅仅理解基本的表到表之间的映射是不够的，开发小组必须对如何使维度，事实及其他维度模型中的特定表一起发挥作用来实施一个成功的ETL解决方案有好的理解。切记ETL系统的主要目标是用昀有效的方式将数据送给昀终用户工具。6.验证计算和公式的有效性。与昀终用户一起校验任何在数据链中任何指定的计算。这个规则来源于纽约市建筑行业的谚语“测两次，切一次”。正如你不想得到一座用错误尺寸的材料造成的摩天大楼，你同样不希望在数据仓库中部署不正确的度量指标。在ETL过程中花时间以错误的法法编码之前，确保你的计算公式都是正确的将是非常有用的。逻辑数据映射内部在深入你将遇到的不同的数据源细节之前，我们需要研究逻辑数据映射文档的实际设计。该文档包括整个企业针对数据仓库源系统的数据定义，目标数据仓库数据模型，以及从原有格式到昀终目的转换所需要的完全数据操作。逻辑数据映射的组成逻辑数据映射（见图3.1）通常用一个表或者电子表格格式来表示，它包括以下特定的组成部分：„目标表名称：数据仓库中出现的物理表名称；目标列名称：数据仓库表中的列名称；„表类型：表示这个表是事实表，维表或者子维表（支节）„SCD（缓慢变化维）类型：对维表，这个部分表示是类型1，类型2或者类型3的缓慢变化维。这个指标对维表中的不同的列可以是不同的。„比如在客户维中，名字可能属于类型2（保留历史信息），而姓可能属于类型1（覆盖）。这些SCD类型将在第五章展开详细探讨。„源数据库：源数据所在的数据库实例的名称。这里通常是指连接数据库所需的连接字符串。如果出现在文件系统中，它也可以是一个文件的名称。这时，还需要包含这个文件的路径。„源表名称：源数据所在的源表的名称。很多时候需要多个表。这时，只需将生成目标数据仓库相关表的所有表简单列出即可。„源列名称：生成目标所需的相关列。简单的列出装载目标列需要的所有列。源列之间的关联在转换部分记录。„转换：源数据与期望的目标格式对应所需的详细操作。这个部分通常用SQL或者伪代码来编写。逻辑数据映射中的列有时是组合的。比如，源数据库，表名称和列名称可能被组合在一个源列中。这个组合列的信息可能用原点来分隔信息，如ORDERS.STATUS.STATUS_CODE。如果不考虑格式，这个逻辑数据映射文档的内容已经把进行有效的规划ETL过程的所有的关键的信息都提供了。逻辑数据映射中的某些部分看起来很简单并且很直接。然而，当仔细研究的时候，该文档就会揭示许多ETL小组可能忽略的隐藏的需求。这个文档的主要的目标是为ETL开发者提供一个清晰的蓝图，它精确的说明可以从ETL过程获得什么。这个表必须清晰地描述在转换过程中包含的动作流程，不能有任何疑问的地方。看一下图3.1。图表3.1逻辑数据映射仔细观察这个图，你可能会注意到一些注意事项，如果它们没有被关注，可能会引起许多故障诊断和调试的工作甚至昀终延误这个项目。比如，你可能注意到STATE在源和目标中的数据类型已经从255字符转换为75字符。尽管数据分析文档可以支持数据范围的减小，但将来创建任何大于75字符的值时，就有可能丢失这些数据。而且，一些ETL工具实际上可能终止或者使整个包含这些数据溢出错误的过程失败。请注意STATE的转换说明没有明确定义这一数据转换—转换是隐含的。根据定义，不应该有一个明确定义的账户是隐含转换的。隐含转换在破坏你的处理流程方面是常见和臭名昭著的。为了避免不幸的发生，ETL小组必须假定对这些类型的隐含数据转换都负责任地进行了明确的处理。ETL工具包通常持续跟踪这些隐含的数据转换并提供报告来标识任何的这种类型的转换。表类型给了我们数据加载过程执行的次序—先是维表，然后是事实表。与表类型一起，加载维表过程SCD类型显得至关重要。正如我们在这一章的前面所解释的，表结构的本身无法揭示缓慢变化维的策略是什么。错误地解释缓慢变化维策略将引起数周开发时间的浪费。在开始开发加载过程之前，需要清楚地了解哪些列需要保留历史信息以及如何获取历史信息所需的策略。这个列的值随着时间的推移可能发生改变。通常在单元测试的时候，当你第一次挑选用户来观察数据仓库中的数据时，他们看到了不想得到的结果。即使数据建模者极其努力的尝试，SCD的概念还是很难向用户表达，并且一旦他们开始进行维度的加载时，他们总是想要与你的SCD策略背道而驰。这种需求是很常见的，这需要数据仓库项目经理来处理并改变管理流程。映射中的转换是这个流程中的小阶段，这里是技术性好的开发者首先关注的。但你必须迫使自己不要只集中精力在编码上，在进入转换之前要仔细检查整个映射。这个转换可能包含了整个解决方案或者根本就什么都不是。昀常见的，转换可能用SQL来表示。SQL可能是也可能不是完整的语句。通常，它是那些不能在映射用其他元素表达的代码段，比如SQL中的WHERE子句。在其他时候，转换也可能是一种方法，没有特殊的SQL，只有普通的英语说明，比如从一个平面文件进行预加载，或者基于数据库之外的标准进行加载转换，或者拒绝已知的异常数据到一个拒绝文件中的指导性说明。如果转换是空的，这说明映射是直接从源到目标的，没有任何转换的需求。以上是逻辑数据映射的全部内容，在开始任何实际的编码开始之前和ETL开发者一起对文档做一个全面的走查。使用工具设计逻辑数据映射一些ETL和数据建模工具能直接抓取逻辑数据映射信息。人们很自然的想要在这些工具中直接表示数据映射。输入信息到工具中使得我们可以共享元数据，这是不错的选择。但在写信息的时候，并没有说明与逻辑数据映射相关的适当的数据元素的标准。在各种工具中可用的实际元素差别很大。正如数据仓库中的元数据标准是成熟的一样，对逻辑数据映射中的元素定义也应该建立一个标准。建立元数据标准将使得这些工具对这一目的变得更加一致和可用。你要调查你当前的工具包对存储逻辑数据映射来说是否可用并充分利用已有的任何功能。然而，如果你的工具没有实现所有你需要的元素，你将不得不把逻辑数据映射放在不同的地方，这使你的维护工作变成一件非常麻烦的事件。请密切关注各种产品在这方面所做的改进。创建逻辑数据映射数据仓库的成功主要来源于这样的情形，所有的数据放在一个逻辑位置，使用户可以执行交叉功能分析。在后台，ETL小组无缝的整合和转换分散的无组织的数据并使它看起来好像从一开始就在一起的一样。数据仓库成功的主要标准之一是它存储的数据是干净的和一致的。统一的数据存储需要对每一个源系统有相当深入地了解。对数据源中的数据甚至源系统本身理解的重要性常常在ETL的项目规划阶段被忽略和低估。在源系统得到确认和分析之前完整的逻辑数据映射是不存在的。源系统分析通常分为两个主要阶段：„数据发现阶段；„异常检测阶段；数据发现阶段一旦理解了目标需要做成什么样子后，就要确认和检查数据源了。部分或者全部的源系统可能在数据建模期间发生很大变化，但并不需要过多地考虑这些。通常，只有主要的源系统在数据建模期间被确认出来。要知道数据建模工程师的主要目标是建立一个数据模型，这一点很重要。任何来自数据建模期间的逻辑数据映射都只是一个副产品----一个起点。况且，数据建模工程师花大部分的时间和昀终用户在一起，所以在逻辑数据映射中定义的源系统可能不是真的初始的或者优化的源—记录系统。这需要ETL小组更深入到数据的需求中，确定每一个需要加载到数据仓库中的源系统、表和属性。为每一元素确定适当的源或者记录系统是一个挑战，必须仔细评估。完整的分析可以减少在ETL过程中由于使用错误的源而导致的数周时间的工期延误。收集和文档化源系统源系统通常由各种文档组成，包括会谈纪录，报表，以及数据建模人员的逻辑数据映射。ETL小组通常需要更多的调研。和团队