再谈Kettle 性能问题
最近talend 的一些讨论似乎又激起了kettle 社区的一些"回应" , 讨论的问题又回到了性能的问题上，按照talend 的说法，kettle 的性能不如talend 的, 然后kettle 的首席架构师matt 又出来回应,然后就出现了关于ETL工具性能的讨论:
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" 的全库导入导出不知道什么时候可以做好.