ETL三大主流工具

转自：http://chenjinglys.blog.163.com/blog/static/16657571620113211381934/

ETL是数据仓库建设的重要环节。相对于关系数据库，数据仓库技术没有严格的数学理论基础，它更面向实际工程应用。所以从工程应用的角度来考虑，按着物理数据模型的要求加载数据并对数据进行一些系列处理，处理过程与经验直接相关，同时这部分的工作直接关系数据仓库中数据的质量，从而影响到联机分析处理和数据挖掘的结果的质量。
　　数据仓库建设是一个独立的数据环境，需要通过抽取过程将数据从联机事务处理环境、外部数据源和脱机的数据存储介质导入到数据仓库中；在技术上，ETL 主要涉及到关联、转换、增量、调度和监控等几个方面；数据仓库系统中数据不要求与联机事务处理系统中数据实时同步，所以ETL可以定时进行。但多个ETL 的操作时间、顺序和成败对数据仓库中信息的有效性至关重要。
　　ETL作为BI/DW（Business Intelligence）的核心和灵魂，能够按照统一的规则集成并提高数据的价值，是负责完成数据从数据源向目标数据仓库转化的过程，是实施数据仓库的重要步骤。如果说数据仓库的模型设计是一座大厦的设计蓝图，数据是砖瓦的话，那么ETL就是建设大厦的过程。在整个项目中最难部分是用户需求分析和模型设计，而ETL规则设计和实施则是工作量最大的，约占整个项目的60%～80%，这是国内外从众多实践中得到的普遍共识。
　　ETL工具中典型的代表产品有Informatica的PowerCent、Ascential的Datastage、Oracle的OWB、 Microsoft SQLServer2000的DTS、Microsoft SQLServer2005的SSIS服务等。目前在数据抽取过程中经常采用三种方法，第一种是借助专业的ETL工具实现；第二种是SQL编程方式实现；第三种是ETL工具和SQL相结合。前两种方法各有优缺点，借助工具可以快速的建立起ETL工程，屏蔽复杂的编码任务，提高速度，降低难度，但缺少灵活性。SQL编程的优点是灵活，提高ETL运行效率，但是编码复杂，对技术要求比较高。第三种综合了前两种的优点，极大的提高ETL的开发速度和效率。
　　在数据环境改造和数据库工程实施中（包括统一数据中心的建设过程中），我们可根据业主方的具体情况推荐相应的ETL工具采购或进行ETL及调度软件的定制研发，在节省投入、提高效率的前提下推进数据库/数据仓库的建设，贯彻落实好规划成果。

 

 

ETL（extract, transform and load）产品乍看起来似乎并不起眼，单就此项技术本身而言，几乎也没什么特别深奥之处，但是在实际项目中，却常常在这个环节耗费太多的人力，而在后续的维护工作中，更是往往让人伤透脑筋。之所以出现这种状况，恰恰与项目初期没有正确估计ETL工作、没有认真考虑其工具支撑有很大关系。

做ETL产品的选型，仍然需要从以前说的四点（即成本、人员经验、案例和技术支持）来考量。在此，主要列举三种主流ETL产品：Ascential公司的Datastage、Informatica公司的Powercenter、 NCR Teradata公司的ETL Automation。其中，ETL Automation相对其他两种有些特别之处，放在后面评述。

旗鼓相当：Datastage与Powercenter

就Datastage和Powercenter而言，这两者目前占据了国内市场绝大部分的份额，在成本上看水平相当，虽然市面上还有诸如Business Objects公司的Data Integrator、Cognos公司的DecisionStream，但尚属星星之火，未成燎原之势。

谈Datastage和Powercenter，如果有人说这个就是比那个好，那听者就要小心一点了。在这种情况下有两种可能：他或者是其中一个厂商的员工，或者就是在某个产品上有很多经验而在另一产品上经验缺乏的开发者。为什么得出这一结论？一个很简单的事实是，从网络上大家对它们的讨论和争执来看，基本上是各有千秋，都有着相当数量的成功案例和实施高手。确实，工具是死的，人才是活的。在两大 ETL工具技术的比对上，可以从对ETL流程的支持、对元数据的支持、对数据质量的支持、维护的方便性、定制开发功能的支持等方面考虑。

一个项目中，从数据源到最终目标表，多则上百个ETL过程，少则也有十几个。这些过程之间的依赖关系、出错控制以及恢复的流程处理，都是工具需要重点考虑。在这一方面，Datastage的早期版本对流程就缺乏考虑，而在6版本则加入Job Sequence的特性，可以将Job、shell脚本用流程图的方式表示出来，依赖关系、串行或是并行都可以一目了然，就直观多了。 Powercenter有Workflow的概念，也同样可以将Session串联起来，这和Datastage Sequence大同小异。

ETL的元数据包括数据源、目标数据的结构、转换规则以及过程的依赖关系等。在这方面，Datastage和Powercenter从功能上看可谓不分伯仲，只是后者的元数据更加开放，存放在关系数据库中，可以很容易被访问。此外，这两个厂家又同时提供专门的元数据管理工具，Ascential有Metastage，而Informatica拥有Superglue。你看，就不给你全部功能，变着法子从你口袋里面多掏点钱。

数据质量方面，两种产品都采用同样的策略——独立出ETL产品之外，另外有专门的数据质量管理产品。例如和Datastage配套用的有ProfileStage和QualityStage，而Informatica最近也索性收购了原先OEM的数据质量管理产品FirstLogic。而在它们的ETL产品中，只是在Job或是Session前后留下接口，所谓前过程、后过程，虽然不是专为数据质量预留的接口，不过至少可以利用它外挂一些数据质量控制的模块。

在具体实现上看，Datastage通过Job实现一个ETL过程，运行时可以通过指定不同参数运行多个实例。Powercenter通过Mapping表示一个ETL过程，运行时为Session，绑定了具体的物理数据文件或表。在修改维护上，这两个工具都是提供图形化界面。这样的好处是直观、傻瓜式的；不好的地方就是改动还是比较费事（特别是批量化的修改）。

定制开发方面，两者都提供抽取、转换插件的定制，但笔者认为，Datastage的定制开发性要比Powercenter要强那么一点点。因为Datastage至少还内嵌一种类BASIC语言，可以写一段批处理程序来增加灵活性，而 Powercenter似乎还缺乏这类机制。另外从参数控制上，虽然两者的参数传递都是比较混乱的，但Datastage至少可以对每个job设定参数，并且可以job内部引用这个参数名；而Powercenter显得就有些偷懒，参数放在一个参数文件中，理论上的确可以灵活控制参数，但这个灵活性需要你自己更新文件中的参数值（例如日期更新）。另外，Powercenter还不能在mapping或session中引用参数名，这一点就让人恼火。

总起来看，Datastage和Powercenter可谓旗鼓相当，在国内也都有足够的支持能力，Datastage在2005年被IBM收购之后，可以说后劲十足。而Informatica则朝着BI全解决方案提供商方向发展，Powercenter显然还将是它的核心产品。

独树一帜：Teradata的ETL Automation

继续要说的第三种产品是Teradata的ETL Automation。之所以拿它单独来说是因为它和前面两种产品的体系架构都不太一样。与其说它是ETL工具，不如说是提供了一套ETL框架。它没有将注意力放在如何处理“转换”这个环节上，而是利用Teradata数据库本身的并行处理能力，用SQL语句来做数据转换的工作，其重点是提供对ETL流程的支持，包括前后依赖、执行和监控等。

这样的设计和Datastage、Powercenter风格迥异，后两者给人的印象是具有灵活的图形化界面，开发者可以傻瓜式处理ETL工作，它们一般都拥有非常多的“转换”组件，例如聚集汇总、缓慢变化维的转换。而对于Teradata的 ETL Automation，有人说它其实应该叫做ELT，即装载是在转换之前的。的确，如果依赖数据库的能力去处理转换，恐怕只能是ELT，因为转换只能在数据库内部进行。从这个角度看，Automation对数据库的依赖不小，似乎是一种不灵活的设计。也正是这个原因，考虑它的成本就不单单是ETL产品的成本了。

其实，在购买现成的工具之外，还有自己从头开发ETL程序的。

ETL工作看起来并不复杂，特别是在数据量小、没有什么转换逻辑的时候，自己开发似乎非常节省成本。的确，主流的ETL工具价格不菲，动辄几十万；而从头开发无非就是费点人力而已，可以控制。至于性能，人大多是相信自己的，认为自己开发出来的东西知根知底，至少这些程序可以完全由自己控制。

就目前自主开发的ETL程序而言，有人用c语言编写，有人用存储过程，还有人用各种语言混杂开发，程序之间各自独立。这很危险，虽然能够让开发者过足编码的瘾，却根本不存在架构。

有位银行的朋友，他们几年前上的数据仓库系统，就是集成商自己用c语言专门为他们的项目开发的。单从性能上看似乎还不赖，然而一两年下来，项目组成员风雨飘零，早已物是人非，只有那套程序还在那里；而且，按照国内目前的软件工程惯例，程序注释和文档是不全或者是不一致的，这样的程序已经对日常业务造成很大阻碍。最近，他们已经开始考虑使用ETL工具重新改造了.