Kettle Table Exists控制元件優化

weixin_34208283發表於2018-02-12

一、背景

    本文是kettle優化的系列文章中的其中一篇。最近在分析一些跑的比較慢的Job,發現一個很詭異的現象:同一個Table Exists控制元件,有的跑的很快、有的很慢,最慢的甚至30分鐘左右。經過進一步分析,瞭解到在判斷hive資料庫時,當表的資料量很大或檢視的查詢邏輯非常複雜,控制元件呼叫就會變得非常耗時。

   初步想法是控制元件在執行時,可能是資料庫連線或查詢資料的TEST SQL有問題,導致對大量資料表的判斷沒有進行優化。為了驗證這一想法並進行徹底的優化,只能通過看原始碼實現方式。

二、準備工作

    1、下載Kettle原始碼

  從githup上下載kettle程式碼並checkout到和自己kettle版本對應的分支上:

  git clone git@github.com:pentaho/pentaho-kettle.git

  git checkout 6.1.0.1-R

    2、下載big-data-plugin原始碼,big-data-plugin是kettle大資料相關的元件     

   git clone git@github.com:pentaho/big-data-plugin.git

   git checkout 6.1.0.1-R

3、前兩步下載的專案匯入到Eclipse

三、程式碼分析

    Table Exists控制元件的實現類是 pentaho-kettle專案中的JobEntryTableExists,執行時執行execute方法,該方法首先獲得Database物件、資料庫連線,然後呼叫Database的checkTableExists方法,該方法就是用來判斷資料庫中是否存在指定的表。

    checkTableExists根據實際的資料庫例項,設定特定資料庫的SQL,然後執行該sql,基於執行結果判斷表是否存在,如果表不存在會異常。

    Mysql執行的sql:

10607688-8d673800900302f9

Oracle執行的sql:

10607688-f19d4361adf4568e

可以看到不同的資料庫,查詢sql是不一樣的,這就可以根據資料庫的特點,以最快的效率返回查詢結果。

    Hive使用的是預設的Sql:

hive中執行上面的查詢sql時,如果表或檢視的資料量比較大,就會起MR任務,啟動和銷燬MR任務都會浪費時間,這就導致了查詢比較慢。

四、程式碼優化

    經過上面的分析,已經能定位到問題,解決方案也很簡單,針對hive資料庫實現特定的getSQLTableExists方法,最大化利用hive特性、以最優方式查詢資料。

    在pentaho-big-data-legacy專案的Hive2DatabaseMeta類增加以下程式碼:

10607688-ede42aece04f4e22

編譯big-data-plugin專案下的legacy模組,編譯後的jar包放到$KETTLE_HOME/plugins/pentaho-big-data-plugin目錄下

五、總結

    遇到問題首先要分析詳細的Log,找到問題,根據以往經驗瞭解大致原因,然後為了進一步找到問題根源,最好仔細看原始碼、然後優化

本文首發於公眾號:data之道

相關文章