业务导入的小文件数量过多，降低了compaction的效率：
经统计，业务有至少60%的文件是小于100B的小文件，且每天每台机器4小时内平均新增1万个文件，最高2万个。
大部分compaction的文件总大小仅几十KB。
根据分析的原因，进行了代码和配置的双重优化：
限制stripe和L0触发compact的最小大小，提升compact的效率：避免频繁进行KB级别大小的compaction；避免过小的stripe频繁参与compaction； 增加的compaction队列的管理：
增加队列监控，避免同一store重复加入队列浪费计算资源；增加队列长度限制，避免过多store等待compaction； 优化bulk load后触发compact的机制：避免重复加入到compaction队列；
Hbase-26249 Ameliorate compaction made by bulk-loading files配置合理的compact线程数量，避免compact占用过多的系统资源。
hbase.regionserver.thread.compaction.large
hbase.regionserver.thread.compaction.small配置合理的compact周期，及早触发compaction。（像业务这种小文件很多的模式，需要频繁触发compaction以减少文件数量，最终提升查询性能。但是同时需要避免compact线程长时间占用计算资源。）
hbase.server.compactchecker.interval.multiplier=400 效果
从文件数量指标和请求处理时间来衡量
文件数量bulkload前后变化 用户每天都会有bulk load任务，最后一轮优化前，文件数量在bulk load后都是仅减少一部分，整体呈累计上升趋势。
升级后，compact效率提高，文件数量首先有大幅下降。
经过bulk load后，文件数量恢复较快，整体文件数量稳定。
从单机文件数量增长指标看，升级前每天的导入任务单机短时间内约新增1万个文件，而升级后，单机无段时间内文件大量新增情况，整体每天新增约1200个文件。单机新增文件数量降低了88%。
并不是用户导入的新增文件减少了，而是compact从用户导入一小部分文件就开始高效执行，及时通过compact减少了文件数量，且compact压力不会在bulkload后的短时间内聚集，整体压力分散了。
同时整体文件数量增速减缓带来的好处是，单机的处理请求p99延迟从最高14000ms降低到120ms，降低了2个数量级。