用了幾次impala + kudu做大數(shù)據(jù)實時計算場景，一路踏坑過來，這里分享踏坑經(jīng)驗

• 一開始需要全量導(dǎo)入kudu，這時候我們先用sqoop把關(guān)系數(shù)據(jù)庫數(shù)據(jù)導(dǎo)入臨時表，再用impala從臨時表導(dǎo)入kudu目標(biāo)表

由于sqoop從關(guān)系型數(shù)據(jù)直接以parquet格式導(dǎo)入hive會有問題，這里默認(rèn)hive的表都是text格式；每次導(dǎo)完到臨時表，需要做invalidate metadata 表操作，不然后面直接導(dǎo)入kudu的時候會查不到數(shù)據(jù)

• 除了查詢，建議所有impala操作都在impala-shell而不在hue上面執(zhí)行
• impala并發(fā)寫入kudu的時候，數(shù)據(jù)量比較大的時候

這時候kudu配置參數(shù) --memory_limit_hard_bytes能大點就大點，因為kudu寫入首先保存再內(nèi)存里面，到一定閥值才溢寫到磁盤，這個是直接最能提高寫的方法；

當(dāng)然不是所有機(jī)器都有那么多資源，可以把--maintenance_manager_num_threads 這個參數(shù)稍微調(diào)大，需要調(diào)試，提高數(shù)據(jù)從內(nèi)存寫入磁盤的效率

• impala查詢kudu

首先所有表做完全量的etl操作，必須得執(zhí)行compute stats 表名，不然impala執(zhí)行sql生成的計劃執(zhí)行數(shù)評估的內(nèi)存不準(zhǔn)確，容易評估錯誤導(dǎo)致實際執(zhí)行不了

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

kudu針對大表要做好分區(qū)，最好range和hash一起使用，前提是主鍵列包含能hash的id，但range分區(qū)一定要做好，經(jīng)驗告訴我一般是基于時間；

查詢慢的sql，一般要拿出來；方便的話做下explain，看下kudu有沒有過濾部分?jǐn)?shù)據(jù)關(guān)鍵字kudu predicates；假如sql沒問題，那在impala-shell執(zhí)行這個sql，最后執(zhí)行summray命令，重點查看單點峰值內(nèi)存和時間比較大的點，對相關(guān)的表做優(yōu)化，解決數(shù)據(jù)傾斜問題

• kudu數(shù)據(jù)刪除

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

• 關(guān)于impala + kudu 和 impala + parquet

網(wǎng)上很多分析impala + kudu 要比 impala + parquet 優(yōu)越很多；誰信誰XB；

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

hive基于hdfs，hdfs已經(jīng)提供一套較為完善的存儲機(jī)制，底層數(shù)據(jù)和文件操作便利；安全性，可擴(kuò)展性都比kudu強(qiáng)很多，最重要parquet + impala效率要比kudu高，數(shù)倉首選是它

kudu最大優(yōu)勢是能做類似關(guān)系型數(shù)據(jù)庫一樣的操作，insert, update, delete，這樣熱點的數(shù)據(jù)可以存儲在kudu里面并隨時做更新

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

同步工具我們這里使用streamsets，一個拖拉拽的工具，非常好用；但內(nèi)存使用率高，通過jconsole我們發(fā)現(xiàn)，所有任務(wù)同時啟動；JVM新生代的內(nèi)容幾乎都跑到老年代了，GC沒來的及，就內(nèi)存溢出了；后面單獨拿幾臺服務(wù)器出來做這個ETL工具，jvm配置G1垃圾回收器