Kudu表結構設計最佳實踐

不允許更改創(chuàng)建后的分區(qū)表,但可以添加或刪除range分區(qū)
分區(qū)方式:hash分區(qū),range分區(qū)以及組合分區(qū)
根據自身業(yè)務場景,選擇合適的分區(qū)方式,讓讀與寫操作在所有tablet server上均勻分布
根據應用查詢的語句,設計合理的主鍵以及分區(qū),保證讀取數(shù)據時掃描最小的數(shù)據集
分區(qū)數(shù)量的設置,根據官方文檔,每個分區(qū)的大小盡量控制在4G左右(單個tablet server最大存儲8T/管理的tablets數(shù)量最大2000個≈4G),如果表數(shù)據量未來估算在40G左右,那么分區(qū)數(shù)量可以設置10個

Impala與Kudu Client場景選擇最佳實踐

就查詢來說,Impala的查詢速度要快于Kudu Client的scan數(shù)據掃描,建議使用Impala
KuduClient原聲API中update/delete/upsert只能根據主鍵操作,如果需要其他條件則需要查詢一下,拿到主鍵再進行操作,所以不如impala寫sql方便,如果同時使用impala和kuduclient最好做資源隔離

盡量采用MANUAL_FLUSH,性能最好,如果有寫入Kudu錯誤,flush()函數(shù)會拋出異常
在性能要求不高的情況下,AUTO_FLUSH_SYNC也是一個很好的選擇
僅僅在測試環(huán)境下使用 AUTO_FLUSH_BACKGROUND, 不考慮異常處理時候代碼可以很簡單, 性能也很好. 在生產環(huán)境下不推薦使用的原因是: 插入數(shù)據可能會是亂序的, 一旦考慮捕獲異常代碼就很冗長

時鐘服務NTP配置不合理,會導致Kudu服務直接崩潰,建議根據官方的推薦來配置NTP,另外可以通過修改參數(shù)max_clock_sync_error_usec值,來提高Kudu對時間偏差的容忍程度
在Impala中對Kudu表進行alter table A rename to B，只會更改impala的元數(shù)據，而不會更改任何Kudu的元數(shù)據，可以通過先修改Impala元數(shù)據alter table A rename to B 后，再修改Kudu元數(shù)據alter table A set TBLPROPERTIES（’kudu.table_name’=’B’）
沒有rebalance功能,需要手動做balance
在Kudu1.6.0之前，如果tablet server的某個磁盤壞了，那么整個tablet server就要重新format了，如果你的集群版本大于等于1.6.0并且損壞的盤并非WAL/Meta盤，那么你可以通過kusu fs update_dirs
關于range分區(qū)踩坑:一

kudu表信息.png

再看一下設置range分區(qū)信息,注意這里只設置了aa-cc的range分區(qū)

range分區(qū)信息