HBase读写流程

【写流程】

1、Client先从缓存中定位region，如果没有缓存则需访问zookeeper，从.META.表获取要写入的region信息

2、找到小于rowkey并且最接近rowkey的startkey对应的region

3、将更新写入WAL中。当客户端发起put/delete请求时，考虑到写入内存会有丢失数据的风险，因此在写入缓存前，HBase会先写入到Write Ahead Log（WAL）中（WAL存储在HDFS中），那么即使发生宕机，也可以通过WAL还原初始数据。

4、将更新写入memstore中，当增加到一定大小，达到预设的Flush size阈值时，会触发flush memstore，把memstore中的数据写出到hdfs上，生成一个storefile。

5、随着Storefile文件的不断增多，当增长到一定阈值后，触发compact合并操作，将多个storefile合并成一个，同时进行版本合并和数据删除。

6、storefile通过不断compact合并操作，逐步形成越来越大的storefile。

7、单个stroefile大小超过一定阈值后，触发split操作，把当前region拆分成两个，新拆分的2个region会被hbase master分配到相应的2个regionserver上。

【读流程】

1、Client先从缓存中定位region，如果没有缓存则需访问zookeeper，查询.-ROOT-.表，获取.-ROOT-.表所在的regionserver地址。

2、通过查询.-ROOT-.的region服务器 获取 含有.-META-.表所在的regionserver地址。

3、clinet会将保存着regionserver位置信息的元数据表.META.进行缓存，然后在表中确定待检索rowkey所在的regionserver信息。

4、client会向在.META.表中确定的regionserver发送真正的数据读取请求。

5、先从memstore中找，如果没有，再到storefile上读。

补存：
Master工作机制
 
  master启动进行以下步骤: 
1 从zookeeper上获取唯一一个代表active master的锁，用来阻止其它master成为master。 
2 扫描zookeeper上的server父节点，获得当前可用的region server列表。 
3 和每个region server通信，获得当前已分配的region和region server的对应关系。 
4 扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。

  master宕机 
由于master只维护表和region的元数据，而不参与表数据IO的过程，master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region 上下线，无法进行region的合并，唯一例外的是region的split可以正常进行，因为只有region server参与)，表的数据读写还可以正常进行。因此master下线短时间内对整个hbase集群没有影响。 
从上线过程可以看到，master保存的信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来） 
因此，一般hbase集群中总是有一个master在提供服务，还有一个以上的‘master’在等待时机抢占它的位置。