Flush 触发条件
memstore 级别限制
- 当
Region
中任意一个MemStore
的大小达到了上限(hbase.hregion.memstore.flush.size
,默认128MB
),会触发Memstore
刷新(flush
)。
1 2 3 4 |
<property> <name>hbase.hregion.memstore.flush.size</name> <value>134217728</value> </property> |
region 级别限制
- 当
Region
中所有Memstore
的大小总和达到了上限(hbase.hregion.memstore.block.multiplier
*hbase.hregion.memstore.flush.size
,默认2 * 128M = 256M
),会触发memstore
刷新。
1 2 3 4 5 6 7 8 |
<property> <name>hbase.hregion.memstore.flush.size</name> <value>134217728</value> </property> <property> <name>hbase.hregion.memstore.block.multiplier</name> <value>4</value> </property> |
说明:
- 上限值 =
134217728 x 4*
Region Server级别限制
- 当一个
Region Server
中所有Memstore
的大小总和超过低水位阈值hbase.regionserver.global.memstore.size.lower.limit * hbase.regionserver.global.memstore.size
(前者默认值0.95
),RegionServer
开始强制flush
; - 先
Flush Memstore
最大的Region
,再执行次大的,依次执行; - 如写入速度大于flush写出的速度,导致总
MemStore
大小超过高水位阈值hbase.regionserver.global.memstore.size
(默认为JVM内存的40%),此时RegionServer
会阻塞更新并强制执行flush,直到总MemStore
大小低于低水位阈值
1 2 3 4 5 6 7 8 |
<property> <name>hbase.regionserver.global.memstore.size.lower.limit</name> <value>0.95</value> </property> <property> <name>hbase.regionserver.global.memstore.size</name> <value>0.4</value> </property> |
HLog数量上限
- 当一个
Region Server
中HLog
数量达到上限(可通过参数hbase.regionserver.maxlogs
配置)时,系统会选取最早的一个HLog
对应的一个或多个Region
进行flush
定期刷新 Memstore
- 默认周期为1小时,确保
Memstore
不会长时间没有持久化。为避免所有的MemStore
在同一时间都进行flush
导致的问题,定期的flush
操作有20000
左右的随机延时。
手动 flush
- 用户可以通过shell命令
flush <tablename>
或者flush <region name>
分别对一个表或者一个Region
进行flush
。
flush的流程
为了减少flush
过程对读写的影响,将整个flush
过程分为三个阶段:
-
prepare阶段:遍历当前
Region
中所有的Memstore
,将Memstore
中当前数据集CellSkipListSet
做一个快照snapshot
;然后再新建一个CellSkipListSet
。后期写入的数据都会写入新的CellSkipListSet
中。prepare阶段需要加一把updateLock
对写请求阻塞,结束之后会释放该锁。因为此阶段没有任何费时操作,因此持锁时间很短。 -
flush阶段:遍历所有
Memstore
,将prepare阶段生成的snapshot
持久化为临时文件,临时文件会统一放到目录.tmp
下。这个过程因为涉及到磁盘IO操作,因此相对比较耗时。 -
commit阶段:遍历所有Memstore,将flush阶段生成的临时文件移到指定的
ColumnFamily
目录下,针对HFile
生成对应的storefile
和Reader
,把storefile
添加到HStore
的storefiles
列表中,最后再清空prepare阶段生成的snapshot
。
Compact合并机制
hbase为了防止小文件过多,以保证查询效率,hbase需要在必要的时候将这些小的store file
合并成相对较大的store file
,这个过程就称之为compaction。
在hbase中主要存在两种类型的compaction合并
minor compaction 小合并
major compaction 大合并
HBase 2.x 还可以基于内存合并
minor compaction 小合并
-
在将
Store
中多个HFile
合并为一个HFile
在这个过程中会选取一些小的、相邻的
StoreFile
将他们合并成一个更大的StoreFile
,这种合并的触发频率很高。 -
minor compaction
触发条件由以下几个参数共同决定:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
<!--默认值3;表示一个store中至少有4个store file时,会触发minor compaction--> <property> <name>hbase.hstore.compactionThreshold</name> <value>3</value> </property> <!--默认值10;表示一次minor compaction中最多合并10个store file--> <property> <name>hbase.hstore.compaction.max</name> <value>10</value> </property> <!--默认值为128m;表示store file文件大小小于该值时,一定会加入到minor compaction的--> <property> <name>hbase.hstore.compaction.min.size</name> <value>134217728</value> </property> <!--默认值为LONG.MAX_VALUE;表示store file文件大小大于该值时,一定会被minor compaction排除--> <property> <name>hbase.hstore.compaction.max.size</name> <value>9223372036854775807</value> </property> |
major compaction 大合并
-
合并
Store
中所有的HFile
为一个HFile
将所有的
StoreFile
合并成一个StoreFile
,这个过程还会清理三类无意义数据:被删除的数据、TTL过期数据、版本号超过设定版本号的数据。合并频率比较低,默认7天执行一次,并且性能消耗非常大,建议生产关闭(设置为0),在应用空闲时间手动触发。一般可以是手动控制进行合并,防止出现在业务高峰期。 -
major compaction触发时间条件
12345<!--默认值为7天进行一次大合并,--><property><name>hbase.hregion.majorcompaction</name><value>604800000</value></property> -
手动触发
12##使用major_compact命令major_compact tableName
Views: 15