公司上线了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
