ETL工具介绍
目录
1. 引言 (3)
1.1 编写目的 (3)
1.2 文档背景 (3)
1.3 预期读者 (3)
1.4 参考资料 (3)
2. ETL基本概念 (4)
2.1 ETL的定义 (4)
2.2 ETL的作用 (4)
2.3 ETL工具的功能 (5)
2.3.1 对平台的支持 (5)
2.3.2 对数据源的支持 (5)
2.3.3 数据转换功能 (6)
2.3.4 管理和调度功能 (6)
2.3.5 集成和开放性 (6)
2.3.6 对元数据的管理 (7)
3. 主流的ETL工具 (7)
3.1 一类是专业ETL厂商的产品 (7)
3.2 另一类是整体数据仓库方案供应商 (8)
3.3 还有一类是由开源提供的软件 (8)
4. 报表工具简介 (8)
5. 前端展现 (9)
6. 建行RIDE报表工具介绍 (9)
6.1 RIDE介绍 (9)
6.2 RIDE的应用 (10)
6.3 RIDE功能 (10)
1.引言
1.1编写目的
本文介绍ETL的基本感念和功能，以及ETL目前主流工具，并对BI/DW架构的最后一个环节报表展示，给予介绍。
1.2 文档背景
1.3 预期读者
对数据挖掘感兴趣的人员。
1.4 参考资料
1.5 修改记录
2.ETL基本概念
2.1 ETL的定义
ETL分别是“Extract”、“ Transform” 、“Load”三个单词的首字母缩写也就是“抽取”、“转换”、“装载”，但我们日常往往简称其为数据抽取。ETL是BI/DW（商务智能/数据仓库）的核心和灵魂，按照统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据仓库转化的过程，是实施数据仓库的重要步骤。ETL包含了三方面，首先是“抽取”：将数据从各种原始的业务系统中读取出来，这是所有工作的前提。其次“转换”：按照预先设计好的规则将抽取得数据进行转换，使本来异构的数据格式能统一起来。最后“装载”：将转换完的数据按计划增量或全部导入到数据仓库中。
2.2 ETL的作用
ETL所完成的工作主要包括三方面：
首先，在数据仓库和业务系统之间搭建起一座桥梁，确保新的业务数据源源不断地进入数据仓库；
其次，用户的分析和应用也能反映出最新的业务动态，虽然ETL在数据仓库架构的三部分中技术含量并不算高，但其涉及到大量的业务逻辑和异构环境，因此在一般的数据仓库项目中ETL部分往往也是牵扯精力最多的；
第三，如果从整体角度来看，ETL主要作用在于屏蔽了复杂的业务逻辑，从而为各种基于数据仓库的分析和应用提供了统一的数据接口，这也是构建数据仓库最重要的意义所在
整个BI/DW系统由三大部分组成：数据集成、数据仓库和数据集市、多维数据分析。通常，商务智能运作所依靠的信息系统是一个由传统系统、不兼容数据源、数据库与应用所共同构成的复杂数据集合，各个部分之间不能彼此交流。从这个层面看：目前运行的应用系统是用户花费了很大精力和财力构建的、不可替代的系统，特别是系统的数据。而新建的商务智能系统目的就是要通过数据分析来辅助用户决策，恰恰这些数据的来源、格式不一样，导致了系统实施、数据整合的难度。此时，非常希望有一个全面
的解决方案来解决用户的困境，解决数据一致性与集成化问题，使用户能够从已有传统环境与平台中采集数据，并利用一个单一解决方案对其进行高效的转换。这个解决方案就是ETL。
ETL是BI/DW的核心和灵魂，按照统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据仓库转化的过程，是实施数据仓库的重要步骤。如果说数据仓库的模型设计是一座大厦的设计蓝图，数据是砖瓦的话，那么ETL就是建设大厦的过程。在整个项目中最难部分是用户需求分析和模型设计，而ETL规则设计和实施则是工作量最大的，其工作量要占整个项目的60%-80%，这是国内外专家从众多实践中得到的普遍共识。
2.3 ETL工具的功能
ETL工具的功能可以概括为以下几方面：对平台的支持、对数据源的支持、数据转换功能、管理和调度功能、集成和开放性、对元数据的管理。下面对ETL工具的功能分别展开介绍。
2.3.1 对平台的支持
随着各种应用系统数据量的飞速增长和对业务可靠性的要求不断提高，数据抽取工具面对的要求往往是将几十上百个GB的数据在有限的几个小时内完成抽取转换和装载，这种挑战势必要求抽取工具对高性能的硬件和主机提供支持。因此，我们可以从数据抽取工具支持的平台的来判断其能否胜任你的环境，目前主流的平台包括SUN Solaris、HP-UX、IBM AIX、AS/400、OS/390、Sco Unix、Linux、Windows等。
2.3.2 对数据源的支持
对数据源支持的重要性不言而喻，因此这个指标必须仔细的考虑。首先你需要对项目中可能会遇到的各种数据源有清晰的认识，其次对各种工具提供的数据源接口类型也要有深入了解，比如，针对同一种数据库，使用通用的接口（如ODBC/JDBC）还是原厂商自己的专用接口，数据抽取效率会有很大差别，这直接关系到能不能在有限的时间内完成ETL任务。这里列出一些常见的数据源以供参考：DB2、 Informix、Oracle,
Sybase、SQLServer、SAS,、Text、Excel、SAP、Peoplesoft等。
2.3.3 数据转换功能
数据转换是ETL中最令人头疼的问题。由于业务系统的开发一般有一个较长的时间跨度，这就造成统一种数据在业务系统中可能会有多种完全不同的存储格式，甚至还有许多数据仓库分析中所要求的数据在业务系统中并不直接存在，而是需要根据某些公式对各部分数据进行计算才能得到。因此，这就要求ETL工具必须对抽取到的数据能进行灵活的计算、合并、拆分等转换操作。通常会遇到的转换要求有：字段映射；映射的自动匹配；字段的拆分；多字段的混合运算；跨异构数据库的关联；自定义函数；多数据类型支持；复杂条件过滤；支持脏读；数据的批量装载；时间类型的转换；对各种码表的支持；环境变量是否可以动态修改；去重复记录；抽取断点；记录间合并或计算；记录拆分；抽取的字段是否可以动态修改；行、列变换；排序；统计；度量衡等常用的转换函数；代理主键的生成；调试功能；抽取远程数据；增量抽取的处理方式；制造样品数据；在转换过程中是否支持数据比较的功能；数据预览；性能监控；数据清洗及标准化；按行，按列的分组聚合等。
2.3.4 管理和调度功能
由于对数据抽取的要求越来越高以及专业ETL工具的不断涌现，ETL过程早已不再是一个简单的小程序就能完成，目前主流的工具都采用像采用多线程、分布式、负载均衡、集中管理等高性能高可靠性与易管理和扩展的多层体系架构，因此这就要求ETL 的管理和调度上都具备相应的功能。一般这方面的一些基本功能包括：抽取过程的备份与恢复；升级；版本管理；开发和发布；支持统一以及自定义的管理平台；支持时间触发方式；支持事件触发方式；支持命令行执行方式；支持用户对计算机资源的管理和分配；负载均衡；文档的自动生成；调度过程中能否执行其他任务等。
2.3.5 集成和开放性
随着数据仓库技术在国内应用的不断深入，许多开发商希望不向用户提供ETL工具的原来操作界面而是将其一些主要功能模块嵌入到自己的系统或其他厂商的系统中，因为在大多数情况下一般项目只会用到ETL工具的少数几个功能，同时也没有必要给
用户提供那么复杂的操作环境这反倒使用户容易产生操作错误。这就要求ETL工具能提供很好的集成性和开放性。可以从以下几方面考虑：与OLAP集成；与前端工具集成；与建模工具集成；开放的API可将产品集成到统一界面；是否能调用各种外部应用，包括存储过程、各种流行语言开发的应用程序等；是否支持客户化定制的转换过程；
是否支持与统计分析工具的集成等。
2.3.6 对元数据的管理
元数据是关于数据的数据，其对于ETL来说尤其重要。ETL中大量的数据源定义、映射规则、转换规则、装载策略等都属于元数据范畴，如何妥善的存储这些信息不仅关系到ETL过程能否顺利完成而且影响到后期的使用和维护。任何业务逻辑的微小改变最终都落实为相应元数据的调整，初期没有一个完善的元数据管理功能后期作类似调整几乎是“不可完成的任务”。基于元数据的重要性，国际组织提出一些统一的元数据存储标准比较知名的如CWM等，这为不同厂商工具之间互操作提供了可能性，相信也是以后的发展趋势。针对ETL的元数据管理应包括：元数据存储的开放性；元数据存储的可移植性；提供多种方式访问元数据；元数据的版本控制；支持开放的元数据标准；支持XML进行元数据交换；支持分布式的元数据访问和管理；生成元数据报表；对于ETL过程的冲突分析；基于元数据的查询功能；元数据的广播和重用；对于ETL过程的流程分析等。
3.主流的ETL工具
目前市场上主流的ETL工具可以分几大类：
3.1 一类是专业ETL厂商的产品
这类产品一般都具备较完善的体系结构和久经考验的产品，产品的功能之复杂和详尽，往往能令初次接触的人膛目，但其高昂的价格也会使一般用户望而却步；专业ETL 厂商和产品包括Ascential公司的DataStageXE、Sagent公司的Solution和Informatica 公司的产品。
3.2 另一类是整体数据仓库方案供应商
他们在提供数据仓库存储、设计、展现工具的同时也提供相应的ETL工具，这类产品一般对自己厂商的相关产品有很好的支持并能发挥出其最大效率，但结构相对封闭，对其他厂商产品的支持也很有限。整体方案提供商和产品则包括Oracle公司的Warehouse Builder和IBM公司的Warehouse Manager。
3.3 还有一类是由开源提供的软件
这类产品虽然提供了开放的源码，需要提供专业人员进行维护、修改升级。当然也可以直接使用其产品，但出现的BUG问题较多，软件灵活性可能比不上专业的ETL工具，也没有相应的产品支持人员，更重要的是对开源项目升级后，以前的基于开源项目开发的系统的升级将变得十分麻烦。这类的ETL工具包括Kettle, 。
4.报表工具简介
报表工具软件的实现也可分为以下两种：
一大类是采用独立报表服务器的，如Bo/Crystal Report，Brio，Cognos，和勤等；
另一大类是在前端有控件的，如数巨报表等。
独立报表服务器的问题在于：
●独立的报表服务器，直接限制了报表的性能瓶颈
●无法共享web服务器的集群能力
●无法共享web服务器的连接池管理能力
●无法统一部署，实施人员既要部署自己的web应用，还需要部署报表服务器
●独立报表服务器往往有一套自己的用户角色管理机制，与用户的应用衔接起来问题
多多
前端控件方式的问题在于：
●用户部署起来非常麻烦，每台机器都要安装控件。（为解决这个问题，有些厂商把
原来控件所做的报表计算工作移到服务器上做，但只能在Windows下运行，因为它不是纯Java的)
●控件会对大报表产生性能问题，因为其报表生成与计算工作是在控件中实现的。
●应用系统无法灵活地通过API对报表进行控制- 因为是在控件里。
●产品升级- 将会是一大麻烦，客户端都要重新下载新的控件。
5.前端展现
像数据仓库、ETL、OLAP，这些都算是后台产品，主要集中在数据层面或是应用服务层面。这次就来谈谈前端的产品，它们负责直接面向用户，将用户的请求转发给服务层、数据层，同时也要向用户展现所需信息。
目前提供前端产品的厂商可以分为两类：
一是专业前端产品提供商，此类公司规模一般不会太大，国外有ProClarity、InSight，国内则要数菲奈特名气稍大；
二是全方案提供商，几乎都是国外公司，如BO、Cognos、Hyperion等都提供前端产品。
6.建行RIDE报表工具介绍
对其他的报表展现以及报表制作工具，不在赘述，这里简单介绍以下目前建行ODSB采用的报表展现工具RIDE。
6.1 RIDE介绍
报表集成开发环境(Reporting Integrated Development Environment),RIDE并不是报表开发工具，而是用户和报表工具之间的一个中间件，为用户提供了一套完整的、统一的界面门户。如图所示：
从后端到前端是信息生产的过程，从前端到后端是用户信息消费过程，这两者的结合点在RIDE，通过RIDE把信息生产产生的报表信息发布到RIDE中进行管理；同时利用RIDE的逻辑系统服务功能，按照业务范围或者用户需求的不同把信息以逻辑系统的形式发布给前端展现。
这样，用户面对的不再是不同的系统和BI工具，而是一致风格和操作习惯的RIDE；
同时针对BI工具的一些不足和共性功能可以在RIDE环节集中解决，是一种主动适应用户需求的方式。
6.2 RIDE的应用
为了保证RIDE在各环境下的适应性，RIDE在BI工具、数据库、应用服务器、操作系统等方面对产品或工具提供了较广泛的支持，在BI工具方面支持Cognos、MSTR 等；数据库支持Oracle、Informix和SQLServer等；J2EE应用服务器支持WebLogic、Tomcat、WebSphere等；操作系统支持IBM AIX、HP-UX、RedHat Linux、Windows等
6.3 RIDE功能
SQL Engine
提供统一的SQL生成和关系型数据库调用功能，并确保其功能的独立性。关系型
数据库支持主流的Oracle、Informix等。
●MDX Engine
提供统一的MDX生成和MDB调用功能，并确保其功能的独立性。
●数据处理Engine
基于SQL Engine和MDX Engine之上的完整的查询定义、数据处理和封装。
●前端工具Engine
支持不同前端工具报表集成到RIDE的接口。
●信息管理Engine
对不同的信息内容提供统一的信息管理功能调用。
●工作流Engine
对RIDE中各种工作流操作提供统一的工作流功能调用