linux上Kettle定时执行（转换的单步执行，job的单步执行，环境变量，kettle定时功能，效率问题等）转自（http://blog.csdn.net/feng19821209/article/details/5800960）
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，很有帮助。
a.使用资源库（repository）登录时，默认的用户名和密码是admin/admin。
b.当job是存放在资源库（一般资源库都使用数据库）中时，使用Kitchen.bat执行job时，需使用如下的命令行：
Kitchen.bat /rep kettle /user admin /pass admin /job job名
c.当job没有存放在资源库而存放在文件系统时，使用Kitchen.bat执行job时，需使用如下的命令行：
Kitchen.bat /norep /file user-transfer-job.kjb
d.可以使用命令行执行job后，就可以使用windows或linux的任务调度来定时执行任务了
e.如果出现异常语句，
Unexpected error during transformation metadata load
No repository defined!
请按上面的操作排除。
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，那么后台就会拼命的输出日志，会在很大程度上影响速度，此处一定要注意。
插入更新是在java中比较完成。
7，常见的调试BUG。
Kettle提供了很多调试的解决办法，但是对于常见的调试BUG还是能避免就避免。
1）路径问题。我最常遇到的问题就是在windows下调试成功，但是部署到UNIX下出问题，忘记将windows下路径变成unix下，经常会出现问题。
2）输出端，数据库插入更新选择不对。输出端，提供了三种数据库输出的办法，数据库输出，插入/更新，更新，对于这三种，各有利弊，如果你知道数据库输出，完全是插入，如果有重复数据，则会报错；插入更新和更新，因为更新数据时，后台输出很多日志，会导致效率很低。
