网站的建设方向,寻找客户的12种方法,网站后台登陆显示验证码错误,个人做网站需要什么资料数据写入、读取流程使用了LSM树体系架构#xff0c;HBase中的用户数据在LSM树体系架构中最终会形成一个一个小的HFile文件。我们知道#xff0c;HFile小文件如果数量太多会导致读取低效。为了提高读取效率#xff0c;LSM树体系架构设计了一个非常重要的模块——Compaction。…数据写入、读取流程使用了LSM树体系架构HBase中的用户数据在LSM树体系架构中最终会形成一个一个小的HFile文件。我们知道HFile小文件如果数量太多会导致读取低效。为了提高读取效率LSM树体系架构设计了一个非常重要的模块——Compaction。Compaction核心功能是将小文件合并成大文件提升读取效率。一般基于LSM树体系架构的系统都会设计Compaction比如LevelDB、RocksDB以及Cassandra等都可以看到Compaction的身影。
我们首先介绍Compaction的基本工作原理包括分类、在LSM树架构中的核心作用以及副作用、Compaction的触发时机让读者能够对Compaction有一个直观的认识。然后基于HBase内核代码深入介绍HBase系统中Compaction实现的基本流程和常用策略。
1 Compaction基本工作原理
Compaction是从一个Region的一个Store中选择部分HFile文件进行合并。合并原理是先从这些待合并的数据文件中依次读出KeyValue再由小到大排序后写入一个新的文件。之后这个新生成的文件就会取代之前已合并的所有文件对外提供服务。
HBase根据合并规模将Compaction分为两类Minor Compaction和Major Compaction。
·Minor Compaction是指选取部分小的、相邻的HFile将它们合并成一个更大的HFile。
·Major Compaction是指将一个Store中所有的HFile合并成一个HFile这个过程还会完全清理三类无意义数据被删除的数据、TTL过期数据、版本号超过设定版本号的数据。
一般情况下Major Compaction持续时间会比较长整个过程会消耗大量系统资源对上层业务有比较大的影响。因此线上部分数据量较大的业务通常推荐关闭自动触发Major Compaction功能改为在业务低峰期手动触发或设置策略自动在低峰期触发。
在HBase的体系架构下Compaction有以下核心作用
·合并小文件减少文件数稳定随机读延迟。
·提高数据的本地化率。
·清除无效数据减少数据存储量。
随着HFile文件数不断增多查询可能需要越来越多的IO操作读取延迟必然会越来越大。
Compaction的另一个重要作用是提高数据的本地化率。本地化率越高在HDFS上访问数据时延迟就越小相反本地化率越低访问数据就可能大概率需要通过网络访问延迟必然会比较大。
Compaction合并小文件的同时会将落在远程DataNode上的数据读取出来重新写入大文件合并后的大文件在当前DataNode节点上有一个副本因此可以提高数据的本地化率。极端情况下Major Compaction可以将当前Region的本地化率提高到100%。这也是最常用的一种提高数据本地化率的方法。
Compaction在执行过程中有个比较明显的副作用Compaction操作重写文件会带来很大的带宽压力以及短时间IO压力。这点比较容易理解要将小文件的数据读出来需要IO很多小文件数据跨网络传输需要带宽读出来之后又要写成一个大文件因为是三副本写入必然需要网络开销当然写入IO开销也避免不了。因此可以认为Compaction就是使用短时间的IO消耗以及带宽消耗换取后续查询的低延迟。虽然数据读取延迟相比图一稳定了一些但是读取响应时间有了很大的毛刺这是因为Compaction在执行的时候占用系统资源导致业务读取性能受到一定波及。
总的来说Compaction操作是所有LSM树结构数据库所特有的一种操作它的核心操作是批量将大量小文件合并成大文件用以提高读取性能。另外Compaction是有副作用的它在一定程度上消耗系统资源进而影响上层业务的读取响应。因此Compaction通常会设计各种措施并且针对不同场景设置不同的合并策略来尽量避免对上层业务的影响。
1.1 Compaction基本流程
HBase中Compaction只有在特定的触发条件才会执行比如部分flush操作完成之后、周期性的Compaction检查操作等。一旦触发HBase会按照特定流程执行Compaction如图所示。 HBase会将该Compaction交由一个独立的线程处理该线程首先会从对应Store中选择合适的HFile文件进行合并这一步是整个Compaction的核心。选取文件需要遵循很多条件比如待合并文件数不能太多也不能太少、文件大小不能太大等最理想的情况是选取那些IO负载重、文件小的文件集。实际实现中HBase提供了多种文件选取算法如RatioBasedCompactionPolicy、ExploringCompactionPolicy和StripeCompactionPolicy等用户也可以通过特定接口实现自己的Compaction策略。选出待合并的文件后HBase会根据这些HFile文件总大小挑选对应的线程池处理最后对这些文件执行具体的合并操作。
为了更加详细地说明Compaction的整个工作流程将Compaction分解成多个子流程分别进行说明子流程包括Compaction触发时机待合并HFile集合选择策略挑选合适的执行线程池以及HFile文件合并执行。
1.2 Compaction触发时机
HBase中触发Compaction的时机有很多最常见的时机有如下三种MemStore Flush、后台线程周期性检查以及手动触发。
·MemStore Flush应该说Compaction操作的源头来自flush操作MemStore Flush会产生HFile文件文件越来越多就需要compact执行合并。因此在每次执行完flush操作之后都会对当前Store中的文件数进行判断一旦Store中总文件数大于hbase.hstore.compactionThreshold就会触发Compaction。需要说明的是Compaction都是以Store为单位进行的而在flush触发条件下整个Region的所有Store都会执行compact检查所以一个Region有可能会在短时间内执行多次Compaction。
·后台线程周期性检查RegionServer会在后台启动一个线程CompactionChecker定期触发检查对应Store是否需要执行Compaction检查周期为hbase.server.thread.wakefrequency*hbase.server.compactchecker.interval.multiplier。和flush不同的是该线程优先检查Store中总文件数是否大于阈值hbase.hstore.compactionThreshold一旦大于就会触发Compaction如果不满足接着检查是否满足Major Compaction条件。简单来说如果当前Store中HFile的最早更新时间早于某个值mcTime就会触发Major Compaction。mcTime是一个浮动值浮动区间默认为7-7×0.277×0.2其中7为hbase.hregion.majorcompaction0.2为hbase.hregion.majorcompaction.jitter可见默认在7天左右就会执行一次Major Compaction。用户如果想禁用Major Compaction需要将参数hbase.hregion.majorcompaction设为0。
·手动触发一般来讲手动触发Compaction大多是为了执行Major Compaction。使用手动触发Major Compaction的原因通常有三个——其一因为很多业务担心自动Major Compaction影响读写性能因此会选择低峰期手动触发其二用户在执行完alter操作之后希望立刻生效手动触发Major Compaction其三HBase管理员发现硬盘容量不够时手动触发Major Compaction删除大量过期数据。
1.3 待合并HFile集合选择策略
选择合适的文件进行合并是整个Compaction的核心因为合并文件的大小及其当前承载的IO数直接决定了Compaction的效果以及对整个系统其他业务的影响程度。理想的情况是选择的待合并HFile文件集合承载了大量IO请求但是文件本身很小这样Compaction本身不会消耗太多IO而且合并完成之后对读的性能会有显著提升。然而现实中可能大部分HFile文件都不会这样在HBase早期的版本中分别提出了两种选择策略RatioBasedCompactionPolicy以及ExploringCompactionPolicy后者在前者的基础上做了进一步修正。但是无论哪种选择策略都会首先对该Store中所有HFile逐一进行排查排除不满足条件的部分文件
·排除当前正在执行Compaction的文件以及比这些文件更新的所有文件。
·排除某些过大的文件如果文件大于hbase.hstore.compaction.max.size默认Long.MAX_VALUE则被排除否则会产生大量IO消耗。
经过排除后留下来的文件称为候选文件接下来HBase再判断侯选文件是否满足Major Compaction条件如果满足就会选择全部文件进行合并。判断条件如下所列只要满足其中一条就会执行Major Compaction
·用户强制执行Major Compaction。
·长时间没有进行Major Compaction上次执行Major Compaction的时间早于当前时间减去hbase.hregion.majorcompaction且候选文件数小于hbase.hstore.compaction.max默认10。
·Store中含有reference文件reference文件是region分裂产生的临时文件一般必须在Compaction过程中清理。
如果满足Major Compaction条件文件选择这一步就结束了待合并HFile文件就是Store中所有HFile文件。如果不满足Major Compaction条件就必然为Minor CompactionHBase主要有两种Minor Compaction文件选择策略一种是RatioBasedCompactionPolicy另一种是ExploringCompactionPolicy。
1.4 HFile文件合并执行
选出待合并的HFile集合再选出合适的处理线程接下来执行合并流程。合并流程主要分为如下几步
1分别读出待合并HFile文件的KeyValue进行归并排序处理之后写到./tmp目录下的临时文件中。
2将临时文件移动到对应Store的数据目录。
3将Compaction的输入文件路径和输出文件路径封装为KV写入HLog日志并打上Compaction标记最后强制执行sync。
4将对应Store数据目录下的Compaction输入文件全部删除。
上述4个步骤看起来简单但实际是很严谨的具有很强的容错性和幂等性
·如果RegionServer在步骤2之前发生异常本次Compaction会被认定为失败如果继续进行同样的Compaction上次异常对接下来的Compaction不会有任何影响也不会对读写有任何影响。唯一的影响就是多了一份多余的数据。
·如果RegionServer在步骤2之后、步骤3之前发生异常同样仅仅会多一份冗余数据。
·如果在步骤3之后、步骤4之前发生异常RegionServer在重新打开Region之后首先会从HLog中看到标有Compaction的日志因为此时输入文件和输出文件已经持久化到HDFS因此只需要根据HLog移除Compaction输入文件即可。 1.5 Compaction相关注意事项
对文件进行Compaction操作可以提升业务读取性能然而如果不对Compaction执行阶段的读写吞吐量进行限制可能会引起短时间大量系统资源消耗使得用户业务发生读写延迟抖动。HBase社区意识到了这个问题并提出了一些优化方案下面分别介绍。
1.Limit Compaction Speed
该优化方案通过感知Compaction的压力情况自动调节系统的Compaction吞吐量在压力大的时候降低合并吞吐量压力小的时候增加合并吞吐量。基本原理如下
·在正常情况下用户需要设置吞吐量下限参数hbase.hstore.compaction.throughput.lower.bound和上限参数hbase.hstore.compaction.throughput.higher.bound而HBase实际工作在吞吐量为lowerhigher-lower*ratio的情况下其中ratio是一个取值01的小数它由当前Store中待参与Compaction的HFile数量决定数量越多ratio越小反之越大。
·如果当前Store中HFile的数量太多并且超过了参数blockingFileCount此时所有写请求就会被阻塞以等待Compaction完成这种场景下上述限制会自动失效。
Compaction除了带来严重的IO放大效应之外在某些情况下还会因为大量消耗带宽资源而严重影响其他业务。Compaction大量消耗带宽资源主要有以下两个原因
·正常请求下Compaction尤其是Major Compaction会将大量数据文件合并为一个大HFile读出所有数据文件的KV重新排序之后写入另一个新建的文件。如果待合并文件都在本地那么读是本地读不会出现跨网络的情况如果待合并文件并不都在本地则需要跨网络进行数据读取。一旦跨网络读取就会有带宽资源消耗。
·数据写入文件默认都是三副本写入不同副本位于不同节点因此写的时候会跨网络执行必然会消耗带宽资源。
跨网络读是可以通过一定优化措施避免的而跨网络写却是不可能避免的。因此优化Compaction带宽消耗一方面需要提升本地化率减少跨网络读另一方面虽然跨网络写不可避免但也可以通过控制手段使得资源消耗控制在一定范围。HBase在这方面参考Facebook引入了Compaction BandWith Limit机制。
2.Compaction BandWidth Limit
与Limit Compaction Speed思路基本一致Compaction BandWidth Limit方案中主要涉及两个参数compactBwLimit和numOfFilesDisableCompactLimit作用分别如下
·compactBwLimit一次Compaction的最大带宽使用量如果Compaction所使用的带宽高于该值就会强制其sleep一段时间。
·numOfFilesDisableCompactLimit在写请求非常大的情况下限制Compaction带宽的使用量必然会导致HFile堆积进而会影响读请求响应延时。因此该值意义很明显一旦Store中HFile数量超过该设定值带宽限制就会失效。
