http://www.gemini5201314.net/?p=129

主要比较了kettle 和talend 在读和写方面的性能测试, 由于有代码可以自己运行, 每个人都可以试一下结果,

一个ETL转换肯定会有写的步骤,所以主要说明一下同时有读和写的情况

文件大小为2.4GB , Kettle 单步骤运行的时候, 读大概:12 – 18M/s , 写大概14M/s , 平均0.7GB/min.

2步骤运行的时候, 读还是12-18 M/s , 写大概18M/s ,平均1.0GB/min , 写是在两个文件上, 但是还是由一个物理磁盘来写的.

运行这个测试的机器是普通的笔记本电脑,估计硬盘的缓存大小为16M/s , 由于写的时候是Linux 系统(kubuntu 8.10), 所以写的速度最大可以略微超过一点.

我在自己的电脑上也测试过这个转换任务, 读大概是18-20M/s , 写只有接近600M/min , 之所以速度慢的原因是我的物理磁盘比较慢, 磁盘是Maxtor 的, 缓存大小只有8M/s , 所以一分钟的最大速度只可能有8*60M/min = 480M/min , 所以我的写速度大概是600M /min 不到是正常的.

由于这个任务的CPU 利用率也比较高,都会达到100% , 所以更强的CPU 也可以提高速度.

关于查看硬盘的信息由多种方式,我是在windows 下, 所以可以使用windows 优化大师的硬件查看功能,如下图: 缓存只有8M/s , 所以速度不是很快, 如果有更快的物理磁盘,这个转换任务会更快.

Linux 下可以使用iostat 命令,比如原测试环境就是使用iostat –k 5 来测试的,硬盘缓存大小为16M/s , 其他的Linux 命令比如hdparm 也可以帮你了解你的硬盘(hdpart –T /dev/sda ) , 或者使用一些专用的IO 测试工具,比如oracle 的orion 之类的.

另外注意这个转换有一些参数需要注意一下, 文件读写尽量使用CSV 文件或者Fixed Text 文件, 这是使用NIO 优化过了的, 注意NIO Buffer 的大小,里面设置的是50M , 文件大的时候就设置大一点, lazy convertion 开启了, 文件格式记得要fast data dump (不开启的话,比较耗CPU,根据你需要决定),

另外不要误以为左边Slave Server 有几个server 就认为这个转换是在cluster 下执行的, 左边的slave server 跟这个完全没关系, 上面CSV 步骤上写的 "x2" 是指这个转换步骤的copy number ,你在这个转换步骤上右键点击选"change number of copys to start" 里面填上你需要的copy number ,  集群的配置是根据你的slaver 数量来决定的,你是不能手工输入多少slaver 来执行,而且他是在步骤的右上角写"Cx2" ,而不是左上角的"x2" .   当然, 虽然这个转换本身是单机的,但是即使换在cluster 环境下执行,也是同时可以既有集群数,也有copy number 的.

这个转换是以文件为主, 如果你在大批量的导入文件到数据库的时候,还是建议使用数据库本身的特有的Bulk Loader , Kettle 也有不少的插件可以支持特定数据库的Bulk Loader 操作, 比如目前已经有Oracle Bulker Loader, Greenplum Bulker ,Postgresql Bulk Loader ,LucideDB Bulk Loader . 相当于在数据库的客户端(Kettle 运行转换的服务器端)执行, 本身要指定你的数据库安装的目录文件位置. 集群的话当然也要保证在每一个Kettle 运行的服务器端都安装好了数据库的客户端软件,不然转换肯定会出错.

1. 图形化设计器生成XML设计文件,然后有个engine 执行
2. 图形化设计器生成某种编程语言代码,然后执行代码
3. 使用某种ETL 引擎框架, 通过编程来执行ETL任务
4. 手工写代码执行

每一种方式实际上都不能完全解决各种复杂的企业数据集成的需求,图形设计器设计出来虽然方便,维护轻松,但是不够灵活,对于传参数,动态判断条件,跟企业已有系统集成较为困难,而使用编程或ETL执行引擎虽然能解决前面的缺点,但是太过复杂,维护成本高,需要比较多的技巧.

Kettle 作为第一种ETL工具, 虽然在功能和易用性上做的不错,但是如果你要从一个已有的程序里面传参数,或者根据一些动态条件来修改设计文件,甚至完全不依赖设计器用编程的方式实现ETL任务基本上都是不可能的.

新出现的kettle jdbc driver 则一部分解决了上述问题, 通过像sql 一样的语法从一个kettle 转换里面取出结果,然后在程序里面使用. 它可以取出任意步骤的结果.

它里面提供的演示是基于pentaho 的,如果不是很懂pentaho 的话建议用文本编辑器打开看一下就好了,而且都是报表的演示,可能不一定都看得懂. 如果想用的话还需要研究一下.

这个项目在google 上, 同时有国内的一位朋友qinhui99 参与, 有兴趣可以去看一下他的个人主页:

http://qinhui99.itpub.net/

参考资料

http://code.google.com/p/jdbckettle/

jdbc kettle 的主页

1. 把kettle 尽量放在顶层目录比如 E:/pdi 下,减少字符长度

2. 把libext/JDBC 目录下的不用的数据库驱动删掉,比如你只用mysql 和oracle 就只保留mysql-connect-xxx.jar 和ojdbc12.jar 其他的都删掉,

3. 在xp 系统下把cmd.exe 文件拷贝到2000 下, 这个字符串长度限制是写死的,xp 的长度限制为8091.

另外需要注意的是至少需要jdk 1.5 以上才能运行, 1.4 是不行的, 我用的是jdk 1.6 的, 点那个kettle.exe 文件它还报错说要jdk 1.5 , 不用exe 文件启动,直接点spoon.bat 启动就是好的.

参考资料

http://tech.it168.com/d/2008-03-21/200803211924754.shtml

开源ETL工具kettle系列之增量更新设计技巧

http://tech.it168.com/n/2008-03-21/200803211716994.shtml

开源ETL工具kettle系列之建立缓慢增长维

http://tech.it168.com/d/2008-03-18/200803171550713.shtml

开源ETL工具kettle系列之动态转换

http://wiki.pentaho.com/display/EAI/Windows+2000

pentaho wiki 上说的解决方法

http://support.microsoft.com/kb/830473

windows 长度限制

1 .http://blog.gobansaor.com/2008/12/04/pentaho-data-integration-kettle-v-talend-benchmark/

事情的起因,

2. http://www.nicholasgoodman.com/bt/blog/2008/11/26/an-arms-race-my-customers-dont-care-about/

kettle 社区的一些回应

3 .http://www.ibridge.be/?p=150

matt 做的实验

按照matt 做的实验 , 环境是在他个人笔记本上，

CPU Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz
Disk 90GB 7200 rpm laptop disk
Memory 3.3GB, 666Mhz
OS Kubuntu 8.10 : Intrepid Ibex
Linux kernel 2.6.27-8

kettle 和talend 简单的读一个2.4G 的csv 文件，每次都是运行5次取平均值，talend 需要108秒，速度大概是1.3Gb/分钟 ，kettle 需要150秒, 速度大概是1GB/分钟 ,  当kettle 使用集群时(单机的一主一从) , 大概需要94 秒，速度是1.5GB/分钟,

kettle 在运行最快的时候比talend 快大约19% . 

在读取文件并回写的测试中,文件还是刚才的2.4G csv 文件, talend 大概需要330秒，04GB/分钟 , kettle 在没有集群时需要196秒，速度大概是07gb/分钟 , 使用一主一从的集群时大概要150秒， 速度为1gb/分钟.  kettle最快的速度比talend 快120%,     kettle 跟unix 的cp 命令比起来还差20% 的速度(毕竟人家是以操作系统的block 为单位) .

最后结论比较简单，没有集群的情况下,talend 读比较快，写一般，但是在kettle 使用集群的情况下(talend 没集群) , 速度就不再同一级别.

另外注意的时，由于测试环境用的电脑很一般，所以即使你使用更多的集群速度也不会又提升，因为硬盘就是一普通的笔记本硬盘， 如果在专门的服务器上使用SCSI 硬盘测试的话，速度会更快.

最后matt 给出了测试结果和 运行的代码. 你也可以自己运行这些测试

http://www.ibridge.be/files/benchmarking-csv-file-read-write.zip

个人的一些想法:

就像文中所说的，由于每个人的配置不一样，可能你精通kettle ,所以你测试出来的结果kettle 会比较快，如果你精通talend ，可能talend 测试出来的比较快，所以一味的比较速度没有意思，没有办法在统一环境下测试.

另外就是个人觉得ETL工具的性能并不是ETL工具最先考虑的东西，功能和易用性和可管理性才是最重要的，kettle 在功能和易用性上得分比较高，可管理性则是很一般.

另外ETL工具中kettle 的性能一向都是很强的，早在kettle 被pentaho 收购之前，它在亚马逊云上的5 台服务器的集群速度就是4000 row * 5 , 而且由于kettle 配置集群又超级简单，而且是根据端口来区分节点，所以一台计算机上都可以配置几个从服务器, 上面给出的代码中就是这样的，不会配置的朋友可以看一下，（真的就是看一眼就懂了).

另外一个觉得很有意思的ETL工具就是oracle 的warehouse build 和data integration ,由于里面使用的是oracle 数据库专有的pl /sql , 不太清楚它的伸缩能力怎么样 (oracle 的hints 里面是可以控制并行度的，不知道pl /sql 会不会也有控制并行度的选项)

再加上kettle 的分区特性和正在做的"可配置并行度" , kettle 的伸缩能力是很强的. 所以性能问题一向都不是kettle 的弱项.

最后要说的就是还是最关心kettle 的可管理性，它的"transform 和 job " 的版本控制和 "Repository" 的全库导入导出不知道什么时候可以做好.

• Binary zip file (60 MB)
• Wiki documentation export (105 MB)
• Source zip file (72 MB)
• Javadoc zip file (7 MB)
• OSX dmg image (52 MB)
• Windows Installer : under construction

3.1 版中把文档分离出来，放在了pentaho的wiki上来，这次一共有562 个bug 修复和新功能.

新功能的介绍在http://wiki.pentaho.com/display/EAI/What%27s+new+in+PDI+version+3.1 上.

简单来说主要有一下一些改进：

1. 界面上的改进（增强易用性）

现在吧输出结果放在单独的面板里用tab分隔.

2. 性能图形

这个算是最大的一个改进，对性能输出增加了一个图形显示

3. 新的数据库连接对话框

以前那个对话框有很多不必要的东西，而且显示的UI 也太复杂，新的数据库连接对话框简化了一点.

4. Zoom

现在对于设计面板里面的东西都可以放大和缩小。

5. Snap to Grid

就是为了放大缩小而设定的格子的大小. 大概意思是一个格式多大吧.

6.  新的欢迎界面

新的欢迎界面多了一个教新手怎么开始的文档了 ，在 http://wiki.pentaho.com/display/EAI/Getting+Started

剩下的就是一些新的Step 和Job ,然后就是增加了几个冷门数据库的支持.可以在上面的what’s new in kettle 3.1 中找到，它每一个step ,job 都有文档的，大多数也有一个实例，还是在它的samples 目录下，个人觉得比较有用的几个step 是

SQL File Output 把结果输出成sql形式，然后后面又可以执行这个文件.

Add a checksum 在做type2 的缓慢维的时候可能有的人喜欢这种方式，不过不知性能会不会很慢.

Data validator 配合Error Handling 一起来验证数据的.（虽然我个人比较喜欢像OWB 那样把这种验证工作单独做成                          一种validate , clean , transform 的形式, 这种数据清理的工作和转换的工作分开.)

job 里面增加了一个shell 还蛮有用的，windows 下可以执行cmd 里的命令，linux 下更不用说了.