• 一開始需要全量匯入kudu，這時候我們先用sqoop把關係資料庫資料匯入臨時表，再用impala從臨時表匯入kudu目標表

由於sqoop從關係型資料直接以parquet格式匯入hive會有問題，這裡預設hive的表都是text格式；每次導完到臨時表，需要做invalidate metadata 表操作，不然後面直接匯入kudu的時候會查不到資料.

• 除了查詢，建議所有impala操作都在impala-shell而不在hue上面執行

• impala併發寫入kudu的時候，資料量比較大的時候

這時候kudu配置引數 --memory_limit_hard_bytes能大點就大點，因為kudu寫入首先儲存再記憶體裡面，到一定閥值才溢寫到磁碟，這個是直接最能提高寫的方法；

當然不是所有機器都有那麼多資源，可以把
 
--maintenance_manager_num_threads 這個引數稍微調大，需要除錯，提高資料從記憶體寫入磁碟的效率

• impala查詢kudu

首先所有表做完全量的etl操作，必須得執行compute stats 表名，不然impala執行sql生成的計劃執行數評估的記憶體不準確，容易評估錯誤導致實際執行不了

kudu表最好不要做任何壓縮，保證原始掃描效能發揮最好；假如對查詢效能要求比儲存要求高的話；大部分企業對實時查詢效率要求高，而且儲存成本畢竟低；

kudu針對大表要做好分割槽，最好range和hash一起使用，前提是主鍵列包含能hash的id，但range分割槽一定要做好，經驗告訴我一般是基於時間；

查詢慢的sql，一般要拿出來；方便的話做下explain，看下kudu有沒有過濾部分資料關鍵字kudu predicates；假如sql沒問題，那在impala
 
-shell執行這個sql，最後執行summray命令，重點檢視單點峰值記憶體和時間比較大的點，對相關的表做優化，解決資料傾斜問題

• kudu資料刪除

大表不要delete，不要猶豫直接drop，在create吧；磁碟空間會釋放的

• 關於impala + kudu 和 impala + parquet

網上很多分析impala + kudu 要比 impala + parquet 優越很多；誰信誰XB；

首先兩個解決的場景不一樣，kudu一般解決實時，hive解決的是離線（通常是T + 1或者 T -1）

hive基於hdfs，hdfs已經提供一套較為完善的儲存機制，底層資料和檔案操作便利；安全性，可擴充套件性都比kudu強很多，最重要parquet 
 
+ impala效率要比kudu高，數倉首選是它

kudu最大優勢是能做類似關係型資料庫一樣的操作，insert, update, delete，這樣熱點的資料可以儲存在kudu裡面並隨時做更新

• 最後談到的實時同步工具

同步工具我們這裡使用streamsets，一個拖拉拽的工具，非常好用；但記憶體使用率高，通過jconsole我們發現，所有任務同時啟動；JVM新生代的內容幾乎都跑到老年代了，GC沒來的及，就記憶體溢位了；後面單獨拿幾臺伺服器出來做這個ETL工具，jvm配置G1垃圾回收器

轉載：https://blog.csdn.net/u013411339/article/details/115343647