为了确保查询效率，使Hbase不会有太多小文件(丢在磁盘上的menstore )，Hbase必须根据需要将这些小store file合并到相对较大的store file中，并将此过程压缩HBase主要存在两种类型的compaction:major compaction和major compaction。
major compaction的功能是将所有存储文件放在一起。 启动major compaction的可能条件是自动运行major_compact命令和majorcompact(API，区域服务器)。 相关参数： hbase.hregion.majoucompaction默认为24小时。h base.h region.major compaction.jetter的默认值为0.2，表示区域服务器同时运行h base.h region.major compaction.jetter参数的作用是使参数hbase.hregion.majoucompaction中定义的值浮动。 如果两个参数都是默认值24和0，2，则majorcompact最终浮动，minor compaction的运行机制更加复杂，由以下几个参数决定： h base.h store.compaction.min :的默认值为3，如果至少需要三个满足条件的store file，则minor compaction是第一个h base.h store.compaction 如果一次从minor compaction中最多选择10个store filehbase.h store.compaction.min.size， 文件大小小于此值的store file将始终添加到minor compaction的store file中，而n.max.size， 文件大小大于此值的store file始终表示minor compaction会按文件年龄对store file进行排序(minor compaction ) 如果从le中选择，并且文件的size小于其后的hbase.hstore.compaction.max个store file size之和乘以ratio，则该store file也会添加到minor中
1 )合并文件
2 )删除、过期、清除多余版本的数据
3 )提高数据读写效率
微操作器计算差异
1 ) Minor操作包含部分文件合并操作和minVersion=0，仅用于设置ttl过期版本的清理，不执行数据删除、多版本数据清理操作。
2 ) Major操作对Region下的HStore下的所有StoreFile执行合并操作，最终组织和合并单个文件。
从这个功能来看，Minor Compaction也不适合Major的工作。 因为部分数据清理可能没有意义。 例如，如果maxVersions=2，则也无法确定在较少的文件中是否只有两个版本的kv。
在什么情况下会发生Compaction呢？
参数名称配置项的默认值minfilestocompacthbase.h store.compaction threshold3maxfilestocompacthbase.h store.compaction.max 10 maxcocod incompactsizehbase.h store.compaction.min.sizememstoreflushsize决定在执行压缩检查时自动执行其合并。 memstore写入磁盘后，在shell命令compact、major_compact后、调用相应的API后，或由异步后台进程启动检查。 region服务运行此线程，其功能由CompactionChecker类实现。
CompactionChecker是RS上的工作线程(Chore )，运行周期由threadWakeFrequency指定，大小由h base.server.thread.wake frequency组成) 如果不更改参数，则CompactionChecker大约每2hrs、46mins和40sec运行一次。
首先，对于HRegion的每个HStor
e进行一次判断，needsCompaction()判断是否足够多的文件触发了Compaction的条件。条件为：HStore中StoreFiles的个数 – 正在执行Compacting的文件个数 > minFilesToCompact
操作：以最低优先级提交Compaction申请。
步骤1：选出待执行Compact的storefiles。由于在Store中的文件可能已经在进行Compacting，因此，这里取出未执行Compacting的文件，将其加入到Candidates中。
步骤2:执行compactSelection算法，在Candidates中选出需要进行compact的文件，并封装成CompactSelection对象当中。
1) 选出过期的store files。过滤minVersion=0，并且storefile.maxTimeStamp + store.ttl < now_timestamp。这意味着整个文件最大的时间戳的kv，都已经过期了，从而证明整个storefile都已经过期了。CompactSelection如果发现这样的storefile，会优先选择出来，作为Min然后提交给Store进行处理。
这部分具体操作被封装在ScanQueryMatcher下的ColumnTracker中，在StoreScanner的遍历过程，ScannerQueryMatcher负责kv的过滤。这里的ScanType包括(MAJOR_COMPACT,MINOR_COMPACT,USER_SCAN)，compact操作是对选出的文件执行一次标识ScanType为MAJOR_COMPACT或者MINOR_COMPACT类型的scan操作，然后将最终符合标准的kv存储在一个新的文件中。参考设置：根据应用的需求设置ttl，并且设置minVersions=0，根据selectCompation优选清理过期不保留版本的文件的策略，这样会使得这部分数据在CompactionChecker的周期内被清理。
误区：在CompactSplitThread有两个配置项
hbase.regionserver.thread.compaction.large：配置largeCompactions线程池的线程个数，默认个数为1。
hbase.regionserver.thread.compaction.small：配置smallCompactions线程池的线程个数，默认个数为1。
这两个线程池负责接收处理CR(CompactionRequest),这两个线程池不是根据CR来自于Major Compaction和Minor Compaction来进行区分，而是根据一个配置hbase.regionserver.thread.compaction.throttle的设置值(一般在hbase-site.xml没有该值的设置)，而是采用默认值2 * minFilesToCompact * memstoreFlushSize，如果cr需要处理的storefile文件的大小总和，大于throttle的值，则会提交到largeCompactions线程池进行处理，反之亦然。
参考设置：可以稍微调大一些largeCompactions和smallCompactions线程池内线程的个数，建议都设置成5。
2) 判断是否需要进行majorCompaction，这是很多判断条件的合成，其中最为重要的一个是
hbase.hregion.majorcompaction设置的值，也就是判断上次进行majorCompaction到当前的时间间隔，如果超过设置值，则满足一个条件，同时另外一个条件是compactSelection.getFilesToCompact().size() < this.maxFilesToCompact。
因此，通过设置hbase.hregion.majorcompaction = 0可以关闭CompactionChecke触发的major compaction，但是无法关闭用户调用级别的mc。
3) 过滤对于大文件进行Compaction操作。判断fileToCompact队列中的文件是否超过了maxCompactSize，如果超过，则过滤掉该文件，避免对于大文件进行compaction。
4) 如果确定Minor Compaction方式执行，会检查经过过滤过的fileToCompact的大小是否满足minFilesToCompact最低标准，如果不满足，忽略本次操作。确定执行的Minor Compaction的操作时，会使用一个smart算法，从filesToCompact当中选出匹配的storefiles。
具体算法为：
如果fileSizes[start] > Math.max(minCompactSize, (long)(sumSize[start+1]*r )，那么继续start++。这里r的含义是compaction比例，它有如下四个参数控制：
配置项 默认值 含义hbase.hstore.compaction.ratio 1.2F hbase.hstore.compaction.ratio.offpeak 5.0F 与下面两个参数联用hbase.offpeak.start.hour -1 设置hbase offpeak开始时间[0,23]hbase.offpeak.end.hour -1 设置hbase offpeak结束时间 [0,23]如果默认没有设置offpeak时间的话，那么完全按照hbase.hstore.compaction.ration来进行控制。如下图所示，如果filesSize[i]过大，超过后面8个文件总和*1.2，那么该文件被认为过大，而不纳入minor Compaction的范围。
这样做使得Compaction尽可能工作在最近刷入hdfs的小文件的合并，从而使得提高Compaction的执行效率。
5) 通过selectCompaction选出的文件，加入到filesCompacting队列中。
6) 创建compactionRequest，提交请求。
总结：
在大多数情况下，Major是发生在storefiles和filesToCompact文件个数相同，并且满足各种条件的前提下执行。这里进行几个参数配置的简介：
hbase.hregion.majorcompaction： 设置系统进行一次MajorCompaction的启动周期，如果设置为0，则系统不会主动触发MC过程。
hbase.hstore.compaction.max：设置执行Compaction(包括Major &Minor)的待合并文件的最大个数。默认值为10，如果超过该设置值，会对部分文件执行一次MinorCompaction，选择算法如Figure1。
hbase.hstore.compactionThreshold: 设置执行Compaction(Major && Minor)操作的阈值，默认是3，如果想降低过频繁的合并操作，可以稍微调大一点，对于HBase负载较重的系统，可以设置成5。
Compaction对于读写操作的影响
Compaction与Flush不同之处在于：Flush是针对一个Region整体执行操作，而Compaction操作是针对Region上的一个Store而言，因此，从逻辑上看，Flush操作粒度较大。这属于一个LSM存储模型最核心的设计：
1）Flush操作如果只选择某个Region的Store内的MemStore写入磁盘，而不是统一写入磁盘，那么HLog上key的一致性在Reigon不同ColumnFamily(Store)下的MemStore内就会有不一致的key区间。
如下图所示，我们假定该RegionServer上仅有一个Region，由于不同的Row是在列簇上有所区别，就会出现有些不同Store内占用的内存不一致的情况，这里会根据整体内存使用的情况，或者RS使用内存的情况来决定是否执行Flush操作。如果仅仅刷入使用内存较大的memstore，那么在使用的过程中，一是Scan操作在执行时就不够统一，二是在HLog Replayer还原Region内Memstore故障前的状态，只需根据Hlog的Flush_marker的标记位来执行Replay即可。
2）Compaction执行结束之后会生成临时文件，临时文件所在的hdfs位置如下：
/hbase-comp/comp_cluster/ffd87a50c3df3080183d4910d183d0ee/.tmp
ffd87a50c3df3080183d4910d183d0ee 是comp_cluster表格的Region名。临时文件的意义在于，在Compaction执行期间，对于原数据访问没有影响。Compaction执行合并操作生成的文件生效过程，需要对Store的写操作加锁，阻塞Store内的更新操作，直到更新Store的storeFiles完成为止。(注意，这个操作过程执行会影响到更新服务，但是影响不会太大)
3）对于读服务的影响，类似于Flush操作，也是通过ChangedReaderObserver为StoreScanner注册监听类来实现的。具体内容可以参考之前的”HBase Flush操作流程以及对读写服务的影响”。