公司上線了kudu有段時間了，主要有兩個用途：
1.實時落地流量日誌以便滿足靈活的olap查詢
2.解析mysql binlog日誌，生成業務庫實時映射表
最近發現有張業務庫的實時映射表數據查詢起來非常慢，隨着不斷解析插入binlog數據，這張表查詢起來越來越慢；
由於kudu集羣的內存和cpu使用率都不高，就沒當回事，解決辦法也比較簡單粗暴：直接將kudu中的映射表的binlog重新同步一遍；
剛做完同步的，業務庫的映射表查詢起來非常快；隨着同步的映射表越來越多，這種情況也越來越多，需要仔細查查到底什麼原因造成的；找了一張查詢很慢的表，查看了下它的block，果不其然，有問題
[root@hadoop]# kudu fs list -fs_data_dirs=/data/kudu/tserver -fs_wal_dir=/data/kudu/tserver -tablet_id=7961429223cb4cae9b70d4c5e9536f77|wc -l
I0331 08:35:37.198873 4116 fs_manager.cc:260] Metadata directory not provided
日誌省略。。。。。
uuid: "eebd881b3639496c9fa66e06ba1d4ed0"
format_stamp: "Formatted at 2020-03-24 10:28:16 on hadoop"
116771
這張表的其中一個tablet的block居然達到116771個，而這張表也不過才200w數據，也就是說過多小的block導致了這張表查詢慢；奇怪的是爲什麼沒有發生compact；
然後查了下這張表所在tablet server 的Metrics
{
"name": "compact_rs_duration",
"total_count": 0,
"min": 0,
"mean": 0,
"percentile_75": 0,
"percentile_95": 0,
"percentile_99": 0,
"percentile_99_9": 0,
"percentile_99_99": 0,
"max": 0,
"total_sum": 0
}
結果顯示這張表沒有發生一次compact，各種調參也不起作用；查了下資料，出現這個問題的原因是：老版本的kudu，無法合併已經刷新到硬盤的小rowset~~~;
在kudu1.9版本以後已經解決了這個問題，而我們線上的kudu版本比較老是1.7，怎麼解決？
kudu將數據刷到硬盤主要是由兩個參數影響
--flush_threshold_mb=1024
--flush_threshold_secs=120
“--flush_threshold_mb=1024”當memRowSet的數據達到1024m時，將數據刷到硬盤；
“--flush_threshold_secs=120”每120s將memRowSet的數據刷到硬盤，當滿足兩者任何一個條件，就會將內存中的數據刷到硬盤；
而造成之前rowset過多的原因就是每120s刷一次數據；既然這樣那我們加大刷數據的間隔，這樣小文件生成的頻率就會下降，那隨之而來的就是內存使用率上升；
所以做了如下調整
--unlock_unsafe_flags=true
--unlock_experimental_flags=true
--flush_threshold_secs=86400
集羣重啓後內存使用率並沒有升高多少，畢竟小表數據量本身就少，佔用不了多少內存；如果升高的有點多，可以適當調小“flush_threshold_mb”；雖然這樣做不能根本上解決這個問題，但能很大程度減少小文件快過多的問題；對於之前已經出現問題的表，只能進行重建
參考：
https://community.cloudera.com/t5/Support-Questions/kudu-compaction-did-not-run/td-p/84298