选择合适的ETL工具满足数据整合性能挑战

yangtao36 20060814

选择合适的ETL工具满足数据整合性能挑战

当选择ETL产品时,最关键的因素是考虑这个产品在你的指定的环境和配置下,这个产品的执行性能.

选择一个ETL软件方案过程是一个典型的复杂过程,需要评估很多功能,然而在评估ETL产品时最重要因素之一就是这个产品在你自己的环境和配置下这个产品的性能¬表现如何.

很多ETL软件供应商往往在他们的销售手册里通过给出令人印象深刻的性能数字,从而给他们方案的性能来下结论.这些数字总是被下面这样形式提供出来

这个工具能够在单位时间内转换多少行.

很多用户往往被这种令人印象深刻的性能数字所误导.而在实际的项目中证实这些令人深刻的性能数字远不是那么令人印象深刻的.这是因为在没有对一个信息系统进行全¬方位评估时,评估性能是最困难的任务之一.实际上性能在实际环境时是被总体架构和在ETL过程中的数据流动所影响的.
本篇文章提出了影响ETL过程的性能的几个关键因素.解释了某些产品的架构和方法提供了这些产品的独特优势.

历史背景

随着计算机系统从大型机到分布式系统的演变,商业智能出现了.第一代ETL方案被引入,从那个时代起几代ETL产品已经产生了.

第一代:最初的ETL和旧有系统的代码生成(Legacy Code Generators) .最初的数据集成工具在数据集成过程运行的操作系统平台上生成本地代码.这些产品实际上大多数产生COLBOL,因为在那个时代数据绝大多数存储在大型机上.

这些产品利用中心化的工具生成数据集成过程和发布代码到适当的平台,并通过代替手工编码使数据集成的过程更容易.使用这个方法性能会变得更好,这是源于本地编译¬代码具有的性能.然而这些工具要求你掌握不同的平台上深入的编程技能.维护也变得比较困难因为代码分散在不同的平台上对每一个源和目的都是不同的

这个架构提供了最佳性能的可能,因为数据是被存储在平面文件和层次数据库上,记录级的存取是很快的.虽然这种模型在大型机上运行的很好.然而在关系数据库上使用¬此方法证明是不成功的特别是当处理大数据量时.

第二代ETL:自有的ETL引擎.第二代ETL工具基本上基于自有的数据引擎(它位于源和数据仓库目的库之间)这个引擎运行所有的数据转换过程.这个方法解决了¬第一代ETL必须对不同平台使用不同语言的问题.而只需掌握这个ETL自有的语言.但是一个新的问题出现了,这个完成所有转换的自有数据引擎在转换过程中经常变¬成一个瓶颈.因为所有来自不同数据源的数据必须通过这个引擎一行一行的转换移动到数据目标库.当处理大容量数据量时,这个方法会变得很慢.

第三代ETL:E-LT(抽取-装载和转换)架构的介绍.

第三代工具解决了由前面工具带来的弱点而且保持了它们的强项.

第一代工具的强项—旧有代码生成器-是它们的集中式方法生成数据集成过程和自动发布代码到合适的平台上.这种生成的本地代码提供了很好的性能优势.第三代工具同¬样使用一个提供集中式方法和发布本地代码的分布式架构.

第二代工具的强项-它使用自有的数据引擎-是它的图形环境和转换功能.这个转换功能在90年代初期是SQL语言所不具有的.但是从第二代ETL出现起,数据库厂¬商已经在改进它们的SQL语言能力方面投入了很多资源.

第三代工具使用E-LT架构,它提供了一个高度图形化的环境,它并且具有生成本地SQL代码来在数据仓库服务器上执行数据转换的任务.这个新的方法具有下面比较¬明确的优点:
它降低了位于源和目的之间的ETL中心集线器的要求.而这个中心集线器普遍存在于第二代ETL产品中.

• 它使用了RDBMS(relation database management system)去执行数据转换这允许数据的bulk processing.( bulk processing处理速度是行行数据处理的1000倍).数据量要处理的越大,越显得bulk processing的重要.因为大的数据库厂商(IBM,Oracle,Microsoft,Sybase等)已经投入很多资源极大地改进了它们各自的数据¬引擎的性能.使用RDBMS数据引擎完成数据转换能够提供巨大的性能提高而且进一步借助于原先的技术投资.

• 使用E-LT

架构,所有的数据库引擎参与转换—也就是在它最优化的地方运行每部分转换.任何RDBMS都可以是数据引擎,也就是我们为了提高性能可以在源和目的上发布SQL¬代码.例如,我们可以把一个对二个表的join放在数据源上做.

• 一个集中控制式的设计工具使编程和维护变得更容易,它允许开发者控制那个数据引擎处理那块信息.

• 本篇文章的其余部分详细举出采用E-LT方法的产品的若干影响ETL过程性能的几个关键因素

E-LT架构

第三代ETL工具的革新性的架构在于它以SQL代码为基础,这借助了了目前已经安装在数据仓库的RDBMS的强项.

这种方法是和星型集线器的架构根本不同的,星型集线器的架构由一个集中式的自有的引擎来完成数据转换的处理.

E-LT架构在以下几个方面提高了性能.

它通过降低网络通讯来改善性能.E-LT和分布式架构的第一个益处是减少了网络上的通讯量.数据可以在源系统上被结合和过滤从而避免了到转换引擎的不必要的传输¬.

直接从源到目的的数据传输节省了很多时间是因为它提供了一条直接的通路,与此相反的是自有引擎,在这里数据通过网络被装入到数据引擎,数据引擎处理数据后同样通¬过网络把处理后的数据送到目的库.

在第二代ETL工具的星型和集线器架构里,所有的数据需要经过引擎,并被引擎以一行一行的方式处理.为了验证数据的完整性这会在自有引擎和目的库之间产生额外的¬网络通讯.不幸的是在网络上传输通常都是一种代价高昂的行动.更为有效的方式是应该在数据仓库服务器上完成数据转换任务从而可以大幅度减少网络通讯量.

它为了更好的扩展性而分散了负荷.

SQL代码生成的方法使E-LT分布式架构能够得到实现.数据集成工具允许每个RDBMS(源和或者目的的数据转换过程)参与转换过程.

因此当更多的数据服务器被加入到这个架构中,更多的数据要被处理.随着新的数据库出现,它们的引擎也被使用.这意味着附加的转换对现在的转换没有什么影响.一个¬分布式的架构很容易处理增加的数据库.与此相反,在带有一个自有数据引擎的架构里所有的转换是由自有数据引擎完成的,这会产生瓶颈.随着数据库的数目增加转换的¬数据量增大,自有引擎的负荷也增大了.传统的ETL工具很快地遇到硬件扩展问题既需要更多的资源(更多的处理器,更多的内存)以至于要求一个新的软件许可证来把¬负荷分散到多个自有引擎上去.然而即使你购买了更多的许可证,转换操作仍然是一行一行得处理.例如, 一行一行插入1百万行意味着送一百万个_insert命令到数据库.然而当你你以bulk方式移动数据,插入一百万行仅意味着一个_insert指令.

它分配负荷.由于它的指定负荷能力,第三代ETL工具提供了我们许多性能上的改进.

本篇文章已经强调这个事实.也就是它分配负荷从而降低以自有数据引擎架构普遍遇到的瓶颈问题.但是第三代工具的益处已经超越这些.例如你可以过滤你的数据,你很¬明显地要求在转换开始之前做这个操作.因此你要使用开发工具定义一个创立过滤器的规则,这避免了必须连接数据库和手写一段不能在工具里管理的脚本语言.

它支持所有种类的源.一个有效的第三代数据整合工具通过一个单独的图形界面让你控制各种数据源类型.(象数据库,平面文件,XML格式,LDAP服务器和从中间¬件的消息).

这个工具使你可以采用适合每一个转换的性能最好的技术.同一个厂商的数据库服务器通过RDBMS厂商提供的本地功能能够直接连接另一数据库(象dblink,l¬ink server等)—你可以建立这个配置过程并从ETL工具中监视这个过程.平面文件使用本地的应用工具直接转入到数据库中(SQL*loader,bulk _insert,bcp,FastLoad等).除次之外,这个有效的工具允许产生必要的配置文件和控制文件.这样一个产品通过确保生成代码是最适合你的情况,而¬提供最好的性能。

第二代工具既需要通过自有的loader装入数据到数据引擎,如果你要利用数据库的装载工具那就需要手工代码.但是这样一个方法会使你丧失开发工具的集中和跟踪¬性.

它充分利用了数据库自己的架构优势.因为一个第三代数据整合分配转换任务到数据引擎.它同样充分利用由RDBMS提供的高级功能.比如象在目前RDBMS出现的¬负载平衡,集束和大规模平行处理等.用第三代工具,你可以使用适合的参数,设置选项接着调用数据库工具来利用好这些这些功能.

选择合适的能够达到最优性能的ETL工具.

当你选择一个ETL工具时,需要考虑选中工具的几个因素.应该能够支持分布的数据整合需要并且要允许你借助于手头的资源和技术.数据整合工具的使用不应该干扰你¬现在的环境,而是应该充分利用由RDBMS和SQL提供的能力和功能.

如果性能是关键,确保选中的工具应该能够处理你需要处理的任何种类和容量的数据转换.当然也是最重要的是不要被误导的市场资料所欺骗.花点时间了解一下不同的E¬TL方法.确保你选择的软件有一个很广的实用性和可靠性以满足日益复杂的数据整合市场.

Qing 20060815

这是原创还是转载的？从整个文章的观点风格看，有点像软文。明显倾向于"第三代"ETL工具，让人不得不怀疑此文的客观性。

当然，从个人观点看，我也比较推崇ELT的路线。这个观点可纯粹是主观的。

ELT与其说是一种工具，不如说是一种框架，相对于代码生成器型和引擎型来说。因为大部分苦力活都让数据库自己干，它负责的只是哪些苦力活联系起来，制定一些大¬家遵守的规矩。这符合"术业有专攻"的想法，在数据库本身处理性能方面，ETL引擎再牛也牛不过数据库本身的。还不如放弃，干点自己适合干的事情。而适合干的，¬恐怕就是起到那种流程处理的功效了。

ETL引擎大多还有个特点，就是设计数据转换的图形化界面，操作实在是方便。不过心里老犯嘀咕，将ETL开发人员当作傻瓜是不是合适？也许，这种工具当初设计的¬思路是——一般不懂技术、不懂数据库的人也能够用这种工具捣鼓数据玩吧。

这当然是不现实的，谁没事折腾这玩意儿呢。因此，灵活易用的图形化界面，倒像一个鸡肋。你说不好吧，但用起来确实还挺方便，但你说它好吧，经常又受限于它。譬如¬作一些批量的修改，只能用鼠标点来点去，这是弱智干的事情。

我猜想，此文作者，十有八九跟sunopsis关系甚密。因为现在就数这家公司将ELT的概念叫嚣地最凶。在一般国外网站上，要是看到某则广告，上面在否定原来¬的ETL，强调ELT的强大优势。那就不用想了，基本上都是这家公司的广告。

不容易啊。

思路是好思路，不过要跟传统的ETL打架，如此的宣传还真是有必要。不过，想着哪些ETL引擎型的工具厂商，都是主流的，哪里轻易放弃。恐怕也不愿意轻易放弃自¬己引擎式的产品路线，可能会在自己产品上，增强流程处理、定制开发等功能吧。

yangtao36 20060815

对!这是我翻译的http://www.datawarehouse.com今年三月的一遍文章.我觉得我们在选择ETL工具时,它给出了一个观点.有助于我们选择.况且国内介绍关于这方面的概念的文章,几乎没有.实际上现在微软的DTS¬,SQL server 2005叫SSIS.oracle的OWB都是这类的E-LT框架的产品.不过它们只是支持自己的RDBMS做为数据仓库.不支持别的厂家的RDBMS最为数据¬仓库.这应该是个方向啊.理由是刘庆也说了,ETL的引擎在怎么强也强不过这些数据库的厂商数据引擎.我们想想oracle有多少用户有多大的资源,那些占主流¬地位的ETL厂家才有多少客户.我举个例子,在90年代中期的时候ETL的引擎比数据库厂商的引擎强,但到今天ETL厂商的引擎是不会赶上这些大数据库公司的数¬据引擎.举个oracle的例子,1995年Oracle 7的速查手册仅有2页（_insert，_delete uodate，create）。那个时代的SQL不能够满足ETL工作的需要。但是同样的速查手册到了最近开发的Oracle9，就有40页多。Oracle 9手册多出的38页主要是数据集成，聚合和数据转换指令。今天绝大多数的RDBMS有充分的能力去做任何转换工作。希望看到大家提出意见.

innovate511 20060816

ETL工具对于一些大型项目也是一种趋势，虽然我们很多ETL工作受限于他，但我们可以用其他程序或脚本来补充这些不足，这样就两全齐美了。做什么方向都需要向¬核心部门靠近，确实仅仅去努力掌握一些工具不是好注意，但没有他们，有时做项目又不方便。但由于不同工具使用方法不同，还在不断升级，这也给人们熟悉其操作带来¬些不便，所以需要有技术而且能掌握一定工具的人才合在一起，才能把有些项目做好。

yang_zxf 20060816

对于ETL工具，我们刚开始做项目的时候也是选用相应的ETL工具来实现，后来确实发现针对大数据量的处理方面，不如使用数据库的存储过程，所以在后来我们实施¬的项目中基本上所有的ETL工作都改成了存储过程来实现，ETL工具基本上都成了一个调度的平台，再后来我们干脆自己开发了一个调度平台，彻底丢掉了ETL工具¬。

当让ETL工具也有它的好处，ETL人员基本不用熟悉各个数据库太多的东西，就能够快速实施ETL工作，因为不同的省份使用的数据库可能是不同的。其次有关ET¬L规则变化后，修改还是相对比较容易，毕竟是图形化的界面，如果要去修改存储过程，那难度可就大了，特别是如果项目人员的变动，造成ETL工作的交接，就算是有¬比较详细的ETL规则文档，那也是比较麻烦的，另外如果后期的维护交给用户，那就更难了。

前段时间和保险公司的技术人员交流，他们就倾向于使用ETL工具，来进行ETL的实现，原因就是易维护性。

再一个就是有关元数据交换的问题，ETL工具一般都支持将元数据导出，而数据库的存储过程确实十分的困难，所以在构建元数据管理系统时，进行影响性分析，还是E¬TL工具比较方便的。

yangtao36 20060816

使用ETL工具在很多项目还是应该的,因为ETL工具具有version
control等支持多人开发的功能.但问题是选什么架构的ETL工具,是选择还要学习它的专有语言的ETL工具.还是采用E-LT架构的工具.如果采用第三代¬ETL工具,如果你是一个对你的RDBMS很熟悉的人,那么你基本不用学习.而且图形化的界面,自动生成代码的能力和第二代的能力一样强.

最值得称道的是如果你对做为数据仓库的RDBMS很熟悉并且原来采用过手工编写存储过程的人来说.你可以定制第三代ETL工具它的代码生成.而这种定制改变完全¬在你的工具掌握之内.

在对大数据量处理方面和你自己编的存储过程一样速度快.