做数据转换有不短的时间了,积累的经验不能满足新增的需求,上网找了一些ETL的资料,记录之,供参考

数据“大力擒拿手”

———三大主流ETL工具浅析

本报特约撰稿人 刘庆 2006-4-12 阅读人次：10875

-->

--> BI项目中最耗费人力的环节是什么？恐怕还要数ETL（抽取、转换和装载）工具。在传统的非BI项目中同样存在很多“导数据”的工作，那么，在数据仓库中又该如何选择合适的ETL工具来支撑抽取、转换和装载三个细分步骤？本期专栏就选取三个主流工具做一选型评析。 ETL产品乍看起来似乎并不起眼，单就此项技术本身而言，几乎也没什么特别深奥之处，但是在实际项目中，却常常在这个环节耗费太多的人力，而在后续的维护工作中，更是经常让人伤透脑筋。之所以出现这种状况，恰恰与项目初期没有正确估计ETL工作、没有认真考虑其工具的功能有很大关系。 在此，主要列举三种主流ETL产品。 旗鼓相当 Datastage与Powercenter 就Datastage和Powercenter而言，这两者目前占据了国内市场绝大部分的份额，从成本上看水平相当，虽然市面上还有诸如Business Objects公司的Data Integrator、Cognos公司的DecisionStream，但尚属星星之火，未成燎原之势。 谈Datastage和Powercenter，如果有人说这个就是比那个好，那听者就要小心一点了。在这种情况下有两种可能: 他或者是其中一个厂商的员工，或者就是在某个产品上有很多经验，而在另一产品上缺乏经验的开发者。为什么得出这一结论？一个很简单的事实是，从网络上大家对它们的讨论和争执来看，基本上是各有千秋，都有着相当数量的成功案例和实施高手。确实，工具是死的，人才是活的。 在两大ETL工具技术的比对上，可以从以下五个方面考虑。 一个项目中，从数据源到最终目标表，多则上百个ETL过程，少则也有十几个。这些过程之间的依赖关系、出错控制以及恢复的流程处理，都是选择工具时需要重点考虑的。在这一方面，Datastage的早期版本对流程就缺乏考虑，而在后来则加入Job Sequence的特性，可以将Job、shell脚本用流程图的方式表示出来，依赖关系、串行或是并行都可以一目了然。Powercenter有Workflow的概念，也同样可以将Session串联起来，这和Datastage Sequence大同小异。 ETL的元数据包括数据源、目标数据的结构、转换规则以及过程的依赖关系等。在这方面，Datastage和Powercenter从功能上看可谓不分伯仲，只是后者的元数据更加开放，存放在关系数据库中，可以很容易被访问。此外，这两个厂家又同时提供专门的元数据管理工具，Ascential有Metastage，而Informatica拥有Superglue。你看，就不给你全部功能，变着法子从你口袋里面多掏点钱。 数据质量方面，两种产品都采用同样的策略—独立于ETL产品之外，另外有专门的数据质量管理产品。例如和Datastage配套用的有ProfileStage和QualityStage，而Informatica最近也索性收购了原先OEM的数据质量管理产品FirstLogic。 在具体实现上看，Datastage通过Job实现一个ETL过程，运行时可以通过指定不同参数运行多个实例。Powercenter通过Mapping表示一个ETL过程，运行时为Session，绑定了具体的物理数据文件或表。在修改维护上，这两个工具都是提供图形化界面。这样的好处是直观、傻瓜式的；不好的地方就是改动还是比较费事的。 定制开发方面，两者都提供抽取、转换插件的定制，但笔者认为，Datastage的定制开发性要比Powercenter强那么一点点。因为Datastage至少还内嵌一种类BASIC语言，可以写一段批处理程序来增加灵活性，而Powercenter似乎还缺乏这类机制。 总起来看，Datastage和Powercenter可谓旗鼓相当，在国内也都有足够的支持能力。Datastage在2005年被IBM收购之后，可以说后劲十足，而Informatica则朝着BI全面解决方案提供商的方向发展，Powercenter显然还是它的核心产品。 独树一帜 NCR Teradata的Automation 第三种产品是NCR Teradata的Automation。之所以拿它单独来说，是因为它和前面两种产品的体系架构都不太一样。与其说它是ETL工具，不如说是提供了一套ETL框架。它没有将注意力放在如何处理“转换”这个环节上，而是利用Teradata数据仓库本身的并行处理能力，用SQL语句来做数据转换的工作，其重点是提供对ETL流程的支持，包括前后依赖、执行和监控等。 这样的设计和Datastage、Powercenter风格迥异，后两者给人的印象是具有灵活的图形化界面，而 Automation，有人说它其实应该叫做ELT，即装载是在转换之前的。的确，如果依赖数据仓库的能力去处理转换，恐怕只能是ELT，因为转换只能在数据仓库内部进行。从这个角度看，Automation对数据仓库的依赖不小，似乎是一种不灵活的设计。也正是这个原因，考虑它的成本就不单单是ETL产品的成本了。 其实，在购买现成的工具之外，还有自己从头开发ETL程序的。有人用C语言编写，有人用存储过程，还有人用各种语言混杂开发，程序之间各自独立。这很危险，虽然能够让开发者过足编码的瘾，却根本不存在架构。 有位银行的朋友，他们几年前上的数据仓库系统，就是集成商自己用C语言专门为他们的项目开发的。单从性能上看似乎还不错，然而一两年下来，项目组成员风雨飘零，早已物是人非，只有那套程序还在那里；而且，按照国内目前的软件工程惯例，程序注释和文档不全或者不一致，这样的程序已经对日常业务造成很大阻碍。最近，他们已经开始考虑使用ETL工具重新改造了。 ETL工具选型参照表 工具 优点 缺点 主流工具 Datastage 内嵌一种类BASIC语言，可通过批处理程序增加灵活性，可对每个job设定参数并在job内部引用 早期版本对流程支持缺乏考虑；图形化界面改动费事 Powercenter 元数据管理更为开放，存放在关系数据库中，可以很容易被访问 没有内嵌类BASIC语言，参数值需人为更新，且不能引用参数名；图形化界面改动费事 Automation 提供一套ETL框架，利用Teradata数据仓库本身的并行处理能力 对数据库依赖性强，选型时需要考虑综合成本（包括数据库等） 自主开发 相对于购买主流ETL工具，成本较低 各种语言混杂开发，无架构可言，后期维护难度大。

添加人：孙可