1. 为什么进行compaction
kudu中的compaction主要针对磁盘中的DiskRowset进行合并，DiskRowset包含3部分数据：BaseData、RedoLog、UndoLog，对应的有下面3种compaction形式：
- MergeCompaction：仅对BaseData合并
- MinorDeltaCompaction：对RedoLog进行合并
- MajorDeltaCompaction：对UndoLog、BaseData、RedoLog进行合并，删除历史版本数据释放磁盘空间
2. compaction如何触发
kudu tablet有一个maintenance_scheduler线程负责针对当前系统状况来对后台维护任务进行调度。tablet会创建MaintenanceOp 对象，维护线程每250ms轮询一次上述对象，并决定执行哪些任务。
3. compaction策略
compaction会消耗当前的机器资源，但是可以提升后续的服务性能，所以需要在当前资源消耗和后续服务性能之间取得平衡。
3.1. 服务开销
为了衡量kudu的读写时间开销，引入高度和宽度，这两个概念：
假设在一个tablet中有如下A - F 6 个rowset文件，文件包含1 - 5 这5个key：
1 2 3 4 5
|--A--||-B--||--C--||---D----|
|--------------E-------------|
|-F--|
**宽度：**E首尾距离为5， 所以E的宽度为5， 同理D的宽度为2
**高度：**对于4这个key，可能存在于D、E、F这3个文件，所以高度为3， 同理 2 的高度为2
插入操作：
插入操作需要先检查主键是否存在，kudu将每个文件包含的起始结束键存储在树中，通过检索可以快速找到可能包含当前pk的文件。按照如下公式计算时间开销：
n = 可能包含当前pk的文件个数 即 高度
B = 上述文件BloomFilter误报概率
C_bf = BloomFilter校验时间开销
C_pk = 单文件pk查找时间开销
开销为 Cost = n * C_bf + n * B * C_pk = n * (C_bf + B*C_pk)
随机读取：
和插入类似
短扫描：
扫描不使用BloomFilter，且磁盘读取时间较短，所以开销为Cost = n*C_pk
长扫描：
长扫描需要读取大量数据
S = 需要读取的数据
B = 磁盘带宽
开销为 Cost = n * C_pk + S / B
3.2. 合并策略
通过3.1的结果可以得出结论：
- 插入，随机读，短扫描 这3个场景下，减少 n（高度）可以获得最大收益，也就是将有主键交叉的文件合并
- 对于长扫描，一次寻道时间为10ms左右，读取10M文件需要100ms左右，可以通过合并文件来提升顺序性能，但相对于1中的线性提升，单个文件到达一定大小后，继续合并所节省的寻道时间占比越来越低，在OLAP场景下更为突出
理论上像HBase一样将所有文件合并成一个可以获得最大长扫描性能，但会带来较大的写放大（数据反复合并*副本数 ）和性能波动，所以kudu选择将Memstore限制在64M，DiskRowSet限制在32M，合并IO限制在128M，且只对有主键交叉的文件进行合并，既保证了后续读写性能，又可以在后台不断执行合并而不会对当前读写有太大影响。
Tips:因为kudu合并有主键交叉的文件，可以使用递增主键来避免合并，提升写入性能。
3.3 文件选择策略
如果有多个待合并的文件，kudu如何进行文件选择呢？ 上面提到合并的目标是降低tablet的高度，tablet的高度是因为有多个文件主键交叉导致的，所以如果一个文件的主键分布太广（即宽度过大），就会导致其与其他文件主键交叉的概率增加，所以应该优先合并宽度大的文件。
假设在如下文件中选取3个文件进行合并：
可以看到合并ABD高度减少到2 ，宽度减少到40， 合并BDE高度减少到2，宽度减少到35，很明显BDE是更好的合并方式。
Kudu的合并策略也有一些弊端，如果持续缓慢的向kudu写入主键递增的数据，因为Kudu 2分钟flush的策略，就会导致磁盘上有很多小文件，却又一直不会合并，导致该表性能下降。https://community.cloudera.com/t5/Interactive-Short-cycle-SQL/kudu-compaction-did-not-run/td-p/84298这个问题在1.9版本修复，感兴趣看下设计文档https://docs.google.com/document/d/1yTfxt0_2p5EfIjCnjJCt3o-nB9xk-Kl2O8yKTA1LQrQ/edit#