HBase MemStore

MemStore 详解

Store

A Store hosts a MemStore and 0 or more StoreFiles (HFiles). A Store corresponds to a column family for a table for a given region.

  • 多行RowKey与Column Family相交的地方构成Stroe,每个Region 包含多个Store。
  • 每个Store由一个MemStore和0个或多个StoreFile 组成。

MemStore

MemStore保存了对Store内存的修改,修改Cells单元或KeyValue键值对数据。有刷写请求时,当前的MemStore会被移动到一个快照并被清除,HBase继续提供来自新的MemStore的编辑服务,并且支持快照,直到flush报告刷写成功。此时该快照才会被丢弃。
Note:当发生新的刷写请求时,同一个Region下的所有MemStore都将会被刷写。

为什么要有MemStore?

为了方便查询,存储在HDFS上的Hfile需要按照RowKey排序,而HDFS本身设计为顺序写,只支持追加的方式写入,而不允许修改。这样的话HBase就不能高效的写数据,因为将写入到HBase的数据不被排序就意味着没有检索优化。为了解决这个问题,HBase将最近接受到的数据缓存到内存中,在持久化到HDFS之前完成排序,然后快速顺序写入到HDFS。
Note :存储在HDFS中的Hfie不仅仅是排序后的列表。

除此之外MemStore还有其他好处:

  1. 作为一个内存级缓存,缓存最近增加的数据,通常新的数据往往比老的数据使用频繁。
  2. 在持久化到HDFS之前,可以对Rows/Cells做一些优化,当数据的Version为1的时候,MemStore可能存了多个对该Cell的更新,此时写入到HFile时,没必要全部保存,只存储最最后一个最新的版本,将其他之前的版本抛弃。

Note:每次Flush都会为Column Famliy 创建一个新的HFile,这样在查询时效率会相对较高一些,HBase会先检查请求数据是否在MemStore中,然后再检查Block Cache中,最后检查HFile,最终会返回一个merge的结果给用户。

MemStore Flush

每个MemStore都有一定的阈值,当MemStore达到阈值大小时会进行 Flush。

Note:The minimum flush unit is per region, not at individual MemStore level.

A MemStore flush can be triggered under any of the conditions listed as below:

  1. Region级的刷写:

    某个MemStore达到"hbase.hregion.memstore.flush.size, 128M by default"时,当前MemStore所属Region对应的所有MemStore都会刷写。

  2. RegionServer全局触发刷写:

    当Regionserver中Memstore的总大小达到"heapsize*0.4*0.95"时该RegionServer下所有的MemStore都会被刷写,直到MemStore的总大小低于hbase.regionserver.global.memstore.upperLimit,刷写顺序为MemStore的使用降序。

  3. WAL(Hlog)引起RegionServer触发全局刷写:

    当WAL 大小超过 "hbase.regionserver.maxlogs * hbase.regionserver.hlog.blocksize (2GB by default)"时,所有的MemStore都会被刷写,直到WAL中文件的个数小于hbase.regionserver.max.logs,刷写顺序基于时间,时间最久的MemStore将会被率先刷写。

    当WAL 中的文件个数超过 "hbase.regionserver.max.logs, 32 by default"时,所有的MemStore都也会被刷写,现在这个值已经不可以设置。

  4. 当自动刷写的时间到了也会触发memstoreflush,自动刷新的时间间隔默认1小时。

由于MemStore的频繁刷写会对HBase集群的读写性能产生严重的影响,并有可能带来一些额外的负载,同时MemStore的刷写方式可能会影响Schema的设计,所以我们要对MemStore的一些配置格外关注。
对于MemStore的刷写,通常有两类配置项:

  1. 决定Flush的触发时机。

    • hbase.hregion.memstore.flush.size
    • hbase.regionserver.heapsize * 0.4 * 0.95
      Note:在我们设置第一个参数即每个MemStore的内存大小时,一定要考虑当前RegionServer所管理的Region的个数以及总内存的大小,否则可能一开始的时候Region较少,但随着Region的增多,虽然每个MemStore的大小都没有达到刷写条件,但是总的内存大小已经达到了总内存大小的限制,会使刷写提前触发。
  2. 决定Flush的触发时更新被阻断。

    • hbase.hregion.memstore.flush.size * 4
      当某个MemStore达到hbase.hregion.memstore.flush.size * 4 即512M时会阻止继续往该memstore写数据。

    • hbase.regionserver.global.memstore.upperLimit
      当ReigonServer内所有Region的Memstores所占用内存总和达到heapsize的40%时,HBase会强制block所有的更新并flush这些region以释放所有memstore占用的内存,阻断更新请求。

    • hbase.regionserver.global.memstore.lowerLimit
      当Regionserver中Memstore的总大小达到"hbase.regionserver.global.memstore.lowerLimit"时不会flush所有的Memstore。它会找一个Memstore内存占用最大的Region,做个别flush,此时写更新还是会被block。

      hbase.regionserver.global.memstore.lowerLimit = 'heapsize*0.35'

    • 当HFile的数量超过一定的阈值也会产生写阻塞。

第一组配置是关于正常的Flush,这类flush发生时并不会影响写请求。
第二组配置主要出于安全考虑,有时候集群的"写负载"非常高写入量一直超过flush的量,这是我们就希望MemStore不要超过一定的安全设置。这种情况下写操作就要被阻止,直到MemStore恢复到一个可管理的大小。
提示:密切关注Memstore的大小和Memstore Flush Queue的Size大小。理想情况下,Memstore的大小不应该达到hbase.regionserver.global.memstore.upperLimit的设置,Memstore Flush Queue 的size不能持续增长。某个节点“写阻塞”对该节点来说影响很大,但是对于整个集群的影响更大。HBase设计为:每个Region仅属于一个RS但是“写负载”是均匀分布于整个集群(所有Region上)。有一个如此“慢”的节点,将会使得整个集群都会变慢(最明显的是反映在速度上)。

WAL(Hlog) Size:

  • 每当RegionServer收到写请求时,RegionServer会将请求转至相应的Region,每个Region的Column Family数据都存储在Store中,而Store由MemStore和StoreFile组成,MemStore位于RegionServer的内存中,当RegionServer处理写请求时,先将数据写入到MemStore进行排序,然后在刷写到HFile。但由于MemStore是基于内存的,存在RegionSever宕掉时数据丢失的风险,所以,当数据被写入时会默认先写入Write-ahead Log(WAL)。WAL中包含了所有已经写入MemStore但还未Flush到HFile的更改(edits),然后再将数据写入到MemStore,在MemStore中数据还没有持久化,虽然可能RegionSever宕掉,但是可以使用WAL恢复数据。
  • 但是当WAL中数据变的很大时,恢复数据的时间就会变得很长,因此对WAL的大小也有一些限制,当达到这些限制的时候MemStore就会触发刷写,从而减小WAL的大小。WAL 的最大值由hbase.regionserver.maxlogs * hbase.regionserver.hlog.blocksize (2GB by default)决定。

Note:通常增加MemStore的内存大小时,也要增加HLog的大小,否则WAL会率先出发MemStore的刷写,因而将无法利用专门为MemStore设置的优化,并且WAL触发的MemStore刷写为全局触发,一次会Flush很多Region,进而很有可能会引起"Flush 大风暴",尽管写数据是很好的分布在整个集群,但是这种情况仍然是我们不希望看到的。

Tips:通常将WAL的hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs 设置为稍微大于hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE。

频繁的刷写会产生的问题:

为了避免写阻塞貌似让Flush操作尽早的达到触发条件的阈值时为宜,但是这将导致频繁的Flush操作,而这可能会使读写性能下降以及增加额外的负载。
因为每次Flush都会创建一个新的HFile,频繁的Flush就会产生大量的Flush,这样在HBase检索时会读取大量的HFile,这使得读性能大打折扣。并且当HFile的数量达到一定阈值的时候也会造成"写阻塞"。

所以HBase为了避免打开过多的HFile造成读性能的恶化,有专门的HFile合并处理,HBase会周期的将多个小的HFile合并成一个大的HFile,显然HFile的数量越多,集群系统要做的合并操作就越多,更糟糕的是Compaction处理是跟集群上其他请求并行执行的,当Compaction不能跟上HBase的刷写速度时,同样会在RegionServer上出现"写阻塞"。
Note:密切关注RegionServer上Compaction Queue 的size,避免在出现问题前持续增大。

当HBase中的table中,Column Famliy的数据量不均匀时,当其中一个较大的Column Family达到MemStore的刷写阈值时,同一个Region中的其他的数据量较少的Column Family对应的MemStore也会刷写,这将会产生大量的HFile小文件。所以通常情况下,一个ColumnFamily时最好的选择。

Source From:https://hbase.apache.org/book.html

作者:yuexiuping
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利.
posted @ 2021-06-21 19:18  yuexiuping  阅读(21)  评论(0编辑  收藏  举报