HBase_HBase_原理_Compaction 基于HBase 2.0

最新推荐文章于 2021-09-02 21:39:28 发布

高达一号

最新推荐文章于 2021-09-02 21:39:28 发布

阅读量433

点赞数

分类专栏： HBase

本文链接：https://blog.csdn.net/u010003835/article/details/105929308

版权

HBase 专栏收录该内容

21 篇文章 1 订阅

订阅专栏

参考文章：

深入理解 HBase Compaction 机制

https://blog.csdn.net/u011598442/article/details/90632702

HBase的文件合并（minor/major compact）

http://www.bubuko.com/infodetail-3366448.html

HBase的文件合并（minor/major compact）

https://www.cnblogs.com/xiashiwendao/p/12151573.html

本篇文章主要介绍 HBase 中的 LSM -Tree 中的合并，

分为以下几个部分

LSM-Tree Compaction 主要流程

LSM-Tree Compaction 主要流程

HBase 是基于 LSM-Tree （Log-Structured Merge Tree）存储模型设计，存储模型设计的，

写入路径上是先写入WAL（Write-Ahead-Log）即预写日志，

再写入MemStore 缓存，MemStore中的数据先Flush成一个Immutable的Segment，多个Immutable Segments可以在内存中进行Compaction，当达到一定阈值以后才将内存中的数据持久化成HDFS中的HFile文件。

满足一定条件后执行flush操作将缓存数据刷写到磁盘，生成一个HFile数据文件。

随着数据不断写入，磁盘HFile文件就会越来越多，文件太多会影响HBase查询性能，主要体现在查询数据的io次数增加。为了优化查询性能，HBase会合并小的HFile以减少文件数量，这种合并HFile的操作称为Compaction，这也是为什么要进行Compaction的主要原因。

Compaction 作用

其实Compaction操作属于资源密集型操作特别是IO密集型，这点后面也会提及到，Compaction其实就是以短时间内的IO消耗，以换取相对稳定的读取性能。

Compaction 分类

HBase Compaction 主要分为 3种，内存中的 Segment 的合并，Minor Compaction 与 Major Compaction，通常我们简称为小合并、大合并。下面是一个简单示意图

Minor Compaction :

Minor Compaction：指选取一些小的、相邻的HFile将他们合并成一个更大的HFile。默认情况下，minor compaction会删除选取HFile中的TTL过期数据。

　Minor Compact是指少量HFile文件按照Minor Compact规则进行合并；它的正常流程是这样的，探测到有新的文件刷进来（比如因为memstore的flush，当然可以直接写入HFile而跳过memstore，比如Bulk写入），此时Region Server只要发现同一个列簇有3个及以上的文件，将会扫描文件列表，然后将符合合并规则文件纳入到list中，并且list中文件数>1，则将会进行compact；其中规则如下：

文件大小小于min.size的放入到list中；
文件大小大于max.size的将一定不会放入到list中；
如果文件大小排序，该文件大小小于后面10个文件总大小*1.2（说明文件不是足够），那么就放入到list中；这里10是由hbase.hstore.compaction.max决定，1.2是由hbase.hstore.compaction.ratio决定的。

　　所以看到minor的规则稍微有点复杂，原则是减少合并（文件合并要门当户对），避免形成大文件（达到一定程度之后就不在合并）。
　

Major Compaction :

Major Compaction：指将一个Store中所有的HFile (同一个column family的所有文件) 合并成一个HFile，这个过程会清理三类没有意义的数据：被删除的数据（打了Delete标记的数据）、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此，生产环境下通常关闭自动触发Major Compaction功能，改为手动在业务低峰期触发。

Compaction 触发条件

HBase触发Compaction的条件有三种：memstore Flush、后台线程周期性检查、手动触发。

MemStore Flush：

可以说compaction的根源就在于flush，memstore 达到一定阈值或其他条件时就会触发flush刷写到磁盘生成HFile文件，正是因为HFile文件越来越多才需要compact。HBase每次flush之后，都会判断是否要进行compaction，一旦满足minor compaction或major compaction的条件便会触发执行。

后台线程周期性检查：

后台线程 CompactionChecker 会定期检查是否需要执行compaction，检查周期为 hbase.server.thread.wakefrequency * hbase.server.compactchecker.interval.multiplier，这里主要考虑的是一段时间内没有写入请求仍然需要做compact检查。其中参数 hbase.server.thread.wakefrequency 默认值 10000 即 10s，是HBase服务端线程唤醒时间间隔，用于log roller、memstore flusher等操作周期性检查；参数 hbase.server.compactchecker.interval.multiplier 默认值1000，是compaction操作周期性检查乘数因子。10 * 1000 s 时间上约等于 2hrs, 46mins, 40sec。

手动触发：

是指通过HBase Shell、Master UI界面或者HBase API等任一种方式执行 compact、major_compact等命令。

Compaction 参数解析

Major Compaction 参数

Major Compaction涉及的参数比较少，主要有大合并时间间隔与一个抖动参数因子，如下：

1.hbase.hregion.majorcompaction

Major compaction周期性时间间隔，默认值604800000，单位ms。表示major compaction默认7天调度一次，HBase 0.96.x及之前默认为1天调度一次。设置为 0 时表示禁用自动触发major compaction。需要强调的是一般major compaction持续时间较长、系统资源消耗较大，对上层业务也有比较大的影响，一般生产环境下为了避免影响读写请求，会禁用自动触发major compaction。

2.hbase.hregion.majorcompaction.jitter

Major compaction抖动参数，默认值0.5。这个参数是为了避免major compaction同时在各个regionserver上同时发生，避免此操作给集群带来很大压力。这样节点major compaction就会在 + 或 - 两者乘积的时间范围内随机发生。

Minor Compaction 参数

Minor compaction涉及的参数比major compaction要多，各个参数的目标是为了选择合适的HFile，具体参数如下：

1.hbase.hstore.compaction.min

一次minor compaction最少合并的HFile数量，默认值 3。表示至少有3个符合条件的HFile，minor compaction才会启动。一般情况下不建议调整该参数。

如果要调整，不建议调小该参数，这样会带来更频繁的压缩，调大该参数的同时其他相关参数也应该做调整。早期参数名称为 hbase.hstore.compactionthreshold。

2.hbase.hstore.compaction.max

一次minor compaction最多合并的HFile数量，默认值 10。这个参数也是控制着一次压缩的时间。一般情况下不建议调整该参数。调大该值意味着一次compaction将会合并更多的HFile，压缩时间将会延长。

3.hbase.hstore.compaction.min.size

文件大小 < 该参数值的HFile一定是适合进行minor compaction文件，默认值 128M（memstore flush size）。意味着小于该大小的HFile将会自动加入（automatic include）压缩队列。一般情况下不建议调整该参数。

但是，在write-heavy就是写压力非常大的场景，可能需要微调该参数、减小参数值，假如每次memstore大小达到1~2M时就会flush生成HFile，此时生成的每个HFile都会加入压缩队列，而且压缩生成的HFile仍然可能小于该配置值会再次加入压缩队列，这样将会导致压缩队列持续很长。

4.hbase.hstore.compaction.max.size

文件大小 > 该参数值的HFile将会被排除，不会加入minor compaction，默认值Long.MAX_VALUE，表示没有什么限制。一般情况下也不建议调整该参数。

5.hbase.hstore.compaction.ratio

这个ratio参数的作用是判断文件大小 > hbase.hstore.compaction.min.size的HFile是否也是适合进行minor compaction的，默认值1.2。更大的值将压缩产生更大的HFile，建议取值范围在1.0~1.4之间。大多数场景下也不建议调整该参数。

6.hbase.hstore.compaction.ratio.offpeak

此参数与compaction ratio参数含义相同，是在原有文件选择策略基础上增加了一个非高峰期的ratio控制，默认值5.0。这个参数受另外两个参数 hbase.offpeak.start.hour 与 hbase.offpeak.end.hour 控制，这两个参数值为[0, 23]的整数，用于定义非高峰期时间段，默认值均为-1表示禁用非高峰期ratio设置。

Compaction 线程池选择

HBase RegionServer内部专门有一个 CompactSplitThead 用于维护执行minor compaction、major compaction、split、merge操作的线程池。其中与compaction操作有关的线程池称为 largeCompactions（又称longCompactions）与 smallCompactions（又称shortCompactions），前者用来处理大规模compaction，后者处理小规模compaction，线程池大小都默认为 1 即只分别提供了一个线程用于相应的compaction。
这里并不是major compaction就一定会交给largeCompactions线程池处理。关于HBase compaction分配给largeCompactions还是smallCompactions线程池受参数 hbase.regionserver.thread.compaction.throttle 控制，该参数默认值为2 * hbase.hstore.compaction.max * hbase.hregion.memstore.flush.size，如果flush size 大小是128M，该参数默认值就是2684354560 即2.5G。一次compaction的文件总大小如果超过该配置，就会分配给largeCompactions处理，否则分配给smallCompactions处理。

largeCompactions与smallCompactions的线程池大小可通过参数 hbase.regionserver.thread.compaction.large、hbase.regionserver.thread.compaction.small进行配置。对于compaction压力比较大的场景，如果要调大两种线程池的大小，建议调整范围在2~5之间，不建议设置过大否则可能会消费过多的服务端资源造成不良影响。

Compaction 策略介绍

HBase的compaction policy准确的说有4种，分别是RatioBasedCompactionPolicy、ExploringCompactionPolicy、FIFOCompactionPolicy 以及 StripeCompactionPolicy。其中，HBase使用的压缩策略主要就是前两种，HBase 0.96.x版本之前，默认的压缩策略是RatioBasedCompactionPolicy，HBase 0.96.x以及更新版本中，默认为ExploringCompactionPolicy。ExploringCompactionPoliy要比旧版本中的RatioBasedCompactionPolicy 性能更高，因此一般情况下也不建议改变默认配置。各种压缩策略之间更详细的区别不再介绍。

如果在HBase 0.96.x之后仍想配置RatioBasedCompactionPolicy策略，可以通过修改hbase-site.xml添加hbase.hstore.defaultengine.compactionpolicy.class配置项，配置值为RatioBasedCompactionPolicy，恢复默认配置只需移除该配置项即可。

Compaction 对读写请求的影响

存储上的写入放大

HBase Compaction会带来写入放大，特别是在写多读少的场景下，写入放大就会比较明显，下图简单示意了写入放大的效果。

随着minor compaction以及major Compaction的发生，可以看到，这条数据被反复读取/写入了多次，这是导致写放大的一个关键原因，这里的写放大，涉及到网络IO与磁盘IO，因为数据在HDFS中默认有三个副本。

读路径上的延时毛刺

HBase执行compaction操作结果会使文件数基本稳定，进而IO Seek次数相对稳定，延迟就会稳定在一定范围。然而，compaction操作会带来很大的带宽压力以及短时间IO压力。因此compaction就是使用短时间的IO消耗以及带宽消耗换取后续查询的低延迟。这种短时间的压力就会造成读请求在延时上会有比较大的毛刺。下图是一张示意图，可见读请求延时有很大毛刺，但是总体趋势基本稳定。

写请求上的短暂阻塞

Compaction对写请求也会有比较大的影响。主要体现在HFile比较多的场景下，HBase会限制写请求的速度。如果底层HFile数量超过 hbase.hstore.blockingStoreFiles 配置值，默认10，flush操作将会受到阻塞，阻塞时间为hbase.hstore.blockingWaitTime，默认90000，即1.5分钟，在这段时间内，如果compaction操作使得HFile下降到blockingStoreFiles配置值，则停止阻塞。另外阻塞超过时间后，也会恢复执行flush操作。这样做可以有效地控制大量写请求的速度，但同时这也是影响写请求速度的主要原因之一。