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 大小 * 列簇数量)

参数说明：

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

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