1.KETTLE跨平台使用。
例如：在AIX下（AIX是IBM商用UNIX操作系统，此处在LINUX/UNIX同样适用），运行KETTLE的相关步骤如下：
1）进入到KETTLE部署的路径
2）执行 CHMOD *.SH，将所有SHELL文件添加可执行权限
3）在KETTLE路径下，如果要执行TRANSFORMATION，就运行./PAN.SH -FILE=?.KTR -DEBUG=DEBUG -LOG=LOG.LOG
其中。-FILE说明你要运行的TRANSFORMATION文件所在的路径；-DEBUG说明日志输出的级别；-LOG说明日志输出的路径
4）同理，对于JOB的执行，请将./PAN.SH更换成./KITCHEN.SH，其他部分说明不变。

2.KETTLE环境变量使用。
在TRANSFORMATION中，CORE OBJECTS-->JOB-->SET VARIABLES，可疑设置环境变量，对于绝对路径和相对路径的转换很有帮助，KETTLE的跨平台很大程度依靠他的

3.其它功能的使用。
其它功能包括DB存储过程调用，流查询，值映射，聚合记录等，各位自行摸索，有问题可以和我联系：）

4.KETTLE定时功能。
在JOB下的START模块，有一个定时功能，可以每日，每周等方式进行定时，对于周期性的ETL，很有帮助。

5.KETTLE经验之日志。
KETTLE对于日志的处理，存在一个BUG，看过上一篇的人或许已经看到了我的留言，KETTLE对于日志处理有一个BUG，当日志多于49M（不是50M，也不是49M），KETTLE就会自动停止，这一点我在源码里面也没有找到对应的设置和约束，原因还找不到，因为是日志没有写，所以原因也不好跟踪还不知道具体原因。

6.KETTLE之效率提升。
KETTLE作为一款ETL工具，肯定无法避免遇到效率问题，当很大的数据源输入的时候，就会遇到效率的问题。对此有几个解决办法：
1）数据库端创建索引。对需要进行查询的数据库端字段，创建索引，可以在很大程度上提升查询的效率，最多的时候，我不创建索引，一秒钟平均查询4条记录，创建索引之后，一秒钟查询1300条记录。
2）数据库查询和流查询注意使用环境。因为数据库查询为数据输入端输入一条记录，就对目标表进行一次查询，而流查询则是将目标表读取到内存中，数据输入端输入数据时，对内从进行查询，所以，当输入端为大数据量，而被查询表数据量较小（几百条记录），则可以使用流查询，毕竟将目标表读到内存中，查询的速度会有非常大的提升（内存的读写速度是硬盘的几百倍，再加上数据库自身条件的制约，速度影响会更大）。同理，对于目标表是大数据量，还是建议使用数据库查询，不然的话，一下子几百M的内存被干进去了，还是很恐怖的。
3）谨慎使用JAVASCRIPT脚本，因为JAVASCRIPT本身效率就不高，当你使用JS的时候，就要考虑你每一条记录，就要执行一次JS所需要的时间了。
4）数据库COMMIT次数，一条记录和一百条记录COMMIT对效率的影响肯定是不一样的。
5）表输入的SQL语句的写法。有些人喜欢在表输入的时候，将所有关联都写进去，要么FROM N多个表，要么IN来IN去，这样，就要面对我在2）里面说道的问题，需要注意。
6）注意日志输出，例如选择数据库更新方式，而且日志级别是DEBUG，那么后台就会拼命的输出日志，会在很大程度上影响速度，此处一定要注意。

7.常见的调试BUG。
KETTLE提供了很多调试的解决办法，但是对于常见的调试BUG还是能避免就避免。
1）路径问题。我最常遇到的问题就是在WINDOWS下调试成功，但是部署到UNIX下出问题，忘记将WINDOWS下路径变成UNIX下，经常会出现问题。
2）输出端，数据库插入更新选择不对。输出端，提供了三种数据库输出的办法，数据库输出，插入/更新，更新，对于这三种，各有利弊，如果你知道数据库输出，完全是插入，如果有重复数据，则会报错；插入更新和更新，因为更新数据时，后台输出很多日志，会导致效率很低。

总体来说，KETTLE还是一个很不错的ETL工具，在开源软件里面并不多见，以后有KETTLE相关的问题，大家可疑相互探讨。