ETL子系统.doc

ETL子系统 第9章抽取、转换和装载介绍 在建立DW/BI环境的过程中，后台的抽取、转换和装载(ETL)系统常常要花费70%的时间和工作量。创建一个ETL系统通常是非常富有挑战性的，因为有那么多的外部约束给ETL设计带来压力：业务需求、源数据系统、预算、处理窗和现有职员的技能状况。要理解为什么ETL系统如此复杂并且资源如此密集是很困难的。每个人都需要知道三个字母：将数据从它在源系统中的位置取出来(E)，对数据进行一些转换(T)，并且将数据装载(L)到最终的表集合中供用户查询。 当谈到设计和建立ETL系统的最优方法时，很多设计人员都会说：这视情况而定。这取决于源系统、数据的限制条件、可用的脚本语言和ETL工具、职员的技能，而且还取决于BI工具。 视情况而定这句话是很危险的，因为这常常会成为使用某种未系统化的方法开发ETL系统的借口，这样做最坏情况下会造成表、模块、过程、脚本、触发器、警报和作业调度都像意大利面条那样搅合起来乱成一团。这种具有创造性的设计方法是不能容许的。随着成千上万个数据仓库的成功，大量经验的积累，已经出现了一系列ETL最优方法。因此，没有理由去使用某种未系统化的方法。 对这些最优方法进行认真的考虑之后，我们发现几乎所有的维度数据仓库后台都需要34个子系统，难怪ETL系统会消耗生命周期中的大部分资源！但是这也带来了一些好消息，如果学习了这34个子系统，在利用自己的经验创建每个子系统的时候几乎很快就会辨识出所有的子系统。 ETL系统是DW/BI项目的基础，它可以使数据仓库项目成功，也可以使数据仓库项目中断。本章阐述了ETL系统架构中的主要组成部件，为第10章奠定了基础。在第10章将会概述基于本章所确立的架构基础来建立ETL系统的过程。 参考资料： 本章讲述的ETL架构这一主题在The Data Warehouse ETL Toolkit (Wiley Publishing, 2004)一书中讲得更为详细。我们强烈建议ETL团队在设计和开发ETL系统的时候将这本书作为参考。 ETL团队应当通读本章的内容。数据设计师、数据模型师和DBA也应当对本章的内容比较熟悉。项目经理应当将本章作为教育本机构其他成员的基础，告诉他们ETL环境的复杂性。项目团队的其他成员可以简单浏览本章的内容，熟悉基本步骤，但是不需要对相关概念所涉及的知识有更深入的了解。 9.1? 归拢需求?????????????????????????????????????? 从最困难的挑战之一出发确立ETL系统的架构：归拢需求。这就意味着要收集并且理解所有已知的需求、实际情况和影响ETL系统的约束。需求清单会有很厚一摞，但是一定要在开始开发ETL系统之前就将它们摆到案头。 ETL系统需求主要是一些您必须用到的约束，即必须使系统符合这些约束。在这些需求框架中，也有机会进行自己的选择、练习自己的判断和充分利用自己的创造性，但是这些需求规定了ETL系统必须提交的核心要素。下面的10个选项描述了影响ETL系统设计和开发的几个主要方面的需求。 9.1.1? 业务需求 从ETL设计者的角度来看，业务需求就是DW/BI系统用户的信息需求。在这里使用业务需求这个术语来表示业务用户在进行业务决策的过程中所需的信息内容则稍稍有些勉强。因为业务需求直接驱动了对数据源的选择，以及随后在ETL系统中对数据的转换操作，所以ETL团队必须了解并且仔细核查业务需求。 很多情况下，在维度建模的过程中进行的初始业务用户访谈(见第3章)和数据源调查都无法完全揭示出数据的复杂度和限制。ETL团队有时会有重大的发现，会对业务需求能否按照最初所希望的那样得以解决产生影响。当然，他们有时也会在数据源中意外发现一些宝贝，能够帮助用户提高决策制定能力。即使在ETL系统的技术后台开发中，也必须保持ETL团队、数据设计师、模型师、业务分析员和业务用户之间的对话。从更大的意义上来看，业务需求和数据源的内容都是移动目标，都需要不断地进行复查和讨论。 9.1.2? 合规性 法规和报表需求会迫使很多机构严格制定他们的报表，并且提供证明来说明报表中的数据是正确和完整的，并且没有经过任何篡改。当然，常规业务(如医药和电信业务)中使用的数据仓库，多年来都是按照规定的报表需求进行的。但是，就财务报表的整体趋向来看，它对每个人都越来越严格。 有些合规性问题会超出DW/BI系统的范围，但是大多数合规性问题都会在系统所要考虑的范围之内。一般数据仓库中需要谨慎处理的需求包括： ●?保存数据源和随后数据登台的存档副本。 ●?为改变任何数据结果的完整的事务处理流程提供证明。 ●?完整记录用于分配、调整和推导的算法。 ●?随着时间推移为数据副本的必威体育官网网址性提供证明，包括在线和离线两种。 9.1.3? 数据质量 有三股极有影响的力量聚焦到数据质