Hbase的MinorCompact过程解析及参数调优

1.首先说一下Compact的作用：

在Memstore超过一定的阈值的时候，就要新开一个进程将Memstore flush到storefile中，新的Memstore继续写入接受到的数据，当storefile越来越多时，就会降低读的性能，为了提高读的性能，可以对这些storefile进行compact操作，形多个storefile合并成一个大的storefile，那么compact就需要对HBase的数据进行多次的重新读写，这将产生大量的IO操作，所以Compact操作就是以IO操作来换取后面读的性能。

2.Compact的两种方式及区别：

<1>、Minor：

Minor操作只用来做部分文件的合并操作以及包括minVersion=0并且设置ttl的过期版本清理，不做任何删除数据、多版本数据的清理工作。

<2>、Major：

Major操作是对Region下的Store下的所有StoreFile执行合并操作，最终的结果是整理合并出一个文件。

一般情况下都是做Minor合并，Major不少集群都是禁止，然后在集群负载较小时，进行手动Major合并，在企业中，一般配置了

hbase.hregion.majorcompaction

major Compaction之间的时间，以毫秒表示。设置为 0 可禁用基于时间的自动重要压缩。用户请求的和基于大小的主要压缩将仍然运行
默认时间7天

既然Major合并是把所有HFile都合并成一个文件，可想对集群负载不可小觑。

<3>、Minor触发条件

Minor则只会选择数个HFile文件compact为一个HFile，minor的过程一般较快，而且IO相对较低。在日常任务时间，都会禁止major操作，只在空闲的时段定时执行(因为太占用集群资源)。

Compact的触发条件：
在源码中有这么一段函数：
public boolean needs Compaction(final Collection storeFiles, final List filesCompacting) {
//store下的storefile的数量减去正在compact的storefile数量
int numCandidates = storeFiles.size() - filesCompacting.size();
//如果相减的值大于等于3时就表示需要做compact
return numCandidates >= comConf.getMinFilesToCompact();//hbase.hstore.compaction.min=3
表示至少需要3个满足条件的store file时，minor compaction才会启动
}
如果返回true，就需要做minor，如果返回false，就进一步判断是否需要做major，主要是查看一下是否太久没有做compact。

<4>具体的判断过程：

	<1>、获得compact时间间隔。hbase.hregion.majorcompaction（默认7天）为base基准时间，hbase.hregion.majorcompaction.jitter（默认5.0）为jitter，
	公式base +jitter - Math.round(2 * jitter * randomNum) 计算出一个会每次自动抖动的数值作为majorcompact的时间间隔。
	之所以要一个自动抖动，就是避免在HRegionServer重启的时候大量的major compact出现造成大量的IO。

	<2>、所有storefile最老（时间戳最小）的那个storefile的时间间隔大于这个majorcompact的时间间隔，则执行major compact。
	另外如果HRegion只有一个storefile，并且这个storefile的所有KeyValue的时间戳都没有超过TTL，则表示无须进行major compact，会跳过这次major compact。

第一个条件是异步的操作compact，第二个条件是同步操作compact

MinorCompact的过程：

当确定为需要MinorCompact时，便开始storefile的合并过程。

1、选出待执行Compact的storefiles。由于在Store中的文件可能已经在进行Compacting，因此，这里取出未执行Compacting的文件，将其加入到Candidates（候选）中。

2、执行compactSelection算法，在Candidates中选出需要进行compact的文件，并封装成CompactSelection对象当中（这里面还是很复杂的）。

	这一步主要是过滤掉过期的storefiles。过滤minVersion=0，并且storefile.maxTimeStamp+ store.ttl < now_timestamp。
	这意味着整个文件最大的时间戳的kv，都已经过期了，从而证明整个storefile都已经过期了。
	CompactSelection如果发现这样的storefile，会优先选择出来，作为Min然后提交给Store进行处理。

3、判断fileToCompact队列中的文件是否超过了maxCompactSize，如果超过，则过滤掉该文件，避免对于大文件进行compaction。（这一步可以忽略，因为默认maxCompactSize为Long.MaxValue，很少有文件大于这个值。

4、如果确定Minor Compaction方式执行，会检查经过过滤过的fileToCompact的大小是否满足minFilesToCompact最低标准（默认为3，即超过3个storefile文件则启动合并），如果不满足，忽略本次操作。确定执行的Minor Compaction的操作时，会使用一个smart算法，从filesToCompact当中选出匹配的storefiles。

hbase会将队列中的storefile 按照文件年龄排序（older to younger），minor
compaction总是从older store file开始选择，

（1）如果该文件小于hbase.hstore.compaction.min.size（为memestoreFlushSize）则一定会被添加到合并队列中。
（2）如果该文件大于hbase.hstore.compaction.max.size（Long.MAX_VALUE）则一定会被排除，这个值很大，一般不会有。

（3）如果该文件的size 小于它后面hbase.hstore.compaction.max（默认为10） 个store file size之和乘以一个ratio（hbase.hstore.compaction.ratio，默认为1.2），则该storefile
也将加入到minor compaction 中。当然，如果他后面不足10个文件，那么也就是取他后面几个文件总和*ratio了。

如此，最终选择下来的文件就将进入Minor合并

---

参数调优

1).hbase.hstore.compaction.min默认值 3，

一个列族下的HFile数量超过该值就会触发Minor Compaction，这个参数默认值小了，一般情况下建议调大到5~10之间，注意相应调整下一个参数。（旧版本中该参数是hbase.hstore.compactionthreshold）

2).hbase.hstore.compaction.max默认值 10，

一次Minor Compaction最多合并的HFile文件数量，这个参数基本控制着一次压缩即Compaction的耗时。这个参数要比上一个参数hbase.hstore.compaction.min值大，通常是其2~3倍。

3).hbase.regionserver.thread.compaction.throttle

HBase RS内部设计了两个线程池：large compactions与small compactions，用来分开处理Compaction操作，这个参数就是控制一个Compaction应该交由哪一个线程池处理，默认值
2 * hbase.hstore.compaction.max * hbase.hregion.memstore.flush.size，即210128M=2.5G，如果待合并文件的总大小大于该值则交给large compactions线程池处理，否则交给small compactions线程池处理。一般建议不调整或稍微调大。

4).hbase.regionserver.thread.compaction.small默认值 1

RS中small compactions线程池的大小。一般建议调整到2~5，不建议调太大，否则可能会消费过多的服务端资源得不偿失。

5).hbase.regionserver.thread.compaction.large默认值 1

RS中large compactions线程池的大小。调整建议同上。

6).hbase.hstore.blockingStoreFiles默认值 10

一个列族下HFile数量达到该值就会阻塞写入，等待Compaction完成。生产环境中默认值太小了，一般建议设置大点比如100，避免出现阻塞更新的情况。

7).hbase.hregion.majorcompaction默认值 604800000，就是7天，

这是Major Compaction周期性触发的时间间隔。因为通常Major Compaction持续时间长、资源消耗大，建议关闭HBase Major Compaction，参数设为0，并在业务低峰期手动执行。

---

参考：https://blog.csdn.net/weixin_43888806/article/details/99890831