使用Kettle的几点用法和感受

使用Kettle一个多月，记录一下临时的感受和印象较深刻的步骤。
(基于Kettle 4.1.0 stable， SQL Server 2005， WindowsXP & 2003)

几点用法

1. 在一个Transformation里面的不同步骤中传递参数
1) 向Execute SQL Script传递参数
步骤-1：从数据源头获取一行数据
步骤 0：Select Values （针对一行进行有选择地取出某些字段，比如取出5个字段，每个字段作为变量参数，传递给下一步的SQL）
步骤 1：Execute SQL Script（进一步选取上一步输出的某几个字段值，比如从上面5个字段里面再筛选出4个，作为执行SQL的参数）
这4个字段是：aid，bid，date，amount，其中id是string，date是datetime，amount是decimal
那么在步骤 1中的SQL脚本中使用如下：

declare @aid varchar(20)
declare @bid varchar(20)
declare @date datetime
declare @amount decimal(19, 2)

set @aid = '?'
set @bid = '?'
set @date = '?'
set @amount = ? 
...

其中@amount的?是不需要引号的。因为kettle实际上用的是全局替换（这一点很重要，我被迷惑了很久），如同C/C++中的const常量，编译后全部替换成指定的值。
否则如果amount的值是20， 如果加了引号，就变成了set @amount = '20',这和decimal的类型冲突。会出错。而id和date类型的变量就可以赋值为字符类型。

选项要点：
Execute for each row：
要选中。很好理解，对每一行输入都要执行该SQL语句
Execute as a single statement:
要选中。否则你在里面写的大段大段的SQL就被一行一行地执行，会大面积出错。
Variable Substituation:
要选中。这里牵涉到传进来的多个参数的赋值顺序问题。上面的aid先赋值，那系统怎么知道第一个问号是上一步传进来的哪个参数呢？就要由这一步来决定顺序。要在左下方的表格里指定好传进来的参数列表和顺序

2)向Table Output中的SQL Script传递参数
Table Output也可以使用SQL，同样也可以使用参数。不过这里使用的参数就不是全局替换了。这个就和通常编程序里面遇到的?类似了。举例：

步骤0：获取当前数据仓库的时间戳，然后从源数据库抽取出大于该时间戳的数据进行增量处理。本步骤返回时间戳。
步骤1：使用Table Output。利用SQL并且使用上步传进来的时间 datetime 类型。本步骤里唯一打勾的就是对Replace Variables in Script

这一次datetime类型作为参数，在SQL中使用的就是?,而不需要引号。要区别于上一个主题中的全局替换。

2. 在不同的Transformation/Sub Job 中传递参数
下面这篇文档说得很好了。
Using Named Parameters in Kettle
http://type-exit.org/adventures-with-open-source-bi/2010/07/using-named-parameters-in-kettle/

3. 循环处理
这个是避免不了的。ETL时总会遇到这种事情。抓来一行数据，处理到多个表中。再继续处理下一行。这个网上的例子很多，就不再啰嗦。我试过的可行的办法是：
在上一个Transformation中的最后一步用Copy Rows to Results作为末节点
在当前Transformation中的第一步使用Get Rows From Results，并且，对当前的Transformation的属性 Execute for every input row 打勾 （Advanced tab）

这两步足矣，但是不幸的是它有内存泄漏。所以承受不起很大的数据量。如果你每天增量循环处理的数据量小于1万条，那还凑合。这是个不太准的说法。实际上这个和你的机器内存，数据量大小有直接关系。

4. 定期处理
比如只有周一做某一件事，其它日子跳过这一步。可以使用JavaScript，封装在一个Tranformation中，返回true/false。然后在下一个Transformation中进行条件判断和处理，合理使用Dummy这个节点。我曾经想在一个Tranformation完成上述处理。发觉很麻烦，有点被绑架的感觉。为了一个简单的步骤要额外造出很多轮子。反而分开处理还相对方便一点。

用后感受
使用Kettle一个多月，积累了一些想法。以后可以慢慢修正。

1. Tranformation内部还是之间
我有贪心的感觉总想把相关联的步骤放在一个Tranformation里面解决。但是有时候根本不合适，反而更麻烦。网上也有很多讨论，其中较多人推荐的一个方案就是把某些动作独立到各自的Tranformation中，从而简化处理的复杂度。

2. 性能
我用的不多，所以不好一棍子打死。毕竟才用了不到2个月。分区和集群都没有研究过。所以本观点具有时效性。但还是觉得Kettle性能方面确实没什么优势。看到有的人用kettle说每天能处理几个G的数据都没问题，我表示怀疑。当然如果相对简单的并发抽取，并发导出而没有较多的中间数据处理步骤，应该可以做得到吧。

我把含有一个20万，两个15万条数据的xml文件简单直接导入三个单个数据库表中用了20多分钟，而且还没有加索引（64位windows，8G），并发执行。不过把这三个表反过来导出到xml文件中，就很快了，几十秒。

我这里主要是指在进行对每行循环处理的时候有内存泄漏。循环处理了几万条以后内存使用量达到8G，垃圾回收不回去，不停的增长。这就是问题了。所以后来改了策略，先到一个数据库里把之前的历史数据用存储过程，游标等常规手段进行抽取，花了十几个小时。之后就是每天的增量更新，最多不过2000条。绕过了这个问题。

我又想，这也许就是开源软件的通病？据说（没试过），Mondrian的OLAP Server 也是处理不了大数据，我在网上看到类似的讨论。我用过BIRT进行Cross table的变换，导出的excel文件接近30M，也是慢的不行，本地处理需要5分钟以上。毕竟BIRT的强项不是多维查询，还是以展现为主吧。

3. 并发和同步
基本上Tranformation内部是并发的，除非你特别指定需要同步。这样的设计理由很简单，提高处理速度。对于Transformation之间包括sub job，缺省是顺序执行，不是并发的，你可以指定并发。
但是也不一定。所以上述的描述并不准确。

比如在Tranformation内部使用Block this step until steps finish,有时候就不管用。
再比如在Tranformation之间的动作也不一定严格顺序，有时候上一步的文件处理压缩还没完成，下一步的删除文件动作就开始了。结果把不该删的先删掉了。当然这个都是设计问题。

重点是不要迷信，重点是你必须要测试它的行为是不是你需要的。你希望并发，那就要测试一下它真的并发了吗？你希望它顺序执行，就要多次测试，是否真的同步执行了。实践是检验真理的唯一标准。

4. bug
Kettle的小问题还是很多的。我没有资格去抱怨人家的劳动成果。只是觉得在开发的时候测试很重要。有时候根据文档说明想当然地用了合适的步骤去做事，结果偏偏不按你想的那样出现。搞到最后，就是更加细心，更加胆小，有点不信任的感觉。
比如在使用4.0.1 stable 版时用到了支持数据库事务的属性，发现一到commit的时候就停住不走了。后来翻啊翻，发现是个bug，有人已经报到kettle项目的JIRA里面去了。据说4.1.0已经fix了，还没有测试过。 Kettle支持的功能越来越多，现在还支持JSON输入，bug也会增加，不可避免。

还是那句话：全面的测试很必要的，实践是检验真理的唯一标准。

Kettle还是好东西，为什么，就因为它是LGPL。以不同的生活水平来比较Kettle和Informatica也没什么意思。

好的网站
在研究的时候经常会被google导到这个网站http://type-exit.org/adventures-with-open-source-bi/
虽然它的方案有时候并不正确。但是讨论的内容比较全面。学习Kettle的人可以参考一下这个网站。

要淡定，自己手工做把。这玩意儿不怎么靠谱。

相当不靠谱，很容易出错

最近有用到Kettle,我只是做点封装.受LZ点拔在理解上貌似又前进了一小步.在此小谢下LZ分享的点滴感受.引进kettle自有它的价值,总比坐在一边说风凉话的好.

使用ETL这种玩意
我记得有个经典评价
他的效率比好的程序员写的要差
但是总比差的程序员写的效率要高。