Hbase Memstore刷新方式与Region的数目上限

harry发布

Hbase Memstore刷新方式与Region的数目上限

目录

Region数目上限

Region大小上限

MemStore的刷新方式(触发条件)

HLog (WAL) Size & Memstore Flush

频繁的Memstore Flushes


Region数目上限

RegionServer的region数目取决于memstore的内存使用,每个region拥有一组memstore(memstore的数量有hstore决定,hstore的数据由创建表时的指定的列族个数决定,所以 每个region的memstore的个数 = 表的列族的个数 ),可以通过配置来修改memstore占用内存的大小,一般设置在 128 M – 256M之间。

RegionServer 分配一定比例的内存给它下面的所有memstore( 该比例大小 可通过hbase.regionserver.global.memstore.upperLimit 进行修改 ), 如果内存溢出(使用了太多的memstore),它可能会导致严重的后果,如服务器反应迟钝 或compact风暴。比较好的计算每RS(假设一个表)region的数量的公式为:

((RS memory) * (total memstore fraction)) / ((memstore size)*(# column families))

(RegionServer内存  *  分配给MemStore比例) / (Memstore 大小 * 列簇数量)

 

参数 说明
分配给MemStore比例 hbase.regionserver.global.memstore.upperLimit 单个Region内所有的memstore大小总和,超过则flush到磁盘
Memstore 大小 hbase.hregion.memstore.flush.size 如 memstore 大小超过此值(字节数),Memstore 将刷新到磁盘。通过运行由 hbase.server.thread.wakefrequency 指定的频率的线程检查此值。
  hbase.regionserver.global.memstore.lowerLimit 如下
  hbase.hregion.memstore.block.multiplier 超过memstore大小的倍数达到该值则block所有写入请求,自我保护

参数说明:

hbase.regionserver.global.memstore.upperLimit/lowerLimit
默认值:0.4/0.35

upperlimit说明:hbase.hregion.memstore.flush.size 这个参数的作用是当单个Region内所有的memstore大小总和超过指定值时,flush该region的所有memstore。RegionServer的flush是通过将请求添加一个队列,模拟生产消费模式来异步处理的。那这里就有一个问题,当队列来不及消费,产生大量积压请求时,可能会导致内存陡增,最坏的情况是触发OOM。
这个参数的作用是防止内存占用过大,当ReigonServer内所有region的memstores所占用内存总和达到heap的40%时,HBase会强制block所有的更新并flush这些region以释放所有memstore占用的内存。

lowerLimit说明: 同upperLimit,只不过lowerLimit在所有region的memstores所占用内存达到Heap的35%时,不flush所有的memstore。它会找一个memstore内存占用最大的region,做个别flush,此时写更新还是会被block。lowerLimit算是一个在所有region强制flush导致性能降低前的补救措施。在日志中,表现为 “** Flush thread woke up with memory above low water.”
调优:这是一个Heap内存保护参数,默认值已经能适用大多数场景。
参数调整会影响读写,如果写的压力大导致经常超过这个阀值,则调小读缓存hfile.block.cache.size增大该阀值,或者Heap余量较多时,不修改读缓存大小。
如果在高压情况下,也没超过这个阀值,那么建议你适当调小这个阀值再做压测,确保触发次数不要太多,然后还有较多Heap余量的时候,调大hfile.block.cache.size提高读性能。
还有一种可能性是?hbase.hregion.memstore.flush.size保持不变,但RS维护了过多的region,要知道 region数量直接影响占用内存的大小。

hfile.block.cache.size

默认值:0.2
说明:storefile的读缓存占用Heap的大小百分比,0.2表示20%。该值直接影响数据读的性能。
调优:当然是越大越好,如果写比读少很多,开到0.4-0.5也没问题。如果读写较均衡,0.3左右。如果写比读多,果断默认吧。设置这个值的时候,你同时要参考?hbase.regionserver.global.memstore.upperLimit?,该值是memstore占heap的最大百分比,两个参数一个影响读,一个影响写。如果两值加起来超过80-90%,会有OOM的风险,谨慎设置。

 

hbase.hregion.memstore.block.multiplier

指单个MemStore超过 hbase.hregion.memstore.block.multiplier 的倍数,就阻止写入操作。

当一个集群批量导入数据时,写入速度过快导致异常可调整 hbase.hregion.memstore.block.multiplier 参数。

    e.g. 异常处理:https://blog.csdn.net/zhangshenghang/article/details/82621101

Memstore手动flush

hbase(main):001:0> help 'flush'
Flush all regions in passed table or pass a region row to
flush an individual region.  For example:

  hbase> flush 'TABLENAME'
  hbase> flush 'REGIONNAME'
  hbase> flush 'ENCODED_REGIONNAME'

hbase(main):004:0> flush 'user'
0 row(s) in 0.2640 seconds

 

 

例如: 如果 一个RegionServer配置的内存是16g,使用默认配置( hbase默认regionserver分给memstore的比例是0.4 , 默认的menstore的占用128M内存 ), 一个CF,那么这个regionServer下的region的个数大约为 16384 * 0.4 / (128*1) = 51个,实际测试大于这个数 一两倍 也没太大的问题。 一个HBase表包含一至多个region,那么表的数目上限也是可以估算出来的。

 

Region大小上限

   对于生产场景中大表,最大的region大小主要是受compactions 的限制,大量大HFile的compact会降低群集性能。目前,该建议的最大region大小为10-20GB,而5-10GB是最优

 

 

MemStore的刷新方式(触发条件)

1、hbase.hregion.memstore.flush.size

默认值 128M,单个 MemStore 大小超过该阈值就会触发 Flush。如果当前集群 Flush 比较频繁,并且内存资源比较充裕,建议适当调整为 256M。调大的副作用可能是造成宕机时需要分裂的 HLog 数量变多,从而延长故障恢复时间。

2、hbase.hregion.memstore.block.multiplier

默认值 4,Region 中所有 MemStore 超过单个 MemStore 大小的倍数达到该参数值时,就会阻塞写请求并强制 Flush。一般不建议调整,但对于写入过快且内存充裕的场景,为避免写阻塞,可以适当调整到5~8。

3、hbase.regionserver.global.memstore.size

默认值 0.4,RegionServer 中所有 MemStore 大小总和最多占 RegionServer 堆内存的 40%。这是写缓存的总比例,可以根据实际场景适当调整,且要与 HBase 读缓存参数 hfile.block.cache.size(默认也是0.4)配合调整。旧版本参数名称为 hbase.regionserver.global.memstore.upperLimit。

4、hbase.regionserver.global.memstore.size.lower.limit

默认值 0.95,表示 RegionServer 中所有 MemStore 大小的低水位是 hbase.regionserver.global.memstore.size 的 95%,超过该比例就会强制 Flush。一般不建议调整。旧版本参数名称为 hbase.regionserver.global.memstore.lowerLimit。

5、hbase.regionserver.optionalcacheflushinterval

默认值 3600000(即 1 小时),HBase 定期 Flush 所有 MemStore 的时间间隔。一般建议调大,比如 10 小时,因为很多场景下 1 小时 Flush 一次会产生很多小文件,一方面导致 Flush 比较频繁,另一方面导致小文件很多,影响随机读性能,因此建议设置较大值。

  • Memstore级别限制:当Region中任意一个MemStore的大小达到了上限(hbase.hregion.memstore.flush.size,默认128MB),会触发Memstore刷新。
  • Region级别限制:当Region中所有Memstore的大小总和达到了上限(hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size,默认 2* 128M = 256M),会触发memstore刷新。
  • Region Server级别限制:当一个Region Server中所有Memstore的大小总和达到了上限(hbase.regionserver.global.memstore.upperLimit * hbase_heapsize,默认 40%的JVM内存使用量),会触发部分Memstore刷新。Flush顺序是按照Memstore由大到小执行,先Flush Memstore最大的Region,再执行次大的,直至总体Memstore内存使用量低于阈值(hbase.regionserver.global.memstore.lowerLimit * hbase_heapsize,默认 38%的JVM内存使用量)。
  • 当一个Region Server中HLog数量达到上限(可通过参数hbase.regionserver.maxlogs配置)时,系统会选取最早的一个 HLog对应的一个或多个Region进行flush
  • HBase定期刷新Memstore:默认周期为1小时,确保Memstore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行flush导致的问题,定期的flush操作有20000左右的随机延时。
  • 手动执行flush:用户可以通过shell命令 flush ‘tablename’或者flush ‘region name’分别对一个表或者一个Region进行flush。

 

HLog (WAL) Size & Memstore Flush

当数据被写入时会默认先写入Write-ahead Log(WAL)。WAL中包含了所有已经写入Memstore但还未Flush到HFile的更改(edits)。在Memstore中数据还没有持久化,当RegionSever宕掉的时候,可以使用WAL恢复数据。

当WAL(在HBase中成为HLog)变得很大的时候,在恢复的时候就需要很长的时间。因此,对WAL的大小也有一些限制,当达到这些限制的时候,就会触发Memstore的flush。Memstore flush会使WAL 减少,因为数据持久化之后(写入到HFile),就没有必要在WAL中再保存这些修改。有两个属性可以配置:

  • hbase.regionserver.hlog.blocksize
  • hbase.regionserver.maxlogs

你可能已经发现,WAL的最大值由hbase.regionserver.maxlogs * hbase.regionserver.hlog.blocksize (2GB by default)决定。一旦达到这个值,Memstore flush就会被触发。所以,当你增加Memstore的大小以及调整其他的Memstore的设置项时,你也需要去调整HLog的配置项。否则,WAL的大小限制可能会首先被触发,因而,你将利用不到其他专门为Memstore而设计的优化。抛开这些不说,通过WAL限制来触发Memstore的flush并非最佳方式,这样做可能会会一次flush很多Region,尽管“写数据”是很好的分布于整个集群,进而很有可能会引发flush“大风暴”。

提示:最好将hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs 设置为稍微大于hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE.

 

频繁的Memstore Flushes

要避免“写阻塞”,貌似让Flush操作尽量的早于达到触发“写操作”的阈值为宜。但是,这将导致频繁的Flush操作,而由此带来的后果便是读性能下降以及额外的负载。

每次的Memstore Flush都会为每个CF创建一个HFile。频繁的Flush就会创建大量的HFile。这样HBase在检索的时候,就不得不读取大量的HFile,读性能会受很大影响。

为预防打开过多HFile及避免读性能恶化,HBase有专门的HFile合并处理(HFile Compaction Process)。HBase会周期性的合并数个小HFile为一个大的HFile。明显的,有Memstore Flush产生的HFile越多,集群系统就要做更多的合并操作(额外负载)。更糟糕的是:Compaction处理是跟集群上的其他请求并行进行的。当HBase不能够跟上Compaction的时候(同样有阈值设置项),会在RS上出现“写阻塞”。像上面说到的,这是最最不希望的。

Compaction操作尽量取消自动Compaction,使用空闲时间手动执行,已减少对服务的影响

 

参考资料:

http://blog.csdn.net/oozie123

http://hbasefly.com/2016/03/23/hbase-memstore-flush/

《Hbase权威指南》

https://blog.csdn.net/joeyon1985/article/details/71511891

其他的是之前做的笔记,没有记录当时参考文章~~~~

文章来源于互联网:Hbase Memstore刷新方式与Region的数目上限

分类: docker

0 条评论

发表回复

Avatar placeholder

您的电子邮箱地址不会被公开。 必填项已用*标注