Hbase Flush机制

本文详细介绍了HBase中Region的管理,包括Region的触发flush的条件,如Memstore大小达到上限和Storefile数量过多。同时,讨论了RegionSplit的策略,如ConstantSizeRegionSplitPolicy和IncreasingToUpperBoundRegionSplitPolicy。此外,还阐述了RegionServer全局性的触发刷写条件,以及MemstoreFlush的三个阶段:prepare、flush和commit。通过对这些核心机制的理解,有助于优化HBase的性能和资源管理。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最小Flush单元为HRegion,尽量减少CF数量以减少HStrore数量从而减少MemStore的数量,最终减少每次Flush的开销。

1.Region级别触发条件:

a) hbase.hregion.memstore.flush.size

Region中任意MemStore大小达到上限(默认128MB),触发Memstore,flush该region。

b) hbase.hstore.blockingStoreFiles 默认值:7

当前region的Storefile总数超过阈值,则该Region会block所有写请求进行compaction,以减少storefile数量直到完成一次存储文件的合并,或者阻塞到hbase.hstore.blockingWaitTime 超时才解除block。

当该region的一个store的storefile大小之和,即一个store的大小超过hbase.hregion.max.filesize时,这个region会被拆分。slit的入口在memstore flush操作之后,HRegion写入新的Hfile或者HStore刚刚进行完compact操作后,

HBase就会调用CompactSplitThread.requestSplit判断是否需要split操作。这个判断如下:

判断整个HRegionServer所有的HRegion数量是否超过hbase.regionserver.regionSplitLimit(默认Integer.MAX_VALUE,即没有限制)。

当前HRegion所有HStore中包含的HFile最小数是否>=1

尝试获取SplitKey:hbase:meta表(记录HRegion信息的HBase表,只有单个HRegion)、或是正在恢复状态的HRegion返回null。

然后利用设置的策略判断是否需要split操作。一般使用两种策略:ConstantSizeRegionSplitPolicy以及IncreasingToUpperBoundRegionSplitPolicy(默认)。

ConstantSizeRegionSplitPolicy:如果某个不包含Reference文件的HStore(Reference文件是split后产生的临时引用文件,见后述),总大小(包含HFile的总大小)超过hbase.hregion.max.filesize(默认10G),则返回true。

IncreasingToUpperBoundRegionSplitPolicy:对于HRegionServer内所有属于同一个表的HRegion的数n,如果某个不包含Reference文件的HStore,总大小超过[n*n*n*2*MemStoreFlushSize和hbase.hregion.max.filesize(10G)之间最小值],则返回true。

例如,对于如果n=3,则split大小为3^3*2*128M=6912M。可见如果Region数比较少的时候的可以尽早采取split。

返回SplitPoint。返回HRegion里总大小最大HStore的最大HFile的中间rowKey值。

c) hbase.hregion.memstore.block.multiplier默认值:2

2.RegionServer全局性的触发刷写:

a) hbase.regionserver.global.memstore.upperLimit

b) hbase.regionserver.global.memstore.lowerLimit

c) HLog引起的regionserver全局性的触发刷写

d) HBase定期刷新Memstore

Memstore Flush流程

prepare阶段:

遍历当前Region中的所有Memstore,将Memstore中当前数据集kvset做一个快照snapshot,然后再新建一个新的kvset。

后期的所有写入操作都会写入新的kvset中,而整个flush阶段读操作会首先分别遍历kvset和snapshot,如果查找不到再会到HFile中查找。prepare阶段需要加一把updateLock对写请求阻塞,结束之后会释放该锁。因为此阶段没有任何费时操作,因此持锁时间很短。

flush阶段:

遍历所有Memstore,将prepare阶段生成的snapshot持久化为临时文件,临时文件会统一放到目录.tmp下。这个过程因为涉及到磁盘IO操作,因此相对比较耗时。

commit阶段:

遍历所有的Memstore,将flush阶段生成的临时文件移到指定的ColumnFamily目录下,针对HFile生成对应的storefile和Reader,把storefile添加到HStore的storefiles列表中,最后再清空prepare阶段生成的snapshot。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

mylife512

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值