一開始需要全量導入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垃圾回收器
本文分享自微信公衆號 - 大數據技術與架構(import_bigdata)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。