与hbase相同，kudu也需要定期进行compaction操作。kudu中的compaction操作有两种，一是合并delta文件。二是将一个tablet中的多个diskRowset进行重排。下面分别对这两者进行介绍。

之前在kudu的update操作中讲到，update操作的数据会先写入deltaMemStore再flush到deltaFile中。这样会导致deltaFile越来越多，进而影响scan的性能。这个与hbase类似。compaction操作会将所有deltaFile合并到baseData中，并将小于compaction这一刻时间戳的所有历史数据写入到undoFile中。也就是说compaction这一刻的数据成为了新的基准数据baseData，更老的数据在undoData中，并且不存在redoFile。这是kudu的compaction操作。

 

另外就是diskRowset之间的compaction。这个操作本质上不是为了减少文件数量，而是为了对内容进行排序重组，减少不同DRS之间key的overlap（重复），进而在检索的时候减少需要参与检索的DRS的数量。 另外真正删除待删除的数据行。

 

总结下来，在kudu中存在多个后台任务。
1.MemRowSets 刷写磁盘变为 DiskRowSets
2.MemDeltaStore 刷写磁盘变为 DeltaFiles
3.Delta Compaction: 将 Delta Store 部分数据合并到 Base Data 提升读性能
4.RowSet Compaction: 将多个 Disk Rowsets 进行 Compaction, 提升读写效率，物理删除数据行
这些任务会被后台线程调度。注意这些调度不是周期性或者被动触发，而是被工作线程主动调度，并且后台工作线程会一直处于工作状态。后台工作线程会一直处于工作状态，当插入操作比较频繁时，会更多时间片用于 MemRowSets 刷写磁盘变为 DiskRowSets，当插入操作比较少时候，会花更多时间片用于 Delta Compaction/RowSet Compaction，以提升长久的读取和插入性能。

与之相关的几个参数需要注意调整，以获取更好的性能。
maintenance_manager_num_threads  这个参数决定了Kudu后台对数据进行维护操作，如写入数据时的并发线程数。并发数越大，吞吐量越高，但对集群计算能力的要求也越高。默认值为1，表示Kudu会采用单线程操作；对于需要大量数据进行快速写入/删除的集群，可以设置更大的值。该值可以设置跟计算节点的数据磁盘数量和CPU核数有关，一般来说，建议设置为4以获取比较均衡的性能，最大不超过8。

kudu重启后需要做一些redo和undo操作，特别是需要重新组织(整理)数据，启动会非常慢。有两个参数特别重要：  
num_tablets_to_open_simultaneously    默认为1，调成 24
num_tablets_to_delete_simultaneously    默认为1，调成 24