前言

在我们的日常工作中，HBase主要作为KV Store来使用，撑起数据仓库APP层的半边天，为后台和客户端提供高效的存取服务。另外，它也是我们采用的OLAP引擎Kylin的底层存储体系，地位相当重要。

众所周知，HBase的一大优势就是能够实现高速随机读写，这是由HBase设计中的多个因素共同决定的。本文就选取其中一个非常重要的组成部分——MemStore来讲一讲。

从RegionServer到MemStore

下面我们通过复习基础知识来自然地引出MemStore的存在。

image

在HBase体系中，Region是最细粒度的功能单元，一张HBase表即是由一个或多个Region组成。RegionServer运行在HDFS DataNode之上，负责管理存储在它上面的所有Region。除了Region之外，RegionServer还负责管理BlockCache——采用最近最少使用（LRU）策略的读取缓存，以及预写日志WAL——用于记录和恢复数据变更。

在Region中，每个列族的数据会存储在一起，形成一个Store。每个Store由一批HFile与一个MemStore组成。HFile内存储的就是按序持久化在HDFS上的键值结构数据。因为KeyValue实际上是个复杂的数据结构，所以我们并不管它叫“键值对”。

那么MemStore到底是什么呢？一句话：MemStore是列族级别的写入和读取缓存，它保存有那些已经写入但尚未持久化到HFile的数据，所有MemStore都位于RegionServer的物理内存。

既然它的本质是缓存，那么我们就应该结合HBase的写入和读取流程来看看它的作用。

MemStore在读写时的作用

HBase的读写流程（尤其是读取）会涉及到很多非常麻烦的细节，为了避免跑题，这里用一个简化的模型来探讨。

image

• 写入流程
  客户端向HBase写入数据时，会根据ROOT表和META表获取到要写入的Region位置信息，并向RegionServer发出写请求。数据会先写入WAL，再写入Region对应的MemStore。当MemStore的数据量超过一定的阈值后，数据最终按RowKey顺序刷写（Flush）到磁盘，每次Flush都生成一个HFile。MemStore Flush可能会连锁引发Region分裂（Split）和HFile合并（Compaction），这两者都十分复杂，暂且不表。
• 读取流程
  客户端从HBase读取数据时，仍然会先获取要读取的Region位置信息，并向RegionServer发出读请求。根据局部性原理，最近写入的数据很有可能也会最近读取，因此会首先在MemStore中尝试读取，如果MemStore未命中，再去BlockCache读取（图中并未展示出BlockCache）。若BlockCache仍未命中，就要去HFile读取，并返回合并之后的结果数据。最后，将最近读取的数据写入BlockCache。

通过上面的叙述，我们可以对MemStore所扮演的角色有一个大致的印象了。由于它的存在，HBase的读写效率都能得到提升。

MemStore的具体实现是org.apache.hadoop.hbase.regionserver.DefaultMemStore类，基础数据结构是JUC包提供的并发跳表ConcurrentSkipListMap。由于篇幅限制，本文不打算写出源码研究的过程（源码真的太多了），但跳表确实是个很有意思的数据结构，之后会写文章详细分析。

MemStore Flush是上面的流程中最重要且开销最大的操作，HBase并不会为我们提前做优化，因此下面来看看MemStore Flush的触发条件与一些注意事项。

MemStore Flush的触发与相关优化

上面讲写入流程的时候已经提到，“当MemStore的数据量超过一定的阈值后，数据最终按RowKey顺序刷写到磁盘”。该阈值由多个参数共同控制，我们先在Cloudera Manager的HBase Configuration中搜索"memstore"，并截取出对应的配置参数。有两个参数没有出现在下图，在下文叙述中会见到。

image

为了理解连贯，我们不分别解释这些参数的含义，而是直接来叙述哪些情况下会发生MemStore Flush。我们采用的HBase版本为1.2.0。

1. 当一个Region中某个MemStore的大小达到hbase.hregion.memstore.flush.size（默认值128MB）时，会触发该Region中所有MemStore Flush，不会阻塞写操作。
2. 当一个Region中所有MemStore的大小总和达到hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size（默认值2 * 128 = 256MB）时，会触发该Region中所有MemStore Flush，期间阻塞该Region的写操作。
3. 当一个Region准备下线时的MemStore大小总和达到hbase.hregion.preclose.flush.size（默认值5MB）时，会触发该Region中所有MemStore Flush，然后Region才能关闭。
4. 当一个RegionServer中所有MemStore的大小总和达到hbase.regionserver.global.memstore.size * HBASE_HEAPSIZE（默认值0.4 * 堆空间大小）时，会从MemStore最大的Region开始，触发该RegionServer中所有Region的Flush，并阻塞整个RegionServer的写操作。直到MemStore大小回落到上一个参数值的hbase.regionserver.global.memstore.size.lower.limit（默认值0.95）倍，才解除阻塞。
5. 当一个RegionServer中的WAL（即HLog）数量达到hbase.regionserver.maxlogs（默认值32）时，HBase就选取最早的一个WAL对应的那些Region进行MemStore Flush，期间也会阻塞对应Region的写操作。
6. RegionServer会定期Flush MemStore，周期为hbase.regionserver.optionalcacheflushinterval（默认值1小时）。为了避免所有Region同时Flush，定期刷新会有随机的延时。
7. 用户可以通过执行flush [table]或flush [region]命令来手动Flush一张表或一个Region的MemStore。

在多数情况下，MemStore Flush并不会带来什么显著的问题，如以上的1、2、5、6条，要么不会阻塞写操作，要么阻塞的时间很短（毫秒级别）。但是一旦触发第4条中的全RegionServer Flush，阻塞的时间可能要长达分钟级别，对业务影响是非常大的。
为了能够让Flush平稳地进行，有以下优化的建议：

• 单个RegionServer上的Region数目不要过多。在我们的实践中，以50~100个为宜，再多的话容易引发全RegionServer Flush。
• 尽量总是采用一个列族的设计。因为多列族会Flush出更多的HFile，进而引发更加耗时的Compaction操作。
• 对于多写少读的HBase集群，可以适当增大MemStore的内存占比（即hbase.regionserver.global.memstore.size的值）。
• 如果对MemStore内存的调整很大，也必须要同时调整WAL相关的参数，否则WAL的阈值总是先被触发，MemStore本身的限制就无意义了。