zoukankan      html  css  js  c++  java
  • kettle 数据提取效率提升

    本文链接:https://blog.csdn.net/xpliruizhi123/article/details/54580850

           最近发现KETTLE抽数越来越慢,特别是增量INSERT/UPDATE的时候,速度已经达到了令人发指的地步(从一个400W数据规模的表中每天增量量抽取30W数据的TRASFORMATION 竟然要20个小时!!!!读取速率是5条/s......),这个情况是在我的KETTLE工具从3.2升级到7.0版本后发现的,(以前也慢,只是还能接受,升级之后已经到了不改不行的地步了),但是KETTLE是进步的,所以原因还是要从自身找起。

         目前为止我发现的导致KETTLE抽取数据慢有以下几个原因:

     A:SPOON 启动时候内存较小,在spoon.bat这个启动文件中,配置的有JVM的内存XMX,("%PENTAHO_DI_JAVA_OPTIONS%"=="" set PENTAHO_DI_JAVA_OPTIONS="-           Xms8192m" "-Xmx8192m" "-XX:MaxPermSize=4096m"),默认这个是256M,512M  256M, 其中Xms是指JVM初始分配的堆栈的内存,Xmx是指JVM分配的堆栈的内存 (JAVA代码能涉及到的存储数据变量的内存)最大是多少,所以XMS必须要<= XMX,XX:MaxPermSize,是指JVM给自己分配的非堆栈内存(供虚拟机程序自己开销)我的因 为是在服务器上跑,因此改成了8192M8192M4096M,这个改不能是无限的加大,需要考虑总的内存大小,一般来说网上参考是最大堆栈内存不超过总内存的3/8有的也说是 一半,总之得有个度。

    B:抽数的源数据库关键字段没有索引,以我这张表为例,我每天需要按照日期(data_update_date)从DB2增量抽取更新数据,但是这个字段没有建索引,因此也会导致抽数慢。

    C:抽数的源数据库关键字段索引在SPOON里面失效,给大家看两段SQL就知道了:

            SQL1:select TO_CHAR(TO_DATE(t_date,'YYYYMMDD')+1,'YYYYMMDD') from delta_table where t_name='~~~'

                      SELECT * FROM SAPCP1.ZCSSDH053 WHERE REPORT_CREATE_DATE >= ?

           SQL2:select    t_date   from delta_table where t_name='~~~'

                      SELECT * FROM SAPCP1.ZCSSDH053 WHERE REPORT_CREATE_DATE >  ?

          两段SQL执行的都是相同的数据提取过程,但是在REPORT_CREATE_DATE 字段建立索引的情况下,SQL1比SQL2快20倍。原因是用 > 号的时候,索引会失效,而用>=则不会。

          于是我在网上搜索了这种明明应该走 但是并没有走索引的情况(以下是粘贴的)
                                使用<> (有的时候单独的使用< 或者>的时候也有可能)
                                like的时候不能确定最前面的字符 也就是把’%_’的时候
                                单独使用复合索引的非前导列
                               表没有分析
                               字符类型不匹配 发生了显示的或者隐式的转换或者对索引列进行了运算
                                使用了 not in 或者 not exist
                               基于cbo时全表扫描代价小
                                b-tree索引is not null的时候会走,is not null的时候不会走 位图的时候都会 复合索引的时候 is not null会 is null时要看前导列

    D:目的地数据库表的索引太多,这个原因显而易见,因为插入数据的时候会重新更新索引表,索引太多,插入时候会变慢。

    E:插入流程中数据COMMIT过程太频繁,数据插入的COMMIT太频繁也是很影响效率的,,30W的数据提交300次和提交30次速度显然是不一样的,只要你的设置的内存能暂时容得下插入的数据,COMMIT可以尽量设高一点(kettle有限制不能超过50000)

    F:INSERT/UPDATE  过程与 表输入,这两个流程肯定是后者快很多,但是笔者在实际过程中会遇到一个问题就是,万一ETL抽数流程的某个环节发生了错误,导致ETL后面的流程DUMP掉,要么没插入要么部分插入,这样的话,肯定是没有更新关键字段的。(关键字段更新是放在所有流程最后一步),这样的话,当笔者解决掉这个问题重新启动流程,如果重头开始,对于INSERT/UPDATE字段没什么问题,数据重复会进行更新,但是对于表输入的话,就会有问题,昨天写入的数据已经存在了,这样不作处理肯定还会报错。KETTLE 7.0 解决了这个问题,在JOB层设计的时候提前设定好失败数据回滚的操作,在回滚的操作里面删掉已经插入的数据,这样的话用表输入就没有后顾之忧了。

    最后,30W数据进过以上优化时间从20个小时缩短到0.5个小时~~我暂时发现这些优化方式,各位高人有其他方法欢迎交流~~~!!!!
    ————————————————
    版权声明:本文为CSDN博主「xpliruizhi123」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
    原文链接:https://blog.csdn.net/xpliruizhi123/article/details/54580850

  • 相关阅读:
    Boost Log : Log record formatting
    Boost Log : Attributes
    PLSA的EM推导
    特征处理:一点经验
    海量推荐系统:mapreduce的方法
    操作系统之存储器管理
    maredit测试
    算法:链表
    c++特别要点:多态性与虚函数
    sizeof的用法与字节对齐
  • 原文地址:https://www.cnblogs.com/minong/p/11558489.html
Copyright © 2011-2022 走看看