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 位置信息。

说明如下：

1. Root Region永远不会被split，保证了最需要三次跳转，就能定位到任意Region 。
2. .META.表每行保存一个Region的位置信息，行键采用表名+表的最后一样编码而成。
3. 为了加快访问，.META.表的全部Region都保存在内存中。假设.META.表的一行在内存中大约占用1KB，并且每个Region限制为128MB，那么上面的三层结构可以保存的Region数目为：(128MB/1KB) * (128MB/1KB) = 2(34)个region。
4. 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带有内存中索引，合并的过程还是比较快。

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

1. Client向Region Server提交写请求。
2. Region Server找到目标Region。
3. Region检查数据是否与schema一致。
4. 如果客户端没有指定版本，则获取当前系统时间作为数据版本。
5. 将更新写入WAL log。
6. 将更新写入Memstore。
7. 判断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启动进行以下步骤：

1. 从Zookeeper上获取唯一一个代码Master的锁，用来阻止其它Master成为Master。
2. 扫描Zookeeper上的Server目录，获得当前可用的Region Server列表。
3. 和2中的每个Region Server通信，获得当前已分配的Region和Region Server的对应关系。
4. 扫描.META.region的集合，计算得到当前还未分配的Region，将他们放入待分配Region列表。

七、Master下线

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

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