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之道

相關文章