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,Kettle最佳实践
        一、当输入对象为CSV文件时，将NIO Buffer Size从默认的50000改到最佳的200000。

        二、 当输出对象为表输出时，将提交记录数量从默认的1000改到最佳的4000。

       三、尽可能关闭转换过程中一切与数据库相关的日志，如表日志、索引日志等。

        四、在数据库去重时，使用普通索引而不是唯一性索引。

        五、在插入数据之前，先使索引unusable，数据导完之后再rebuild索引。需要注意的是，像数据库去重这种需要索引来优化查询速度的情况可以排除在外。

        六、 索引和表数据使用不同的表空间，尽可能的减少IO争用。

        七、Kettle所在操作系统优先选择Windows，在有些情况下Linux的插入速度明显偏低。
       
        八、尽量使用数据库连接池

        九、尽量提高批处理的'commit size'

        十、尽量使用缓存，缓存尽量大一些

       十一、Kettle 是Java 做的，尽量用大一点的内存参数启动Kettle.

        十二、可以使用sql 来做的一些操作尽量用sql

        'Group , merge , stream lookup ,split field' 这些操作都是比较慢的，想办法避免他们。

       插入大量数据的时候尽量把索引删掉

　　尽量避免使用update ， delete 操作， 尤其是update ， 如果可以把update 变成先delete ，后insert。

　　 能使用truncate table 的时候，就不要使用delete all row 这种类似sql

　　如果删除操作是基于某一个分区的，就不要使用delete row 这种方式（不管是delete sql 还是delete 步骤），直接把分区drop 掉，再重新创建

　　 尽量缩小输入的数据集的大小（增量更新也是为了这个目的）

　　尽量使用数据库原生的方式装载文本文件(Oracle 的sqlloader ， mysql 的bulk loader 步骤)

　　 尽量不要用kettle 的calculate 计算步骤，能用数据库本身的sql 就用sql ， 不能用sql 就尽量想办法用procedure ， 实在不行才是calculate 步骤。