2011-03-28 11:34:25 来源：万方数据
1、引言
数据仓库是一个面向主题的、集成的、不可更新的且随时间不断变化的数据集合，是支持管理人员决策的数据依据。它的目的是建立结构化的数据存储空间，将不同数据源的数据分离出来，形成统一、有效的数据集，并最终加工、整合成决策支持所需要的数据。
ETL 是英文Extract、Transform、load 的缩写，是指从各种异构应用系统中抽取数据，并对抽取到的数据进行加工转换处理，最后加载到数据仓库DW(Data Warehouse)中的过程，它是保证数据仓库数据正确性和有效性重要过程，也是决策支持项目实施成败的关键因素。抽取是指把数据从源系统抽取的过程；数据转换是指根据需求将数据按照特定规则进行清洗、转换、加工并统一数据粒度的过程；加载是将加工好的数据装入目标数据库的过程。根据大量的实践经验得出ETL规则设计和实施约占整个项目工作量的60%-80%。
目前的ETL 实现有两种方式，一是在决策支持项目的实施过程中，针对数据源系统再另外定制一套专门的ETL系统，这种方式的好处在于ETL 工具的针对性对抽取效率和数据质量进行保证，缺点在于决策支持系统本身就是工程量巨大的项目，在此基础上再另外投入大量的人力、时间开发专门的ETL系统增加了项目实施的代价。二是借助专业ETL 厂商提供的现成的ETL 工具。目前较为成熟的ETL工具有Ascential sofware 公司的Datastage 和Informatica 公司的产品Informatica，这些产品一般对自己厂商的相关产品可以进行良好的支持且能发挥最大效率，缺点在于其结构相对封闭，对其他厂商产品的支持也很有限。所以在进行项目的实施过程中，要结合实际情况选择有效的ETL 实现方式。
本文将以进出口贸易公司的决策支持项目实施为例，在借助ETL工具Informatica 的情况下，结合数据仓库存储设计、数据库多重粒度划分，提出一种面向数据仓库的ETL 多层实现策略。
2、ETL多层实现策略
2.1 数据仓库存贮区域设计
良好的数据存储区域设计可以简化ETL 过程中的数据转换，提高抽取效率。通常情况下，传统的ETL 架构设计是将数据的抽取、清洗、转换及加载放在同一过程完成，但是对于大型的进出口贸易集团公司来说，其业务种类繁多，完成信息化建设的过程中又都针对不同业务，在不同时期分别建立了专门的业务系统，这导致数据来源的复杂性。而传统的ETL 架构将处理复杂数据放在一个过程中完成无形的增加了ETL 转换逻辑难度，增加了数据源系统的负担。这种复杂性首先体现在数据源系统数据库类型的不同。大型进出口贸易公司的数据来源多种多样，数据分布于大量异构系统上，其业务系统数据库管理系统DBMS 的类型不尽相同，无法采用单一的抽取、加载方式。其次，来自不同异构系统的数据对于同一个指标字段在数据类型、字段长度的存储上各不相同。例如院分销系统是贸易公司必不可少的业务系统之一，在分销系统中"销售数量"为numeric(22,6)，而在物流系统中字段"出库数量"为numeric(18,3)。又比如，同种商品的"商品编号"字段在不同系统存储有不同的编码定义。诸如此类的"不一致"问题为后继的数据加工带来诸多不便。
在规范目标数据源建模的同时，更需要通过ETL进行数据转换(Transform)的操作，将数据进行标准化。另外，从不同数据源抽取的数据，在粗细粒度上也会存在差异。为汇总计算带来不便。
基于以上异构系统数据源存在的复杂数据问题，可以在ETL 过程中采用以下数据存储区域设计方案，此方案对大型的进出口贸易公司存在的数据来源多样、ETL 转换逻辑复杂等问题起到了良好的作用。
图1 ETL 过程中数据存储区域设计
该数据存储区域设计包括数据缓冲层(stage 层)、明细数据层(ODS 层)、整合层及展示层。在各个层次之间分别有针对性的实现ETL过程的中数据抽取、转换、加载操作。[page]
1) 数据源到缓冲层(stage 层)。针对不同数据源的数据库服务器类型，采用多种抽取方式相结合，将各个业务系统的元数据加载到此存储区域。期间不对数据进行任何转换处理和加工，其目的在于在目标数据库中最大化的呈现源系统数据的面貌，使得后继错误排查及纠正工作不会对源业务系统数据库造成影响。此存储区域将保留业务系统所有全量及增量数据。在增量抽取到缓冲层时增加抽取时间字段，可以标示出每日增量情况。
2)缓冲层到明细数据层(ODS 层)。ODS 层存储"标准化"后的源系统数据。所谓"标准化"是指将各个业务系统例如商品代码、客户代码等诸如此类带有源业务系统个性的数据进行统一的规范化编码。例如：在分销系统中商品" 铸钢" 的商品编码为800002637，在结算系统中同样是商品"铸钢"定义商品编码为900002938，那么缓冲层到明细系统间就要通过ETL 关联规范化的码表将同种商品的编码进行统一，目的是为决策表报数据汇总及展现提供便利。
3)ODS 层到整合层。从ODS 到整合层是实现数据加工最复杂的环节，所有标准化后的源系统数据经过整合、加工、计算最终按照决策所需分析主题存放在整合层，整合层存储结构以星型模型为主，形成所谓的数据集市。另外，基于决策支持系统前台用户对数据粒度要求的不同，在整合层储区域建立多重数据粒度的划分。所以，在ETL 过程中在满足决策分析员和公司高层领导等不同类别用户查询需求的同时，减少了数据仓库数据量，提高查询效率。下图为利用ETL 工具informatica 实现ODS 层到整合层实现部分数据加工的ETLmapping 设计样例，最左侧的为ODS 层表，对于整合层来说为数据源，最右侧为目标表，中间的控件实现了数据的过滤、汇总等加工过程。
图2 ODS 层到整合层mapping 设计样例
整合层到展示层。展示层的设计主要是考虑前台报表展现效率，其模型以分析需求为驱动进行设计，贴合报表的展示模型。对数据仓库进行良好的结构化设计，是优化ETL 方案的基础，由于面临众多异构数据源，对数据的处理过程极其复杂，有了结构化数据存储在后继的数据加工过程中，可以分阶段的对数据进行验证，一旦发现错误也可以快速定位，方便错误排查。
ETL 处理过程是贯穿决策支持系统始终的，并对系统起到决定性作用。图2 是针对贸易企业的决策支持系统设计出整体架构，其中灰色区域部分均为ETL 处理过程，从以下的决策支持系统整体架构中可以看出ETL 过程在整个架构中占据重要位置。
图3 决策支持系统整体架构[page]
3、ETL架构下关键环节问题的处理
图4 为ETL 的架构设计，可以看出，在ETL 架构中除了对数据的加工处理外，流程调度及调度管理也是重要组成部分。以下将对ETL 过程中关键环节问题进行分析
3.1 加载方式讨论
ETL 过程中有两种加载方式，即全量更新和增量加载。全量更新的方式要根据抽取阶段及数据源数据量多少而定。数据源数据量庞大时必须采用增量方式，但是业务系统数据库模型和业务数据产生机制千差万别，所以增量加载又分为镜像更新和直接追加。通常情况下如果源系统存在时间戳或明显的业务时间，则可以根据时间戳采用直接追加的方式，如果数据源没有明细的时间标示或业务系统的增量数据本身就存在重复问题，无法识别真正的增量，则可以按照主键对数据进行全表比对方式加载增量数据。
图4 ETL 架构设计
3.2 标准化例外数据处理
例外数据的处理是BI 项目中不可少的环节，产生的原因大多数是因为业务操作输入不规范造成。例外数据会严重影响到有效数据的汇总计算，那么在处理时，就必须先将例外数据进行标准化转换，对于无法转换的则需要过滤掉。在设计中此项操作在缓冲层到明细数据层之间进行。转换后的数据方可正常加入到上一层，否则写入到专门的例s 外数据表中，由数据管控人员返回给业务部门进行督导更正。
3.3 调度策略
在ETL 的实现过程中，调度策略往往是容易被人忽略的环节，而每条workflow 的成功执行却是保证整个ETL 过程的关键。一般情况下规定为，将每个ETL过程按照依赖关系、数据流向进行分类打包。执行调度时一旦某个ETL任务发生错误停止运行，则要求错误未处理前不再运行下一周期该工作流曰后续所有依赖于该任务的其它工作流停止运行曰并行的其它任务仍照常运行，不受影响。
4、结束语
大量的决策支持项目证实，一种良好、有效的ETL 实现方法是项目成功的关键。ETL 的多层实现策略可以有效的对数据进行针对性的加工，提高ETL 效率，在发现数据错误时可以根据出错的类型准确定位。ETL 过程的实现不仅要考虑到数据本身的特点，进行加工，同时也要结合数据源特性和目标数据仓库存储设计，只有将这几者相结合，才能建立一套完善、高效、有针对性的ETL实现过程。
免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。
抢沙发
