基于JAVA开源工具KETTLE的ETL研究和实现---毕业论文

本 科 毕 业 论 文 基于JAVA开源工具KETTLE的ETL研究和实现Research and Realization of ETL based on Java Open Source Tool KETTLE姓 名： 学 号：学 院：软件学院系：软件工程专 业：软件工程年 级：校外指导教师： 校内指导教师： 年 月摘 要ETL（Extract-Transform-Load）用来描述将数据从来源端经过萃取（extract）、转置（transform）、加载（load）至目的端的过程。ETL作为BI/DW（Business Intelligence/ Data Warehousing）的核心和灵魂，能够按照统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据仓库转化的过程，是实施数据仓库的重要步骤。目前ETL过程中经常采用三种方法：第一种是借助专业的ETL工具实现；第二种是SQL编程方式实现；第三种是ETL工具和SQL相结合实现。前两种方法各有优缺点，第一种可以快速的建立起ETL工程，屏蔽复杂的编码任务，提高速度，降低难度，但缺少灵活性。第二种的优点是灵活，提高ETL运行效率，但是编码复杂，对技术要求比较高。第三种综合了前两种的优点，可以极大地提高ETL的开发速度和效率。目前在市面上存在着很多种ETL工具，其中不乏开源的精品，KETTLE就是一款以JAVA为开发语言的ETL开源工具。本文以金融银行的数据仓库为研究背景，分析其ETL架构，继而以KETTLE为工具、以Teradata为数据库，借助ETL工具的方便性和SQL语句的灵活性来构造一个数据仓库的ETL流程。主要内容如下：(1) 分析了当前数据仓库的研究现状、数据仓库的概念和ETL本质及ETL在数据仓库过程中的作用，阐述了ETL的体系结构、元数据和数据仓库的关系。(2) 通过金融银行数据仓库的ETL架构实例，阐述了ETL流程中的各个过程，分析其实现方法及出现的问题，并在此基础上提出ETL的体系结构。(3) 研究了Java开源ETL工具KETTLE的源码，编写插件来增加KETTLE的功能，使其配合Teradata数据库的使用。(4) 最后运用工具与SQL语句相结合的方式，尝试以元数据为驱动，利用Teradata数据库和KETTLE工具来完整的实现一个ETL的架构。本文研究和实现的ETL架构，适合于多种不同的数据源，经测试可以方便、快捷的实现数据仓库的ETL过程。关键词：数据仓库；ETL；KETTLEAbstractETL stands for extract, transform and load, the processes that enable companies to move data from multiple sources, reformat and cleanse it, and load it into another database, a data mart or a data warehouse for analysis, or on another operational system to support a business process. ETL for the heart and soul of BI / DW (Business Intelligence), can be integrated in accordance with uniform rules and to increase the value of data, is an important step in data warehouse.There are three common methods of ETL process frequently used: the first one is using the professional ETL tools, the second one is using SQL programming. And the third one is the combination of SQL programming and ETL tools. The first two methods have both advantages and disadvantages: with ETL tools，we can set up ETL project quickly, shield the complexity of the encoding task, increase the speed and reduce the difficulty, but lack flexibility. The SQL programming has advantages in flexibility and improves the efficiency of ETL. However, it increases the complexity and requires relatively high coding skill. The third one combines the advantages of the first two, which greatly improves the speed and the efficiency of ETL development.Focusing on financial and banking data warehouse, the ETL architecture based on the database of Teradata is analyzed in this paper. Then a data warehouse ETL process tool which joins Teradata and KETTLE, ETL tool with the convenience and flexibility of SQL statements is constructed. The main contents are as follows:(1) Review the current researches on data warehouse, and then describe the concepts of data warehouse and ETL process. Finally, it elucidates the relationship between ETL architecture, metadata and the data warehouse.(2) Through the example of the banking data warehouse ETL architecture, this paper illustrates the process of ETL, analyzes its implementations and problems during the implementations. Finally, it concludes the concept of the ETL architecture.(3) Do some researches on the source code of KETTLE, an open sourced tool that is developed by Java. Then create plug-ins to improve the cooperation between KETTLE and Teradata database.(4) Finally, a framework of ETL is implemented, which is combined with SQL programming and the ETL tools. It is based on metadata-driven approach by using Teradata database and KETTLE tool. The ETL framework that implemented in this paper, can adapt to various of databases. As the test result shows, this framework can realize the ETL process conveniently and efficiently.Key words: Data Warehouse; Extract-Transform-Load; KETTLE目录第一章引言11.1 课题研究的背景11.2 国内外研究现状21.3 论文的主要内容3第二章数据仓库和ETL介绍42.1 数据仓库介绍42.1.1 数据仓库的定义42.1.2 为什么需要数据仓库52.1.3 数据仓库的体系结构62.2 ETL介绍72.2.1 数据提取82.2.2 数据清洗92.2.3 数据转换92.2.4 数据加载102.2.5 元数据对ETL的作用102.3 本章小结11第三章某商业银行ETL框架实例分析123.1 项目背景123.2 总体设计方案123.2.1 基本设计思想123.2.2 系统逻辑架构133.2.3 网络拓扑与物理架构143.2.4 ETL服务器环境153.3 数据装载163.4 ETL任务和调度193.4.1 任务触发193.4.2 日切/翻牌223.5 本章小结23第四章基于KETTLE的ETL系统架构244.1 系统基础工具分析244.1.1 Java开源ETL工具KETTLE及其插件244.1.2 Teradata数据库介绍284.1.3 Perl脚本294.2 ETL整体架构294.2.1 总体设计思想294.2.2 系统逻辑结构图304.2.3 源系统导出314.2.4 文本文件加载到SDATA临时库334.2.5 SDATA层到PDATA层的转换344.2.6 整体框架的自动化运行344.2.7 元数据设计354.3 ETL详细设计364.3.1 ETL目录结构364.3.2 Teradata 数据库结构374.3.3 元数据设计384.3.4 KETTLE工作流设计444.3.5元数据生成任务XML534.4 ETL框架实例测试534.4.1 测试案例背景534.4.2 插件和KETTLE源码测试544.4.3 ETL作业生成测试544.4.4 ETL作业运行测试554.5 ETL架构性能分析564.6 本章小结56第五章总结与展望585.1 本课题研究工作的总结585.2 进一步工作的建议58致谢59参考文献60ContentsChapter 1 Introduction11.1 Research background11.2 Recent Development21.3 Contents3Chapter 2 Data Warehouse and ETL42.1 Introduction to Data Warehouse42.1.1 Definition of Data Warehouse42.1.2 Why Do We Need Data Warehouse52.1.3 Architecture of Data Warehouse62.2 Introduction to ETL72.2.1 Data Extraction82.2.2 Data Cleaning92.2.3 Data Transformation92.2.4 Data Loading102.2.5 Metadata102.3 Summary11Chapter 3 ETL Case123.1 Project Background123.2 Overall Design Architecture133.2.1 Basic Design Idea133.2.2 Logic Structure133.2.3 Network Topology and Physical Structure143.2.4 ETL Server Environment153.3 Data Loading163.4 ETL Tasks and Scheduling193.4.1 Task trigger203.4.2 Flop223.5 Summary23Chapter 4 ETL System Architecture 244.1 Systems Tools244.1.1 KETTLE and Plug-ins244.1.2 Teradata274.1.3 Perl284.2 ETL Architecture294.2.1 Design Thinking294.2.2 Logical Structure294.2.3 Export The Source System304.2.4 Loadeding334.2.5 Transform334.2.6 Auto Running344.2.7 Metadata344.3 ETL Detailed Design364.3.1 ETL Directory Structure364.3.2 Teradata Database Structure374.3.3 Metadata Design384.3.4 KETTLE Workflow444.3.5 Metadata Generation Task XML534.4 ETL Case Test534.4.1 Background534.4.2 Plug-ins and Source KETTLE Test544.4.3 ETL Generate Test544.4.4 ETL Running tests554.5 Performance Analysis564.6 Summary56Chapter 5Conclusions and Future Work585.1 The Summary Of The Research Work585.2 Further work58Acknowledgements .59Reference .60第一章 引言第一章 引言1.1 课题研究的背景相对许多行业而言，信息处理技术还是一门新兴的技术，但其发展速度却几乎是最快的。随着计算机硬件技术的发展，软件技术也日益更新。从目前的情况来看，许多企业和机构已经建立了相对完善的OLTP，即联机事务处理系统（On-Line Transaction Process）。随着时间的推移，这些系统中积累了大量的历史数据，其中蕴含了许多重要的信息。通过对这些历史数据的分析和综合处理，可以找到那些对企业发展至关重要的业务信息，从而帮助有关主管和业务部门做出更加合理的决策。七十年代中期出现的MIS（管理信息系统Management Information System）实际上就是在这种背景下产生的。但MIS具有很大的局限性。首先，它基本上是按照预先定义好的流程对数据作相应的处理，因此只能对预先描述好的业务问题进行回答；其次，由于开发工具的限制，对其的修改也不太方便，特别是当业务流程发生变化，模型需要调整时，这种修改变得更加困难；最后，由于数据的不断积累，数据量迅速增加，普通的商用数据库(即OLTP数据库)难以处理，系统的扩展存在很大的限制1。在这种情况下，MIS逐步发展到了数据仓库。世界上最早的数据仓库是NCR公司为全美，也是全世界最大的连锁超市集团Wal*Mart在1981年建立的，而最早将数据仓库提升到理论高度进行分析并提出数据仓库这个概念的则是著名学者Bill Inmon，他对数据仓库所下的定义是：数据仓库是面向主题的、集成的、稳定的、随时间变化的数据集合，用以支持管理决策的过程2。由此可见，数据仓库是一个综合的解决方案，主要用来帮助企业有关主管部门和业务人员做出更符合业务发展规律的决策。因此，在很多场合，决策支持系统也成了数据仓库的代名词。ETL（Extract-Transform-Load）是BI/DW（Business Intelligence/ Data Warehousing）的核心和灵魂，按照统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据仓库转化的过程，是实施数据仓库的重要步骤。如果说数据仓库的模型设计是一座大厦的设计蓝图，数据是砖瓦的话，那么ETL就是建设大厦的过程。在整个项目中最难部分是用户需求分析和模型设计，而ETL 规则设计和实施则是工作量最大的，其工作量要占整个项目的60%-80%，61这是国内外专家从众多实践中得到的普遍共识。1.2 国内外研究现状数据集成的研究3始于七十年代中期，其发展大致可分为两个阶段，第一阶段以多数据库系统的研究为主。这方面的研究基本上可分为三大类，第一类采用物理上分布，逻辑上集中的系统结构，系统有全局的模式，但是各数据库结点缺少自治性，难以管理和集成。第二类是Mcclod于八十年代中期提出的联邦式数据库系统的概念，这是一种逻辑上和物理上都分布的结构，每个结点有自己的联邦模式，而不是唯一的全局数据模式，由于不再受制于全局模式，结点的自治性得到加强，数据库系统的集成、扩充和重新配置也较为方便和自然，但是数据库之间的通信受限制。第三类是Litwin 等人倡导的多库语言数据集成方法，这种系统既无统一的全局模式，也无局部的联邦，节点自治性更强，但用户必须接受一种新的数据语言，且透明性较差。进入九十年代中期，随着计算机网络的普及和WWW 的出现，传统的数据集成技术己无法适应人们获取更多数据的需求4，人们要求数据集成系统不仅能 集成数据库中的数据，而且能集成非数据库中的数据，如XML数据不仅能集成传统数据，而且能集成多媒体数据；不仅能集成己有数据源中的数据，而且能集成随时加入新数据源中的数据。也就是说，数据集成的研究必须具有可扩展性，可以实现数据源的“即插即用”，于是诞生了“通用异构数据源集成”的概念，这是数据集成发展的第二阶段。目前国内对通用数据集成工具的研究几乎属于空白，一部分的数据仓库系统是设计与其应用背景相关的、专用的数据集成工具，只能在其具体的业务背景下使用，另一部分则是直接编写脚本来实现对数据的抽取、转换和加载。无论是上面提到的哪一种，他们有一个共同的缺点，那就是灵活度低，设计一个E T L过程的周期长，浪费大量的人力、物力。此外，还有一些用于异构数据库系统的转换工具，但是这些工具的功能简单，不能满足对于数据的清洗、转换等一系列复杂的功能要求。在学术界很多学者提出了很有建树的方法，如基于视图监视的数据集成技术，基于CORBA的数据集成技术，基于X ML的数据集成技术，基于消息中间件的数据集成技术等。国外对数据仓库相关技术的研究更加全面和成熟，特别是对于在数据仓库建设中占比重如此之大的E T L过程的研究。目前在数据仓库领域里比较成熟的通用数据集成工具主要有Ascential公司的DataStage，CA公司的Transformer，Teradata公司的ETL Automation等。这些工具在功能上可以说己经基本上能满足一般的E T L要求，但是他们也存在一些缺点：第一，提供给用户的接口有限，不能满足用户对该工具进行二次开发，使得更加贴近实际需要的要求；第二，价格昂贵，动辄几十上百万，国内一般的企业负担不起；第三，国情不同，这些工具虽然具有了相当的通用性，但是仍然不能完全满足国内用户的需要。1.3 论文的主要内容本文力图通过对商业银行的ETL框架的分析，最后通过Java的开源ETL工具KETTLE来展现一个以Teradata作为数据库的ETL流程。论文的组织结构如下：第一章主要介绍了论文研究的背景、研究的现状及本课题的研究内容等；第二章主要介绍数据仓库和ETL的概念，ETL的本质及其作用，分析元数据在构建ETL架构中的作用；第三章主要对某金融银行的ETL架构进行分析。第四章在分析完ETL架构之后，利用KETTLE实现一个以Teradata为基础的ETL框架。第五章对论文的研究工作进行总结，并提出未来的设想。第二章 数据仓库和ETL介绍第二章 数据仓库和ETL介绍2.1 数据仓库介绍数据仓库是以计算机应用为基础的信息系统，用来支持在各领域的决策分析。数据仓库作为一个集成了许多数据源的中央数据库系统，从许多不同的( 分散的、互不联系的) 联机事务处理数据源收集和提取数据，并通过一系列汇总计算将数据组织成易于分析的形式，从而为企业提供了一个信息集成平台，为管理人员和决策者迅速地提取信息并回答有关业务运作的问题提供支持。因此，数据仓库是企业信息资产的核心，是管理信息系统的“上层建筑”。2.1.1 数据仓库的定义数据仓库概念的提出者、美国著名信息工程专家 William.Inmon 博士在90年代初提出了数据仓库概念的一个表述。他认为：“一个数据仓库通常是一个面向主题的、集成的、随时间变化的、但信息本身相对稳定的数据集合，它用于对管理决策过程的支持。”2 所谓主题，是指用户使用数据仓库进行决策时所关心的重点方面，如：收入、客户、销售渠道等；所谓面向主题，是指数据仓库内的信息是按主题进行组织的，而不是像业务支撑系统那样是按照业务功能进行组织的。所谓集成，是指数据仓库中的信息不是从各个业务系统中简单抽取出来的，而是经过一系列加工、整理和汇总的过程，因此数据仓库中的信息是关于整个企业的一致的全局信息；所谓随时间变化，是指数据仓库内的信息并不只是反映企业当前的状态，而是记录了从过去某一时点到当前各个阶段的信息。通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。而信息本身相对稳定，是指一旦某个数据进入数据仓库以后，一般很少进行修改，更多的是对信息进行查询操作。依据上面的定义，有人可能会把数据仓库简单地理解为仅仅是一个大型的数据存储机制，是一个静态的概念。实际上，数据仓库更像一个过程，这个过程涉及数据的收集、整理和加工，生成决策所需要的信息，并且最终把这些信息提供给需要这些信息的使用者，供他们做出改善业务经营的正确决策。数据仓库的重点与要求就是能够准确、安全、可靠地从业务系统中取出数据，经过加工转换成有规律信息之后，供管理人员进行分析使用。因此数据仓库是一个动态的概念，应该称为数据仓库工程（Data Warehousing）。2.1.2 为什么需要数据仓库数据库及其理论已经出现将近150年。早期的数据库主要是一些独立的数据库，应用于企业数据处理的各个方面从事务处理到批处理，再到分析处理。早期的大多数数据库系统主要集中于操作性的日常事务处理。近年来，出现了一种更高级的数据库观念，即一种数据库服务于操作型需求，而另一种数据库则服务于信息型或分析型需求。从某种程度上讲，这种数据库的新颖思想是随着个人计算机技术、第四代程序设计语言（4GL）技术以及最终用户需求的出现而产生的。将操作型数据库和信息型数据库分离开，是出于以下原因2： (1) 服务于操作型需求的数据在物理上不同于支持信息型或分析型需求的数据。(2) 主持操作型处理的技术从根本上不同于支持信息型或分析型需求的技术。(3) 操作型数据的用户群体不同于信息或分析型数据所支持的用户群体。(4) 操作型环境的处理特点与信息型环境的处理特点从根本上是不同的。分析型环境或称为决策支持系统（DSS）环境。信息型和决策支持系统处理的核心是数据仓库。什么是分析型、信息型处理呢？这种处理服务于决策支持过程中的管理需求，一般称为DSS处理，要在大量的数据中分析处理探索趋势。不同于只查找12条数据记录（如操作型处理），当DSS分析人员进行分析处理时，需要访问大量的数据记录。DSS分析人员很少修改数据。而在操作型系统中，数据在个体记录层次上经常修改。在分析型处理中，需要经常访问记录，收集来的记录内容用于分析的需要，但很少或不需要对单个记录进行修改。相对于传统的操作型处理，在分析型处理中，响应时间的要求大大放宽。分析型处理的响应时间可以是30分钟到24小时。这样的响应时间标准对于操作型处理而言是一个巨大的灾难。服务于分析型用户群体的网络比服务于操作型用户群体的网络的规模小得多。通常情况下，分析型网络的用户比操作型网络的用户少很多。与应用于分析型环境的技术不同，操作型环境中的技术必须将技术本身与数据和事务锁定、数据争用、死锁等因素结合起来考虑。正是这样，在操作型环境和分析型环境之间存在许多重大差别。针对这两者而设计的数据库和数据仓库有以下区别：(1) 数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储在线交易数据，数据仓库存储的一般是历史数据。(2) 数据库设计是尽量避免冗余，一般采用符合范式的规则来设计，数据仓库在设计是有意引入冗余，采用反范式的方式来设计。(3) 数据库是为捕获数据而设计，数据仓库是为分析数据而设计，它的两个基本的元素是维表（维是看问题的角度，比如时间、部门，维表放的就是这些东西的定义）和事实表（事实表里放着要查询的数据，同时有维的ID）。2.1.3 数据仓库的体系结构一个完整的数据仓库结构一般由6个基本层次组成，如图2-1所示：数据展示数据源数据源数据源数据后端处理数据仓库及其管理元数据管理数据集市数据集市数据集市基于数据仓库的应用图 2-1 数据仓库的体系结构 各层次基本功能如下：(1) 数据源：为数据仓库提供数据来源。一个数据仓库可以有多个数据源，而且这些数据源可以有多种不同的数据结构类型，可以是关系数据库如DB2、Oracle等，也可以是各种数据文件如Excel、Word、Lotus以及HTML、XML等文件格式。数据源一般是分布在网络中，通过网络中的数据接口与数据仓库连接。(2) 数据后端处理：是数据源与数据仓库间的数据接口层，也叫抽取层。它的功能是将数据源的数据进行提取、清洗、转换，最终构建成数据仓库所需的数据。所谓的ETL就是在这一层。(3) 数据仓库及其管理：包括数据仓库、数据仓库管理和元数据管理。数据仓库负责存储分析、决策数据；而数据仓库管理则负责管理数据仓库；元数据管理负责对元数据进行管理。元数据描述了数据仓库的数据和存储环境，数据仓库设计运行、维护与使用的基本参数，是整个数据仓库的核心。(4) 数据集市：是面向特定应用的决策数据集合，它与数据仓库的关系有点类似于视图与表的关系。(5) 基于数据仓库的应用：包括分析、决策应用，如OLAP、数据挖掘等。(6) 数据展示：将应用结果，特别是分析、决策结果以多种媒体形式展现出来。目前市场上有多种数据展示工具，如BRIO、BO等。2.2 ETL介绍ETL，Extraction-Transformation-Loading的缩写，中文名称为数据抽取、转换和加载。ETL负责将分布的、异构数据源中的数据如关系数据、平面数据文件等抽取到临时中间层后进行清洗、转换、集成，最后加载到数据仓库或数据集市中，成为联机分析处理、数据挖掘的基础，如图2-2所示。ETL是数据仓库中的非常重要的一环。它是承前启后的必要的一步。相对于关系数据库，数据仓库技术没有严格的数学理论基础，它更面向实际工程应用。所以从工程应用的角度来考虑，按着物理数据模型的要求加载数据并对数据进行一些系列处理，处理过程与经验直接相关，同时这部分的工作直接关系数据仓库中数据的质量，从而影响到联机分析处理和数据挖掘的结果的质量。数据库文件其他抽取转换加载目的数据库临时数据库元数据图2-2 ETL体系结构2.2.1 数据提取数据的抽取就是从不同的网络、不同的操作平台、不同的数据库及数据格式、不同的应用中抽取数据。数据的抽取必须能够充分满足数据仓库系统分析及决策支持的需要，同时必须保证不能影响业务系统的性能，所以进行数据抽取时必须充分考虑这些因素，制定相应的策略。就抽取数据的时效性而言，包括增量抽取、完全抽取等方式。增量抽取即每次只抽取自上次数据抽取以来产生的增量数据。增量抽取的优点是抽取的数据量小，从而转换和加载的数据量也小，能够极大提高数据加载性能。完全抽取是抽取业务系统中指定业务的所有数据，在两种情况下采用完全抽取方式：（1）数据量很小，采用完全抽取方式性能更高；（2）实在无法分离出增量数据。数据抽取的时机，必须尽可能避开业务系统的高峰时段，比如在夜间业务系统比较闲时。2.2.2 数据清洗数据清洗实际就是利用有关技术如数理统计、数据挖掘或预定义的数据清洗规则将脏数据转化成满足数据质量要求的数据。按照数据清洗的实现方式与范围可将数据清洗分为四种：(1) 手工实现方式：用人工来检测所有的错误并改正。这只能针对小数据量的数据源。通过专门编写的应用程序，通过编写程序检测/ 改正错误。但通常数据清洗是一个反复进行的过程，这就导致清理程序复杂、系统工作量大。(2) 某类特定应用领域的问题，如根据概率统计学原理查找数值异常的记录。(3) 与特定应用领域无关的数据清洗，这一部分的研究主要集中于重复记录的检测删除。2.2.3 数据转换数据转换是指对从业务系统中抽取的源数据根据数据仓库系统模型的要求，进行数据的转换、清洗、拆分、汇总等处理，保证数据按要求装入数据仓库。以下原因可能会使数据转换工作变得复杂:(1) 源数据系统同数据仓库系统在模型上的差异性。(2) 源数据系统平台不一致：数据仓库系统的数据源可能包括基于不同平台的数据库的数据。(3) 源数据结构的不一致：有些数据源由于历史的原因，导致同一个表在不同的时期数据结构不一致。(4) 源数据定义不规范导致错误数据。(5) 对数据的约束不严格，导致无意义数据。(6) 存在重复记录。(7) 由于平台系统的不同，可能会存在大量的转码工作。根据实际情况，数据转换工作一般会在以下几个环节中具体实现：(1) 在抽取过程中进行数据处理。(2) 使用异步数据加载，以文件的方式处理。(3) 在数据加载过程中进行数据处理。(4) 进入数据仓库以后再进行数据处理。采用在数据抽取过程中进行数据转换时，必须考虑抽取的性能以及对业务系统性能的影响：采用异步数据加载需要以文件方式处理时，必须充分考虑中间磁盘的存储量以及整个流程的协调性工作和大量的非语句的编程；采用在数据加载过程中进行数据转换时，必须考虑加载性能；采用先将数据装载到数据仓库后再处理时，必须考虑数据仓库引擎的海量数据处理能力。2.2.4 数据加载数据加载就是将从源业务系统中抽取、转换后的数据加载到数据仓库系统中。一般来讲，不同的数据仓库提供厂商，都会有自己的数据加载工具以及深入编程的接口。API对于用户而言，需要重点考察的是数据加载工具的加载性能，比如移动公司每天都产生大量的数据，所以要求数据加载工具必须具有高效的加载性能。有两种加载技术：使用数据仓库引擎厂商提供的数据加载工具进行数据加载和通过数据仓库引擎厂商提供的编程A P I 进行数据加载。在两种数据加载技术中，前一种对于开发人员来讲操作比较简便；后一种方法需要部分程序编写工作，但性能上可能会好一些。具体选择什么技术，必须根据实际的系统及数据量情况进行权衡。数据加载策略主要包括两方面的内容：加载周期及数据追加策略。加载周期是指多长时间从业务系统中抽取并向数据仓库中加载一次数据。数据追加策略是指数据每次是如何向数据仓库系统中追加的。动态数据仓库是数据仓库系统未来的发展趋势，利用动态数据仓库可以实现数据仓库同业务系统的协同工作，将数据仓库系统的功能由战略制定扩展到战术实施。这就要求数据仓库中的数据必须同数据库中的数据保持同步，这里就引申出一个数据加载周期问题。对不同业务系统采用不同的加载周期，但必须保持同一时间业务数据的完整性。2.2.5 元数据对ETL的作用元数据是关于数据的数据，其对于ETL来说尤其重要。ETL中大量的数据源定义、映射规则、转换规则、装载策略等都属于元数据范畴，如何妥善的存储这些信息不仅关系到ETL过程能否顺利完成而且影响到后期的使用和维护。任何业务逻辑的微小改变最终都落实为相应元数据的调整，初期没有一个完善的元数据管理功能，后期作类似调整几乎是“不可完成的任务”。基于元数据的重要性，国际组织提出一些统一的元数据存储标准，比较知名的如CWM等。这为不同厂商工具之间互操作提供了可能性，相信也是以后的发展趋势。针对ETL的元数据管理应包括：元数据存储的开放性；元数据存储的可移植性；提供多种方式访问元数据；元数据的版本控制；支持开放的元数据标准；支持XML进行元数据交换；支持分布式的元数据访问和管理；生成元数据报表；对于ETL过程的冲突分析；基于元数据的查询功能；元数据的广播和重用；对于ETL过程的流程分析等。2.3 本章小结本章主要介绍了数据仓库和ETL的相关概念，简要概述了ETL各个阶段的主要内容，分析了ETL体系结构、元数据、数据仓库和ETL的关系。良好的ETL体系结构和完善的元数据对提高数据仓库的运行质量具有重要意义。第三章 某商业银行ETL框架实例分析第三章 某商业银行ETL框架实例分析3.1 项目背景某商业银行DW&MIS（数据仓库和管理信息系统）项目一期已于2006年8月底成功上线试运行，目前总体运行情况良好。该项目主要构建了数据仓库的基础技术平台，整合了包含 DCC、总账、ECIF（客户化信息整合系统）、国际卡等在内的八个源系统的账户、客户（部分）数据，实施了资产负债管理，提供了静态流动性报表、产品定价器等功能，支持对某商业银行全行资金进行全额计价，满足了银监会1104监管报表报送要求，提出了数据管控策略，并对未来七年容量需求作了总体规划。目前，数据仓库每天增量数据约15G，输出报表80张，达到项目预期目标6。在之后的DW&MIS二期和DW&MIS三期中，为了充分体现数据仓库的投资价值，在不断促进数据仓库数据的积累、模型的完善、数据质量改进的同时，数据仓库支持的应用需求越来越多。目前已知的需求主要包括：ECIF贡献度计算、资产负债管理（ALM Asset Liability Management）一期优化、1104监管报表、CCMIS数据整合、OLAP应用、资本充足率报表、中间业务分析、可预见的分析型客户关系管理（ACRM）、国际卡业务分析（CCMIS）二期、ALM二期等6。如此多的基于数据仓库的 MIS 类应用的实现都离不开整合、共享的基础数据的支持。数据是数据仓库和 MIS 应用主题间的主要联系，数据仓库应用支持项目的主要内容就是为管理决策提供数据支持。为了实现对应用需求的快速响应和提供不间断的长期支持，数据仓库建设必须依据应用发展需求，提前进行数据规划和技术基础改进工作，在项目滚动实施过程中不断改善数据质量，提高数据支持能力。3.2 总体设计方案3.2.1 基本设计思想综合全行总体规划思想和DW一期项目中ETL架构的优缺点，结合数据仓库项目螺旋式的特点：(1) 利用Ascential的DataStage的并行加载ODS（操作数据存储）能力来缓解Teradata设备的压力。(2) 尽可能的连续处理，避免ETL环节的无效等待，节约时间窗口。(3) 遵循ODS开发策略，实现ODS与DW的统一配置。(4) 利用Perl脚本来完成数据的转换和加载功能。(5) 采用Control_M（BMC公司的作业调度产品）来处理任务的调度。3.2.2 系统逻辑架构图3-1 ETL系统架构如图3-1，在DW系统范围内，主要存在4个ETL过程，分别为：(1) 从源系统（主要是ODS系统）到SDATA区域的数据加载。(2) 从SDATA（临时数据库）到PDATA（数据仓库数据库）的ETL处理过程。(3) 从模型数据区以及汇总区域到内外部数据集市的数据抽取过程。(4) 反馈数据的处理。在此前的项目一期中，ETL调度工具主要是使用Teradata自带的开源工具Automation进行调度，采用FastLoad工具进行加载的。在项目二期和三期中，对此进行了改造，主要进行和的ETL改造：(1) 利用Datastage实现ODS向DW的数据加载过程，改变现有FastLoad工具加载方式。l 在数据加载之前完成必要的合并操作，简化原有数据加载流程。l 完成数据检查的参数化配置，减小变更的复杂程度。l 实现特定字段加载方式，减少网络、存储和数据加工的压力。(2) 利用Datastate实现DW向外部集市进行数据导出，改变现有FastExport工具的文本导出方式。l 通过Datastage直接导出数据至外部集市数据库。l 导出过程中完成数据加工。(3) 尝试PDM脚本移植，在保证效率和数据层次完整的前提下改造数据加工任务。(4) 采用Control_M代替ETL Automation进行调度工作。3.2.3 网络拓扑与物理架构如图3-2所示，主要的物理部件有：ETL和ODS调度服务器、Teradata服务器、磁带机、网络设备等。其中Teradata的数据库服务器采用的是WorldMark 5460服务器，系统采用Teradata专用的MP-RAS系统，保证了整个数据仓库流程的效率。图3-2 网络拓扑与物理架构3.2.4 ETL服务器环境从DW系统的特点以及ETL基本架构上，可以将ETL分为3个环节：(1) 源ETL：从数据源到仓库的ETL过程。(2) 仓库ETL：仓库内部的ETL过程。(3) 目标ETL：仓库到目标的ETL过程。从图3-1上，源ETL过程主要由ODS负责处理，主要功能是对分散的各源系统（主要为操作型的业务系统，如核心业务系统、个贷系统等）进行标准化，并将数据加载至仓库的SDATA。ODS采用了多台PC服务器作为集群，承担DataStage处理节点。仓库内部的ETL过程和目标ETL过程都将处理大量的数据，但是从ETL本身来看，整个ETL流程并不复杂，在逻辑上，一个ETL环节往往是数据加载、SDATA整合PDATA、数据导出这三个环节连续顺序的执行。在调度上，除数据加载由ODS系统负责完成以外，DW内部的ETL调度均由唯一的Control-M/Server调度。在物理上将内部ETL过程和到目标的ETL过程统一部署在一个集群内，采用4台4CPU、8G内存的PC服务器，通过1000兆网络连接。图3-3 ETL服务器环境3.3 数据装载数据装载主要指将ODS处理的数据经过合并、技术检查、字段筛选处理后导入DW系统的SDATA区。在DW一期，源系统数据至SDATA的加载完全由DW系统完成。ODS通过集群对全行的几十个系统的数据进行标准化处理，大部分数据按照分行分别存储，数据仓库系统需要对数据进行合并、技术检查、字段筛选等操作后才能装入仓库SDATA区。大部分的处理压力都集中在数据仓库系统，随着仓库系统的数据不断丰富，接入系统的不断增加，最终将无法承受巨大的数据处理压力。如图3-4所示：图 3-4 数据加载方式ODS系统的主要功能是对数据进行标准化和检查，而DW系统中的选取、合并、检查等功能也隶属于ODS标准化和检查范畴，为了统一架构，集中处理，方便管理维护，在DW二期，将选取、检查、合并的操作统一交给ODS系统处理。DataStage已经在ODS系统中广泛使用，并且得到统一的部署和调度，有专门的小组负责监控管理，使用DataStage的作业（job）来完成DW一期中由Fastload工具所做的工作，并且通过DataStage强大的并行处理和管道机制，减少数据的落地，减少I/O的开销和物理存储的消耗。如图3-5所示。其中，技术检查和字段筛选都通过参数形式实现。由DW提供参数文件。数据装载统一由ODS系统完成，加工处理规则以及检查规则由DWAF项目提供，ODS将处理后的数据直接加载到DW系统SDATA区域。调度接口：ODS在完成对SDATA每个数据表的处理后，生成一个控制文件，该控制文件用以来表示该作业成功处理完成。在DW系统中，定制一类文件扫描任务，用来扫描该控制文件是否生成，而后续的作业都以该文件扫描任务作为前提条件。如图3-6所示：图3-5 ODS处理流程图3-6 ODS跟Control_M接口3.4 ETL任务和调度ETL调度是ETL过程中非常重要的一个模块，它主要负责对ETL作业的调用，监控并记录作业的执行状态。在此项目中采购了BMC公司的调度产品Control-M，从全行的角度出发，使用统一的调度产品。所有从源数据到缓存区、缓存区到数据仓库及数据仓库到数据集市的ETL任务都需要ETL 工具统一调度，ETL调度程序应包含以下功能：(1) 并发执行ETL任务（并行处理）；(2) 在指定时间启动ETL任务；(3) 在某一相关任务