HBase写过程详解

1首次读写流程图

2 首次写基本流程

（1）客户端发起PUT请求，Zookeeper返回hbase:meta所在的region server

（2）去（1）返回的server上，根据rowkey去hbase:meta中获取即将进行写操作的region server，并将相关的信进行本地缓存

（3）客户端把put请求发送到（2）返回的HRegion server上，根据HRegion server的架构图，细化如下：

• • 首先写入WAL（写入到磁盘文件中）

• • 根据Rowkey获取HRegion， 根据column获取HStore
  • 将数据写入HStore的MemStore

• • 持续写入MemStore时，如果MemStore满了，将其加入到Flush队列，由单独的线程flush到磁盘上，形成Storefile

注：客户端进行后续读写时， 首先查询本地缓存获取meta表的位置。

3 flush时机（触发条件）

• MemStore级别限制

Region中任意一个MemStore的大小超过上限（hbase.hregion.memstore.flush.size，默认128MB），会触发MemStore刷新

• HRegion 级别限制

当Region中所有的MemStore的总和大小超过上限（hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size，默认 2* 128M = 256M），会触发MemStore刷新

• HRegion Server级别限制

当一个Regoin server中的所有MemStore的总和大小超过上限（hbase.regionserver.global.memstore.upperLimit * hbase_heapsize，默认40%的JVM内存使用量）回触发部分MemStore刷新。刷新的顺序是按照MemStore的大小排序，先刷新最大的MemStore所在的Region，再刷新次大的，直至总体Memstore内存使用量低于阈值（hbase.regionserver.global.memstore.lowerLimit * hbase_heapsize，默认38%的JVM内存使用量）。

• HRegion Server log限制

当一个Region Server中HLog数量达到上限（可通过参数hbase.regionserver.maxlogs配置）时，系统会选取最早的一个 HLog对应的一个或多个Region进行flush

• MemStore 定时flush

默认周期为1小时，确保Memstore不会长时间没有持久化。为避免所有的MemStore在同一时间都进行flush导致的问题，定期的flush操作有20000左右的随机延时。

• client手动flush

用户可以通过shell命令 flush ‘tablename’或者flush ‘region name’分别对一个表或者一个Region进行flush。

   注意：MemStore进行flush的最小单位是HRegion 而不是MemStore，因此在设计中要用尽量少的family column。 因为Column Family个数跟HStore个数对应，如果有多个Column Family就会有多个HStore，其中一个HStore的MemStore满了导致flush时，由于flush的最小单元是HRegion，会导致HRegion中的多有的MemStore都flush成文件。而且还有个问题，有的column family可能很多行数据了，但是有的可能就几条也flush出来，带来性能问题。而且因为HBase是按行的方向上分成几个region，可能导致这几条也要被分成几个region，分不到不同的文件里。

问题：为什么不以MemStore为单位进行flush呢？

解答：如果仅选择MemStore较大的进行Flush，那么HLog中记录的Key在同一个region的不同colomn family(Store)上就会有不同的key区间（难道目前HLog只细化到rowkey级别？待考证） 而且进行scan操作时就不统一了（参考http://blog.csdn.net/liyanyun/article/details/20134417）（个人认为这不是问题：以为scan的结果肯定是MemStore和HFile结果的总和，所以不管有没有被flush出来，都能获取到结果，待考证）

另：MemStore每次进行flush操作都会产生新的HFile，而不是修改现有的文件（参见http://www.cnblogs.com/tgzhu/p/5859014.html）

memstoreFlush出来的文件是经过压缩的，比如memstoreFlushSize设置为640M,真正flush出来的storefile的大小可能是50M左右，没错，压缩比例就是这么大。

4 flush流程

为了减少flush过程对读写的影响，HBase采用了类似于两阶段提交的方式，将整个flush过程分为三个阶段：

(1)prepare阶段：遍历当前Region中的所有Memstore，将Memstore中当前数据集kvset做一个快照snapshot，然后再新建一个新的kvset。后期的所有写入操作都会写入新的kvset中，而整个flush阶段读操作会首先分别遍历kvset和snapshot，如果查找不到再会到HFile中查找。prepare阶段需要加一把updateLock对写请求阻塞，结束之后会释放该锁。因为此阶段没有任何费时操作，因此持锁时间很短。

(2)flush阶段：遍历所有Memstore，将prepare阶段生成的snapshot持久化为临时文件，临时文件会统一放到目录.tmp下。这个过程因为涉及到磁盘IO操作，因此相对比较耗时。

(3)commit阶段：遍历所有的Memstore，将flush阶段生成的临时文件移到指定的ColumnFamily目录下，针对HFile生成对应的storefile和Reader，把storefile添加到HStore的storefiles列表中，最后再清空prepare阶段生成的snapshot。

5. Flush对读写的影响

大部分Memstore Flush操作都不会对业务读写产生太大影响，比如这几种场景：HBase定期刷新Memstore、手动执行flush操作、触发Memstore级别限制、触发HLog数量限制以及触发Region级别限制等，这几种场景只会阻塞对应Region上的写请求，阻塞时间很短，毫秒级别。

然而一旦触发Region Server级别限制导致flush，就会对用户请求产生较大的影响。会阻塞所有落在该Region Server上的更新操作，阻塞时间很长，甚至可以达到分钟级别。一般情况下Region Server级别限制很难触发，但在一些极端情况下也不排除有触发的可能。

参考文献：https://mapr.com/blog/in-depth-look-hbase-architecture/

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