Kettle定时执行

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，那么后台就会拼命的输出日志，会在很大程度上影响速度，此处必定要注意。

7，常见的调试BUG。
    Kettle提供了不少调试的解决办法，可是对于常见的调试BUG仍是能避免就避免。
    1）路径问题。我最常遇到的问题就是在windows下调试成功，可是部署到UNIX下出问题，忘记将windows下路径变成unix下，常常会出现问题。
    2）输出端，数据库插入更新选择不对。输出端，提供了三种数据库输出的办法，数据库输出，插入/更新，更新，对于这三种，各有利弊，若是你知道数据库输出，彻底是插入，若是有重复数据，则会报错；插入更新和更新，由于更新数据时，后台输出不少日志，会致使效率很低。