原创文章，转载请注明原作地址：http://www.jianshu.com/p/895ab6511819
在介绍HBase Compaction之前，我们先来看一下HBase是如何存储和操作数据。
HBase数据存储
如上图所示，HRegionServer负责打开region，并创建对应的HRegion实例。当HRegion打开之后，它会为每个表的HColumnFamily创建一Store实例，ColumnFamily是用户在创建表时定义好的，ColumnFamily在每个region中和Store实例一一对应。每个Store实例包含一个或者多个StoreFile实例，StoreFile是对实际存储数据文件HFile的轻量级封装。每个Store对应一个MemStore（也就是写内存）。一个HRegionServer共享一个HLog实例。
当我们不停地往HBase中写入数据，也就是往MemStore写入数据，HBase会检查MemStore是否达到了需要刷写到磁盘的阈值（更多关于MemStore刷写的信息，可以参考HBase Reference Guide关于MemStore的介绍）。如果达到刷写的条件，MemStore中的记录就会被刷写到磁盘，形成一个新的StoreFile。可想而知，随着MemStore的不断刷写，会形成越来越多的磁盘文件。然而，对于HBase来说，当每个HStore仅包含一个文件时，才会达到最佳的读效率。因此HBase会通过合并已有的HFile来减少每次读数据的磁盘寻道时间，从而提高读速度，这个文件合并过程就称为Compaction。在这里需要说明的是，显然磁盘IO也是有代价的，如果使用不慎的话，不停地重写数据可能会导致网络和磁盘过载。换句话说，compaction其实就是用当前更高的磁盘IO来换取将来更低的磁盘寻道时间。因此，何时执行compaction，其实是一个相当复杂的决策。
HBase的compaction分为minor和major两种。minor合并负责将几个小文件合并成一个较大的文件；major合并是将一个HStore中的所有文件合并成一个文件。每次触发compact检查。系统会自动决定执行哪一种compaction（合并）。有三种情况会触发compact检查：
- MemStore被刷写到磁盘；
- 用户执行shell命令compact、major_compact或者调用了相应的API；
- HBase后台线程周期性触发检查。
除非是用户使用shell命令major_compact或者调用了majorCompact() API（这种情况会强制HBase执行major合并），在其他的触发情况下，HBase服务器会首先检查上次运行到现在是否达到一个指定的时限。如果没有达到这个时限，系统会选择执行minor合并，接着检查是否满足minor合并的条件。
major合并中会删除那些被标记为删除的数据、超过TTL（time-to-live）时限的数据，以及超过了版本数量限制的数据，将HStore中所有的HFile重写成一个HFile。如此多的工作量，理所当然地，major合并会耗费更多的资源，合并进行时也会影响HBase的响应时间。在HBase 0.96之前，默认每天对region做一次major compact，现在这个周期被改成了7天。然而，因为major compact可能导致某台server短时间内无法响应客户端的请求，如果无法容忍这种情况的话，可以关闭自动major compact，改成在请求低谷期手动触发这一操作。
minor合并的关键是，要如何挑选那些被合并的小文件？0.96版本之前，HBase的合并策略只有一个RatioBasedCompactionPolicy。这个策略中有三个重要参数：首先是hbase.hstore. compaction.min. size和hbase.hstore. compaction.max. size，在minor合并中，所有大小超过max. size的文件都会被排除在外，而min. size其实是一个阈值，minor合并会尽可能多地包括那些文件大小低于min. size的文件；在一次minor合并中，合并的文件数量最多不能超过hbase.hstore. compaction.max。另外，这个策略选择需要合并的文件时，总是优先选择较老的文件，也就意味着，沿着时间轴从最老的文件开始扫描，HBase会选择合并它扫描到的第一个满足合并策略的文件集合。
然而，实际操作中发现RatioBasedCompactionPolicy的表现并不好，因为这个策略假设越老的文件大小越大，而实际情况并不是这样，比如bulkLoad导入的新文件大小就很可能大于旧文件。于是，之后HBase加入了一个新策略ExploringCompactionPolicy。在这个策略中，HBase不是选择第一个符合合并策略的文件集合，而是考虑了所有符合要求的文件集合，并从中选择文件数量最多的集合（当有多个这样的文件集合时，选择总文件大小最小的那个集合）。这样导致的影响是，HBase总是选择合并会为IO带来最佳改善的文件集合。
随着compaction的进行，当所有文件中最大的那个超过了配置的最大存储文件大小，又会触发region拆分（如果region拆分没有被禁止的话）。
参考链接：
http://blog.cloudera.com/blog/2013/12/what-are-hbase-compactions/
https://hbase.apache.org/book.html#compaction
《HBase权威指南》
