必威体育Betway必威体育官网
当前位置:首页 > IT技术

深入理解 HBase Compaction 机制

时间:2019-10-01 14:43:18来源:IT技术作者:seo实验室小编阅读:74次「手机版」
 

compaction

欢迎微信搜索公众号:数据手稿笔记,更深入学习HBase,以及更多的大数据技术社区动态等。


HBase有很多话题可以聊,包括读写路径上涉及到的一些数据结构,性能优化以及优化读写做的一些设计等。今天要探讨的Compaction机制就是HBase架构上做的一个重要优化,其实关于HBase的架构设计、Flush&Compaction等文章已经多不胜数了,本文也是主要参考HBase官网、社区的一些文章总结,从各个关键点进行总结,旨在为了帮助我们更加牢固的掌握Compaction机制。

为什么要执行 Compaction

熟悉HBase的同学应该知道,HBase是基于一种LSM-Tree(Log-structured Merge Tree)存储模型设计的,写入路径上是先写入WAL(Write-Ahead-Log)即预写日志,再写入memstore缓存,满足一定条件后执行flush操作将缓存数据刷写到磁盘,生成一个HFile数据文件。随着数据不断写入,磁盘HFile文件就会越来越多,文件太多会影响HBase查询性能,主要体现在查询数据的io次数增加。为了优化查询性能,HBase会合并小的HFile以减少文件数量,这种合并HFile的操作称为Compaction,这也是为什么要进行Compaction的主要原因。

Compaction 作用

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

Compaction 分类

HBase Compaction分为两种:Minor Compaction 与 Major Compaction,通常我们简称为小合并、大合并。下面是一个简单示意图

(图片来源:https://mmbiz.qpic.cn/mmbiz_png/licvxR9ib9M6D6sDjXPZxHR1ic4LDKyicf2q9R9a7SLbxnvKOmjMdOiazq7DmjwSyyNKEMVV31Hv9eZhlTChPfjA3Nw/640)

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

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

这里值得关注,默认情况下Minor Compaction也会删除数据,但只是删除合并HFile中的TTL过期数据。Major Compaction是完全删除无效数据,包括被删除的数据、TTL过期数据以及版本号过大的数据。

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.hourhbase.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.largehbase.regionserver.thread.compaction.small进行配置。对于compaction压力比较大的场景,如果要调大两种线程池的大小,建议调整范围在2~5之间,不建议设置过大否则可能会消费过多的服务端资源造成不良影响。

Compaction 策略介绍

HBase的compaction policy准确的说有4种,分别是RatiobasedCompactionPolicyExploringCompactionPolicy、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会带来写入放大,特别是在写多读少的场景下,写入放大就会比较明显,下图简单示意了写入放大的效果。

(图片来源:https://mmbiz.qpic.cn/mmbiz_png/licvxR9ib9M6D6sDjXPZxHR1ic4LDKyicf2qfx417fJ8QHmfn82uBhSS1fC4mDqSB67JHzGs6kyqHiccrQEu2ryPKJA/640)

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

读路径上的延时毛刺

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

(图片来源:http://img0.tuicool.com/3m2aijv.png)

写请求上的短暂阻塞

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

Compaction 总结

HBase Compaction操作是为了数据读取做的优化,总的来说是以牺牲磁盘io来换取读性能的基本稳定。Compaction操作分为minor compaction与major compaction,其中major compaction消耗资源较大、对读写请求有一定影响,因此一般是禁用自动周期性执行而选择业务低峰期时手动执行。另外本文也重点介绍了操作相关的各个参数,帮助加强对Compaction的理解以及便于后续调参参考。

参考

http://hbase.apache.org/book.html#compaction

https://mp.weixin.qq.com/s/ctnCm3uLCotgRpozbXmVMg

https://blog.csdn.net/cangencong/article/details/72763265

https://blog.csdn.net/shenshouniu/article/details/83902291


关注我,一起进步。

相关阅读

Hbase特性介绍

1、什么是Hbase。 是一个高可靠性、高性能、列存储、可伸缩、实时读写的分布式数据库系统。 适合于存储非结构化数据,基于列的而不

App邀请机制下,策略决定成败

本篇文章分析了邀请机制的几个要点、市场案例,以及邀请机制的形式。邀请注册机制是现在几乎所有App都会设计的一个功能,这是获客成

Oracle数据库深入学习

一、Oracle概念 oracle数据可系统是美国oracle(甲骨文)公司提供的以分布式数据库为核心的一组软件产品,是目前最流行的客户/服务器或

hbase-高级API-协处理器(Observer)

协处理器 过滤器减少服务器端通过网络返回到客户端 的数据量 协处理器(coprocessor):HBase把部分计算移到数据的存放端 协处理器简介

深入浅出PID控制算法(二)————PID算法离散化和增量式

引言 上篇介绍了连续系统的PID算法,但是计算机控制是一种采样控制,他只能根据采样时刻的偏差来计算控制量,因此计算机控制系统中

分享到:

栏目导航

推荐阅读

热门阅读