原文地址：http://intelligent-enterprise.informationweek.com/showArticle.jhtml?articleID=220600174&pgno=1
设计一个数据仓库ETL架构中有些关键因素是我们应该必须关注？它将决定整个数据仓库ETL架构的成本、复杂性、甚至最后数据仓库的成败。本文阐述了六个关键因素。
是否应该使用集成的ETL工具？
在哪个阶段整合数据，如何做数据整合？
选择哪种变化数据捕获机制？
是否需要设置Staging Area
哪个阶段应该进行数据质量控制？
数据的加载频率？
是否应该使用集成的ETL工具？
在ETL系统架构中首先需要考虑的一个基本因素是应该使用手工写ETL代码方式还是采用集成的ETL工具。它不简单是技术和license的问题。架构应 该从更加长远的角度考虑，它将会影响我们整个的ETL环境、设计方法、元数据管理策略、实施的周期等等。
目前，基于ETL系统的规模和管理角度考虑，大部分ETL架构应该考虑使用集成的ETL工具，集成的工具采用图形化、拖 拽组件的方式进行ETL开发。然 而，一些老的开发人员更愿意使用直接写存储过程或是其他代码的形式实现ETL功能，它们更熟悉编程语言，认为这种方式更好。
ETL工具并不会从一开始就带来显著的好处，它的优点会在数据仓库不断的迭代实施中逐渐显现。使用ETL工具将会在可维护性、文档化、元数据方面获益不少。
我的观点：在以前工作实施的项目中使用过两个ETL工具－DataStage和Sagent。ETL 工具主要有以下几方面的优势：在性能方面主要表现在并行、流水线技术、灵活的分区技术；较好的元数据管理，现在的ETL工具大部分基于元数据开发，所有 MAPPING和ETL的血缘关系自动生成，自动维护，多数据源支持：可以支持不同类型的源系统和目标系统的抽取和加载。但是它也有其不足之处，就是受组 件功能所现，不利于处理较为复杂的业务逻辑，数据仓库系统中的业务逻辑往往较为复杂，程序语言这时就体现出他的先天优势-灵活性。在国内往往是两者结合起 来在数据仓库中应用比较好，在ETL的抽取、和数据整合阶段，涉及业务逻辑较为简单，选择使用ETL工具；而在偏分析应用的数据处理ETL层使用编写 ETL代码方式更为合适。
在哪个阶段整合数据，如何做数据整合？
数据整合对于IT来说是个大的话题，它的终极目标是所有系统都无缝地整合在一起。企业有一个全局的、统一的视角分析数 据。在许多时候，本应该在事务交易系 统中就应该整合的数据，被强推在数据仓库中处理。整合的最大关键问题，是我们需要知道哪些应该整合在一起，整合的程度。整合的粒度必须要符合实际的业务规 则要求，在实际中，往往不同部门确实对于同一个数据有不同的统计业务规则需求，我们是不能进行整合的。按照维度建模的思想，整合的目标是一致的维度和一致 的事实。一致的维度意味着整合整合后，不同的部门，系统的人员从分析数据的角度、粒度是一样的；一致的事实意味着指标数据算法的统一。
我的观点：我们在进行数据仓库数据整合的过程中，可以基于从两方面进行整合：逻辑上的整合和物理上的整合。我们在逻辑上 可以从企业的全局视角，而不以非常 详细的业务系统流程为对象进行实体抽象，抓住不同系统间的本质，进行一定的逻辑抽象，而做到逻辑上的整合。在物理实现上，根据具体业务规则，能整合的源系 统进行整合处理，不能整合的可以进行个性化物理实现。
选择哪种变化数据捕获机制？
数据仓库系统在初始加载后，不管从效率、时间窗口考虑，ETL系统都不可能处理全量数据。增量数据如何捕获就是一个ETL系统重要的能力。增量数据捕获听起来简单，但是它却是一个非常复杂的事情。必须根据源系统的状况，数据量的情况采用不同的策略，
目前常见的策略有：
时间戳的的方式：源系统必须记录了表中记录的最新更新的时间，根据更新时间进行抽取。
日志解析：解析数据库系统的日志文件，获取当天在数据库上发生的操作，而捕获变化数据。
文本比较：前后两天的数据进行全文本比较，其中根据业务逻辑的需要可以采用部分字段比较和HASH比较的方式。
源系统记录方式：在源系统中建立触发器，或者应用系统直接记录变化数据的情况。这种情况对源系统依赖极大，简单，但是，很难实施 。
是否需要设置Staging Area
目前许多ETL工具支持不落地的流水线数据处理，数据直接处理完成进入最后的目标表。从性能上看，它确实是一个不错的选择。但是它有可能不是一种最好的处理策略，以下几种情况，数据登台区还是有必要的。
一些CDC(change data capture)工具需要进行两份不同时间数据的比较。
一些组织选择使用数据登台区进行数据归档。
数据登台区可以做到一次抽取，后面的ETL过程多次重运行，重运行不依赖于源系统的开放程度。
长时间的ETL处理过程，超过源系统开放的时间窗口，为了对源系统影响小，可以先抽取，而不做数据转换。
Staging Area的可选择的处理方式也有多种，在源系统时间窗口允许的情况下，可以选择并行登台，数据Staging和转换并行进行。可兼顾效率和上面1，2，3的好处。
哪个阶段应该进行数据质量控制？
数据质量是在数据仓库中非常关注的一个问题，他影响数据的可信度，甚至整个数据仓库的可信度。数据质量问题不仅仅是数据 仓库团队的问题，是整个企业IT系统 的问题，但是往往这种问题全部推给了数据仓库处理。我们又很难抉择在哪个阶段进行数据质量控制，如何进行控制？进行脏数据处理的策略主要有：
停止ETL过程，等待人工介入处理。
把脏数据reject到另外一个地方，再进行处理。
将脏数据打上标签，建立一个错误数据维度并按业务逻辑继续处理。
第三中策略是目前为止较好的一种策略。他既不全面影响ETL过程调用，又可以根据业务逻辑的实际情况，在后面根据错误数据的不同情况，分别处理，不影响业务数据的正确展现。
数据的加载频率？
数据的加载频率 是指与源系统相比，ETL系统延迟多久加载数据。这个因素应该结合成本、业务需求考虑。数据加载的频率对ETL架构的成本和复杂性影响很大。采用何种策略 是和业务需求相关的，有些业务应该要求能实时的分析数据，而有很多应该，并没有这样的要求。目前主要有三种加载策略：
实时加载
每天多次加载
每日一次加载
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wsbupt/archive/2009/12/30/5109393.aspx
