上一篇文章主要基于工作流程对compaction进行了介绍，同时说明了compaction的核心作用是通过合并大量小文件为一个大文件来减少hfile的总数量，进而保证读延迟的稳定。合并文件首先是读出所有小文件的KVs，再写入同一个大文件，这个过程会带来严重的IO压力和带宽压力，对整个系统的读请求和写请求带来不同程度的影响。

alter ’table1’ , CONFIGURATION => {‘hbase.store.engine.class’ => ‘org.apache.hadoop.hbase.regionserver.StripStoreEngine’, … } 

上述两方面的调整为compaction的改进和优化提供了最基本的保障，同时提出了一个非常重要的理念：compaction到底选择什么样的策略需要根据不同的业务场景、不同数据集特征进行确定。那接下来就根据不同的应用场景介绍几种不同的compaction策略。

在介绍具体的compaction策略之前，还是有必要对优化compaction的共性特征进行提取，总结起来有如下几个方面：

3. 小region更有利于compaction：大region会生成大量文件，不利于compaction；相反，小region只会生成少量文件，这些文件合并不会引起很大的IO放大

接下来就介绍几个典型的compaction策略以及其适应的应用场景：

FIFO Compaction（HBASE-14468）

FIFO Compaction策略主要参考了rocksdb的实现，它会选择那些过期的数据文件，即该文件内所有数据都已经过期。因此，对应业务的列族必须设置TTL，否则肯定不适合该策略。需要注意的是，该策略只做这么一件事情：收集所有已经过期的文件并删除。这样的应用场景主要包括：

1. 大量短时间存储的原始数据，比如推荐业务，上层业务只需要最近时间内用户的行为特征，利用这些行为特征进行聚合为用户进行推荐。再比如Nginx日志，用户只需要存储最近几天的日志，方便查询某个用户最近一段时间的操作行为等等

HTableDescriptor desc = new HTableDescriptor(tableName);
    desc.setConfiguration(DefaultStoreEngine.DEFAULT_COMPACTION_POLICY_CLASS_KEY, 
      FIFOCompactionPolicy.class.getName());

HColumnDescriptor desc = new HColumnDescriptor(family);
    desc.setConfiguration(DefaultStoreEngine.DEFAULT_COMPACTION_POLICY_CLASS_KEY, 
      FIFOCompactionPolicy.class.getName());

Tier-Based Compaction（HBASE-7055）（HBASE-14477）

之前所讲到的所有‘文件选取策略’实际上都不够灵活，基本上没有考虑到热点数据的情况。然而现实业务中，有很大比例的业务都存在明显的热点数据，而其中最常见的情况是：最近写入到的数据总是最有可能被访问到，而老数据被访问到的频率就相对比较低。按照之前的文件选择策略，并没有对新文件和老文件进行一定的‘区别对待’，每次compaction都有可能会有很多老文件参与合并，这必然会影响compaction效率，却对降低读延迟没有太大的帮助。

针对这种情况，HBase社区借鉴Facebook HBase分支的解决方案，引入了Tier-Based Compaction。这种方案会根据候选文件的新老程度将其分为多个不同的等级，每个等级都有对应等级的参数，比如参数Compation Ratio，表示该等级文件选择时的选择几率，Ratio越大，该等级的文件越有可能被选中参与Compaction。而等级数、每个等级参数都可以通过CF属性在线更新。

可见，Tier-Based Compaction方案通过引入时间等级和Compaction Ratio等概念，使得Compaction更加灵活，不同业务场景只需要调整参数就可以达到更好的Compaction效率。目前HBase计划在2.0.0版本发布基于时间划分等级的实现方式－Date Tierd Compaction Policy，后续我们也重点基于该方案进行介绍。

该方案的具体实现思路，HBase更多地参考了Cassandra的实现方案：基于时间窗的时间概念。如下图所示，时间窗的大小可以进行配置，其中参数base_time_seconds代表初始化时间窗的大小，默认为1h，表示最近一小时内flush的文件数据都会落入这个时间窗内，所有想读到最近一小时数据请求只需要读取这个时间窗内的文件即可。后面的时间窗窗口会越来越大，另一个参数max_age_days表示比其更老的文件不会参与compaction。

上图所示，时间窗随着时间推移朝右移动，图一中没有任何时间窗包含4个（可以通过参数min_thresold配置）文件，因此compaction不会被触发。随着时间推移来到图二所示状态，此时就有一个时间窗包含了4个HFile文件，compaction就会被触发，这四个文件就会被合并为一个大文件。

对比上文说到的分级策略以及Compaction Ratio参数，Cassandra的实现方案中通过设置多个时间窗来实现分级，时间窗的窗口大小类似于Compaction Ratio参数的作用，可以通过调整时间窗的大小来调整不同时间窗文件选择的优先级，比如可以将最右边的时间窗窗口调大，那新文件被选择参与Compaction的概率就会大大增加。然而，这个方案里面并没有类似于当前HBase中的Major Compaction策略来实现过期文件清理的功能，只能借助于TTL来主动清理过期的文件，比如这个文件中所有数据都过期了，就可以将这个文件清理掉。

Stripe Compaction （HBASE-7667）

通常情况下，major compaction都是无法绕过的，很多业务都会执行delete/update操作，并设置TTL和Version，这样就需要通过执行major compaction清理被删除的数据以及过期版本数据、过期TTL数据。然而，接触过HBase的童鞋都知道，major compaction是一个特别昂贵的操作，会消耗大量系统资源，而且执行一次可能会持续几个小时，严重影响业务应用。因此，一般线上都会选择关闭major compaction自动触发，而是选择在业务低峰期的时候手动触发。为了彻底消除major compaction所带来的影响，hbase社区提出了strip compaction方案。

Level Compaction

此时，社区开发者将目光转向了leveldb的compaction策略：level compaction。level compaction设计思路是将store中的所有数据划分为很多层，每一层都会有一部分数据，如下图所示：

Stripe Compaction 实现

虽然原生的level compaction并不适用于HBase，但是这种compaction的思想却激发了HBaser的灵感，再结合之前提到的小region策略，就形成了本节的主角－stripe compaction。同level compaction相同，stripe compaction会将整个store中的文件按照Key划分为多个Range，在这里称为stripe，stripe的数量可以通过参数设定，相邻的stripe之间key不会重合。实际上在概念上来看这个stripe类似于sub-region的概念，即将一个大region切分成了很多小的sub-region。

截至目前，我们一直都在关注Compaction带来的IO放大效应，然而在某些情况下Compaction还会因为大量消耗带宽资源从而严重影响其他业务。为什么Compaction会大量消耗带宽资源呢？主要有两点原因：

Compaction BandWidth Limit

写在最后