1 ETL的基本内容

    ET L(E xt raction,Tr ansformation和Loading)即数据的抽取、转换与加载。ETL是从各种原始的业务系统(异构多源)中提取数据，按照预先设计好的规则将抽取到的数据进行转换，最后将转换完的数据按计划增量或全部导人到目标数据库或数据仓库中。数据仓库系统建设中，ETL从不同异构数据源流向统一的目标数据.

    在数 据 的 抽取阶段，需要确定所有内部数据源。对所有计算机平台和数据抽取的所有源文件进行详细说明。如果还有外部数据源，要决定内部数据结构和外部数据结构的兼容性，而且要指出数据抽取的方法.

    数据 转 换 是将源数据变为目标数据的关键环节。在数据的转换阶段，包括数据格式转换、数据类型转换、数据汇总计算、数据拼接等等。

    由于源数据都有一定的缺点，所以，在源数据进数据仓库数据库之前，必须被加工处理，其中包括数据转换、数据清洗、数据合并等内容。

    数据的加载是根据用户定义的加载规则将数据缓冲区的数据直接送到数据仓库中对应的表中。

    2 统一的元数据和合理的设计业务模型

    ET L按 照 统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据仓库转化的过程，是事实数据仓库的重要步骤。

    2.1 统一的元数据

    设计 一 个 描述能力强、内容完善的元数据，是有效管理数据仓库的具有决定意义的前提，因此元数据的设计在整个数据仓库设计中占有重要的地位，是数据仓库设计的一个重要组成部分.

    目前 在 业 务应用系统的异构性与分布性越来越普遍的情况下，统一的元数据就显得越发重要了。随着企业的信息系统不断增加而形成的一个个“信息孤岛”是很多企业目前应用的现状。统一、合理的元数据则能有效的描绘出很好的关联性。

    元数据对于ETL过程产生影响的集中表现为:1)定义数据源的位置及数据源的属性。2)定义从源数据到目标数据的对应规则。3)确定相关的业务逻辑。4)在数据实际加载前的其他必要的准备工作。

    在数据仓库中元数据贯穿整个数据仓库项目的始终，ETL的所有过程都必须最大化的参照元数据。

    2.2 合理的设计业务模型

    在数据仓库的设计过程中，合理的设计业务模型对ETL是至关重要的，数据仓库是企业唯一、真实、可靠的综合数据平台。数据仓库的设计建模一般依照三范式、星型模型、雪花模型。数据仓库的模型设计通常都采用星型模型的设计方法。

    无论采用哪种设计思想，都应最大化的涵盖关键业务数据，把业务系统中杂乱无序的数据结构统一成为合理的、关联的、分析型的新结构，而ETL则依照模型的定义去提取数据源，进行转换、清洗，并最终加载到目标数据仓库中。业务模型的重要之处在于对数据做标准化定义，实现统一的编码、统一的分类和组织。

    3 高质量的数据是数据仓库成功的关健

    要想使数据仓库成功的建立，高质量的数据往往是关键的因素。经验告诉我们，纵然整个数据仓库的业务模型构架非常理想，但是数据的质量往往是致命的。一个数据仓库能否成功建立，非常依赖于数据的质量。

    影响数据质量问题的因素很多，在源数据处造成数据质量问题的因素有以下几点:(1) 数 据 格式错误。例如缺失数据、数据值超出范

    围或是数据格式非法等。要知道对于同样处理大数据量的数据源系统，他们通常会舍弃一些数据库自身的检查机制，例如字段约束等。尽可能将数据检查在人库前保证质量，但是这一点是很难确保的。这类情况诸如身份证号码、手机号、非日期类型的日期字段等。

    (2) 数 据 一致性。同样，数据源系统为了性能的考虑，会在一定程度上舍弃外键约束，这通常会导致数据不一致。例如在帐务表中会出现一个用户表中没有的用户ID，再例如有些代码在代码表中找不到等。

    (3)业务逻辑的合理性。通常，数据源系统的设计并不是非常严谨，例如让用户开户日期晚于用户销户日期都是有可能发生的，一个用户表中存在多个用户ID也是有可能发生的。对这种情况。尤其当客户的业务系统本身对业务逻辑联系就更加难以保证。而 在E T L过程中对数据的准确性产生重大的影响的因素有:

    (1) 规 则 描述错误。设计人员对数据源系统理解的不充分，导致规则理解错误，这是一方面。另一方面，是规则的描述，如何无二义性地描述规则也是要探求的一个课题。规则是依附于目标字段的，但是规则总不能总是用文字描述，必须有严格的数学表达方式。

    (3) 人 为 处理错误。在整体ETL流程没有完成之前，为了图省事，通常会手工运行ETL过程，这其中一个重大的问题就是你不会按照正常流程去运行了，而是按照自己的理解去运行，发生的错误可能是误删了数据、重复装载数据等。对于 E TL 数据质量问题，这是无法根治的，但必须有保障手段。从以往的经验看，没有保障手段给实施人员带来麻烦重重。这个保障手段就是数据验证机制，当然，它的目的是能够在ETL过程中监控数据质量，产生报警。这个模块要将实施人员当作是最终用户，可以说他们是数据验证机制的直接收益者。在质 量 度量方法的前提下，就可以建立一个数据验证框架，下面提出几点功能上的建议:

    (1) 提 供 前端。将开发实施人员当作用户，同样也要为之提供友好的用户界面。例如用OLAP的方式提供界面，不光是加上测试统计出来的指标结果，并且配合度量方法的计算。例如误差率，对于误差率大于0的指标，就要好好查一下原因了。

    (2) 提 供框 架。数据质量的验证不是一次性工作，而是每次ETL过程中都必须做的。因此，必须有一个框架，自动化验证过程，并提供扩展手段，让实施人员能够增加验证范围。有了这样一个框架，就能起到规范化操作的作用。这样，实施人员可以在每次装载，甚至在流程过程中就可以观察数据的误差率。特别是，如果数据仓库的模型能够统一起来，甚至数据验证脚本都可以确定下来，剩下的就是规范流程了。