今天就跟大家聊聊有关如何解析HBase大合并与小合并，可能很多人都不太了解，为了让大家更加了解，小编给大家总结了以下内容，希望大家根据这篇文章可以有所收获。
成都创新互联公司专注于企业成都全网营销、网站重做改版、达川网站定制设计、自适应品牌网站建设、H5建站、商城网站建设、集团公司官网建设、外贸网站制作、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为达川等各大城市提供网站开发制作服务。
下面这种图是HBase的存储架构图，网上也有很多我这里就不讲了：
随着用户的持续写入,磁盘HFile文件就会越来越多，元数据也越来越多，单次HBase的查询就需要越来越多的IO操作，增加上查询的耗时，为了优化查询性能，HBase会合并小的HFile以减少文件数量，HBase设计了Compaction机制。
HBase Compaction机制介绍：
HBase Compaction分类：
a.Minor Compaction 小合并
指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次 Minor Compaction 的结果是更少并且更大的StoreFile。
b.Major Compaction 大合并
将所有的StoreFile合并成一个StoreFile，这个过程会清理三种数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据(VERSION）。
注意：
major compaction一般执行时间比较长，且耗资源比较大，由参数hbase.hregion.majorcompaction控制默认的执行周期是7天，生产集群一般将其关闭，等业务量较少或者晚上执行。
设置hbase.hregion.majorcompaction = 0可以关闭CompactionChecke触发的major compaction，但是无法关闭用户调用级别的mc。
Compaction的作用：
a.合并文件
b.清除删除、过期、多余版本的数据
c.提高读写数据的效率
Compaction的触发条件
a.hbase shell中的compact或者major_compact请求
b..memstore flush后,都会判断是否要进行compaction，一旦满足minor compaction或major compaction的条件便会触发执行。
c.响应api中的majorCompact（ ）
d.后台线程轮询 ，HBase后台线程CompactionChecker 会定期检查是否需要执行compaction，检查周期为两个参数乘积：
hbase.server.thread.wakefrequency*hbase.server.compactchecker.interval.multiplier
参数解释：
hbase.server.thread.wakefrequency 默认值 10000 即 10s，是HBase服务端线程唤醒时间间隔，用于log roller、memstore flusher等操作周期性检查；
hbase.server.compactchecker.interval.multiplier 默认值1000s，是compaction操作周期性检查乘数因子。
所以执行周期默认是：
10 * 1000 s 时间上约等于2hrs, 46mins, 40sec。
我这里从源码中截了两张图，有兴趣你可以去看下HBase的源码：
这里默认取值就是10*1000就是10秒：
注意：
这里需要注意的是CompactionChecker线程即使到了执行的时间，也不一定执行major compaction，还需要满足另外一个条件：
对每个HStore进行一次判断，needsCompaction()判断是否足够多的文件触发了Compaction的条件。
条件为：
HStore中StoreFIles的个数 – 正在执行Compacting的文件个数 > minFilesToCompact
minFilesToCompact：默认为3,即超过3个hfile文件则启动合并。
CompactionChecker线程中会有个函数needsCompaction()，先去判断是否需要执行，代码如下：
Minor Compaction和Major Compaction有一些相关的参数，网上有很多 ，我觉得这几个可能需要调整，其他都默认比较好：
1).hbase.hregion.majorcompaction:
配置major合并的间隔时间，默认为7天，可设置为0，禁止自动的major合并，可手动或者通过脚本定期进行major合并。
2).hbase.hstore.compaction.max:
设置执行Compaction(包括Major &Minor)的待合并文件的最大个数。默认值为10，如果超过该设置值，会对部分文件执行一次MinorCompaction,线上一般配置值30。
3).hbase.hstore.compactionThreshold:
设置执行Compaction(Major && Minor)操作的阈值，默认是3，如果想降低过频繁的合并操作，可以稍微调大一点，对于HBase负载较重的系统，可以设置成5。
4).hbase.hstore.compaction.max.size
文件大小 > 该参数值的StoreFile将会被排除，不会加入minor compaction，默认值Long.MAX_VALUE，表示没有什么限制。一般情况下也不建议调整该参数。
5).hbase.regionserver.thread.compaction.small:
默认值为1，regionserver做Minor Compaction时线程池里线程数目,可以设置为5。
6).hbase.regionserver.thread.compaction.large:
默认值为1，regionserver做Major Compaction时线程池里线程数目，可以设置为8。
7).hbase.hstore.compaction.kv.max
默认值10，compaction过程中，每次从Hfile中读取kv的个数，内存够的话可适当调大。
Minor Compaction和Major Compaction对读写的影响：
1).首先Compaction涉及到磁盘的读写，肯定会增加了整个集群的io负担。
2).对写的影响：
这里主要有两个参数：
hbase.hstore.blockingStoreFiles
hbase.hstore.blockingWaitTime
如果底层HFile数量超过hbase.hstore.blockingStoreFiles 配置值，默认10,flush操作将会受到阻塞，阻塞时间为hbase.hstore.blockingWaitTime，默认90000,在这段时间内，如果compaction操作使得HFile下降到blockingStoreFiles配置值，则停止阻塞。另外阻塞超过时间后，也会恢复执行flush操作。这样做可以有效地控制大量写请求的速度，但同时这也是影响写请求速度的主要原因之一。
3).对读的影响：
Compaction操作会带来很大的带宽压力以及短时间IO压力。因此compaction就是使用短时间的IO消耗以及带宽消耗换取后续查询的低延迟。这种短时间的压力就会造成读请求在延时上会有比较大的波动。
看完上述内容，你们对如何解析HBase大合并与小合并有进一步的了解吗？如果还想了解更多知识或者相关内容，请关注创新互联行业资讯频道，感谢大家的支持。
