HBase关键算法/流程

一、Region定位

系统如何找到某个行键（或者某个行键范围）所在的Region？

Hbase 中有两张特殊的表：-ROOT-和.META.
.META.：记录了用户表的Region信息，.META.可以有多个regoin
-ROOT-：记录了.META.表的Region信息，-ROOT-只有一个region
Zookeeper 中记录了-ROOT-表的location
Client 访问用户数据之前需要首先访问Zookeeper，然后访问-ROOT-表，接着访问.META.表，最后才能找到用户数据的位置去访问。
底层设计如下：

BigTable使用三层类似B+树的结构来保存Region位置。第一层保存Zookeeper里面的文件，它持有Root Region的位置。第二层Root Region是.META.表的第一个Region，其中保存了.META.表其它Region的位置。通过Root Region，我们就可以访问.META.表的数据。第三层是.META.，它是一个特殊的表，保存了hbase中所有数据表的Region位置信息。

说明如下：

Root Region永远不会被split，保证了最需要三次跳转，就能定位到任意Region。

.META.表每行保存一个Region的位置信息，行键采用表名+表的最后一样编码而成。

为了加快访问，.META.表的全部Region都保存在内存中。假设.META.表的一行在内存中大约占用1KB，并且每个Region限制为128MB，那么上面的三层结构可以保存的Region数目为：(128MB/1KB) * (128MB/1KB) = 2(34)个region。

Client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果Client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的Region（其中三次用来发现缓存失效，另外三次用来获取位置信息）。

二、读写过程

HBase使用MemStore和StoreFile存储对表的更新。

数据在更新时首先写入Log（WAL log）和内存（MemStore）中，MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到flush队列，由单独的线程flush到磁盘上，成为一个StoreFile。于此同时，系统会在Zookeeper中记录一个redo point，表示这个时刻之前的变更已经持久化了。

当系统出现意外时，可能导致内存（MemStore）中的数据丢失，此时使用Log（WAL log）来恢复检查点之后的数据。

前面提到过StoreFile是只读的，一旦创建后就不可以再修改。因此HBase的更新其实是不断追加的操作。当一个Store中的StoreFile达到一定的阈值后，就会进行一次合并，将对同一个key的修改合并到一起，形成一个大的StoreFile，当StoreFile的大小达到一定阈值后，又会对StoreFile进行split，等分为两个StoreFile。

HBase其实只有增加数据，所有的更新和删除操作都是在后续的合并 过程中进行的。例如删除操作，对某一个行键进行删除，只是单纯的对该行键添加一个删除标记，并没有真正的删除，只有在合并Store File的时候才会根据标识进行删除。

由于对表的更新是不断追加的，处理读请求时， 需要访问Store中全部的StoreFile和MemStore，将他们的按照行键进行合并，由于StoreFile和MemStore都是经过排序的，并且StoreFile带有内存中索引，合并的过程还是比较快。

写请求处理过程如下图所示：

Client向Region Server提交写请求。

Region Server找到目标Region。

Region检查数据是否与schema一致。

如果客户端没有指定版本，则获取当前系统时间作为数据版本。

将更新写入WAL log。

将更新写入Memstore。

判断Memstore的是否需要flush为Store文件。

三、Region分配

任何时刻，一个Region只能分配给一个Region Server。Master记录了当前有哪些可用的Region Server、当前哪些Region分配给了哪些Region Server以及哪些Region还没有分配。

当存在未分配的Region，并且有一个Region Server上有可用空间时，Master就给这个Region Server发送一个装载请求，把Region分配给这个Region Server。Region Server得到请求后，就开始对此Region提供服务。

四、Region Server上线

Master使用Zookeeper来跟踪Region Server状态。当某个Region Server启动时，会首先在Zookeeper上的Server目录下建立代表自己的文件，并获得该文件的独占锁。

由于Master订阅了Server目录上的变更消息，当Server目录下的文件出现新增或删除操作时，Master可以得到来自Zookeeper的实时通知。因此一旦Region Server上线，Master能马上得到消息。

五、Region Server下线

当Region Server下线时，它和Zookeeper的会话断开，Zookeeper而自动释放代表这台Server的文件上的独占锁。而Master不断轮询Server目录下文件的锁状态。

如果Master发现某个Region Server丢失了它自己的独占锁（或者Master连续几次和Region Server通信都无法成功），Master就尝试去获取代表这个Region Server的读写锁，一旦获取成功，就可以确定以下两种情况必至少发生一种：1、Region Server和Zookeeper之间的网络断开了；2、Region Server挂了。

无论哪种情况，Region Server都无法继续为它的Region提供服务了，此时Master会删除Server目录下代表这台Region Server的文件，并将这台Region Server的Region分配给其它还活着的同志。

如果网络短暂出现问题导致Region Server丢失了它的锁，那么Region Server重新连接到Zookeeper之后，只要代表它的文件还在，它就会不断尝试获取这个文件上的锁，一旦获取到了，就可以继续提供服务。

六、Master上线

Master启动进行以下步骤：

从Zookeeper上获取唯一一个代码Master的锁，用来阻止其它Master成为Master。

扫描Zookeeper上的Server目录，获得当前可用的Region Server列表。

和2中的每个Region Server通信，获得当前已分配的Region和Region Server的对应关系。

扫描.META.region的集合，计算得到当前还未分配的Region，将他们放入待分配Region列表。

七、Master下线

由于Master只维护表和Region的元数据，而不参与表数据I/O的过程，Master下线仅导致所有元数据的修改被冻结（无法创建删除表，无法修改表的schema，无法进行Region的负 载均衡，无法处理Region上下线，无法进行Region的合并，唯一例外的是Region的split可以正常进行，因为只有region server参与），表的数据读写还可以正常进行。因此Master下线短时间内对整个HBase集群没有影响。

从上线过程可以看到，Master保存的信息全是可以冗余信息（都可以从系统其它地方收集到或者计算出来），因此，一般HBase集群中总是有一个master在提供服务，还有一个以上的“Master”在等待时机抢占它的位置