Hbase regions在RegionServer上迁移原理解析

谁借莪１个温暖的怀抱￠ 2022-04-23 11:06 379阅读 0赞

### 1. 前言 ###

当Hbase集群中某个RegionServer挂掉之后，Hbase是如何把这台server上的regions迁移到其它的RegionServer上的呢？要弄清楚这个问题，首先要了解Hbase中Region的寻址机制，在此基础上来理解regions在RegionServer之间迁移的原理。

### 2. Region 寻址机制 ###

在Hbase中，读写操作都在 RegionServer 上发生，每个 RegionSever 为一定数量的 Region 服务，那么Client 要对某一行数据做读写的时候如何能知道具体要去访问哪个 RegionServer 呢？

#### 2.1 旧的Region寻址方式 ####

在 HBase-0.96 版本以前，HBase 有两个特殊的表，分别是`-ROOT-`表和`.META.`表，其中`-ROOT-`的位置存储在 ZooKeeper 中，`-ROOT-`本身存储了`.META.` 表的 RegionInfo 信息，并且`-ROOT-`不会分裂，只有一个 Region。而`.META.`表可以被切分成多个Region。读取的流程如下图所示：  
![在这里插入图片描述][20181227152739899]

**详细步骤：**

> 第 1 步：Client 请求 ZooKeeper 获得`-ROOT-`所在的 RegionServer 地址；  
> 第 2 步：Client 请求`-ROOT-`所在的 RS 地址，获取`.META.`表的地址，Client 会将`-ROOT-`的相关 信息 cache 下来，以便下一次快速访问；  
> 第 3 步：Client 请求`.META.`表的 RegionServer 地址，获取访问数据所在 RegionServer 的地址， Client 会将`.META.`的相关信息 cache 下来，以便下一次快速访问；  
> 第 4 步：Client 请求访问数据所在 RegionServer 的地址，获取对应的数据。

从上面的路径我们可以看出，用户需要 3 次请求才能直到用户 Table 真正的位置，这在一定 程序带来了性能的下降。在`0.96`之前使用 3 层设计的主要原因是考虑到元数据可能需要很 大。但是真正集群运行，元数据的大小其实很容易计算出来。在 BigTable 的论文中，每行 METADATA 数据存储大小为 1KB 左右，如果按照一个 Region 为 128M 的计算，3 层设计可以支持的 Region 个数为 `2^34` 个，采用 2 层设计可以支持 `2^17（131072）`。那么 2 层设计的情 况下一个集群可以存储 4P 的数据。这仅仅是一个 Region 只有 128M 的情况下。如果是 10G 呢? 因此，通过计算，其实 2 层设计就可以满足集群的需求。因此在 0.96 版本以后就去掉 了`-ROOT-`表了。

#### 2.2 新的Region寻址方式 ####

如上面的计算，2 层结构其实完全能满足业务的需求，因此 0.96 版本以后将`-ROOT-`表去掉了。 如下图所示：  
　　![在这里插入图片描述][20181227152739923]  
　　  
**寻址变成了3步：**

> 第 1 步：Client 请求 ZooKeeper 获取`.META.`所在的 RegionServer 的地址；  
> 第 2 步：Client 请求`.META.`所在的 RegionServer 获取访问数据所在的 RegionServer 地址，Client 会将`.META.`的相关信息 cache 下来，以便下一次快速访问；  
> 第 3 步：Client 请求数据所在的 RegionServer，获取所需要的数据。

#### 2.3 去掉-ROOT-的原因 ####

*  其一：提高性能
 *  其二：2 层结构已经足以满足集群的需求

这里还有一个问题需要说明，那就是 Client 会缓存`.META.`的数据，用来加快访问，既然有缓 存，那它什么时候更新？如果`.META.`更新了，比如 Region1 不在 RerverServer2 上了，被转移 到了 RerverServer3 上。Client 的缓存没有更新会有什么情况？

其实，Client 的元数据缓存不更新，当`.META.`的数据发生更新。如上面的例子，由于 Region1 的位置发生了变化，Client 再次根据缓存去访问的时候，会出现错误，当出现异常达到重试次数后就会去`.META.`所在的 RegionServer 获取最新的数据，如果`.META.`所在的 RegionServer 也变了，Client 就会去 ZooKeeper 上获取`.META.`所在的 RegionServer 的最新地址。

### 3. Regions迁移原理 ###

HBase基于Hadoop，RegionServer中的数据保存在HDFS上，默认情况下HDFS保存3份，会尽量放在3台机器上。所以当一台机器挂掉的情况下，HDFS层面会检查到这部分数据的复制份数不够，再复制一份出来到其它机器上去的。

#### 3.1 RegionServer 宕机时重新分配Region ####

RegionServer上的HFile和WAL都存储在HDFS上，当RegionServer 宕机的时候，数据是不会丢失的，丢失的只是Memstore中尚没有写入HFile的部分。RegionServer宕机后，该RegionServer所负责的Region就会变成不可用，HMaster就会根据集群的负载状况，将这些Region分配给其他RegionServer。

接手的RegionServer从zookeeper上的`-ROOT-`表（`0.96`之前版本Hbase）和`.META.`表上可以找到充分的元数据信息，那么RegionServer只需要根据这些信息组织起内存结构，并获取WAL文件进行重放，就可以最大程度的恢复到原来那台RegionServer宕机前的状态。

> 当然由于RegionServer通常和DataNode在一台服务器上，在写入时，也会调用本地的DFSClient写入，数据块会在本机有一个副本，在另外的机架上有一个副本，还有另外一个随机分配的副本，这样在读写时可以保证Data Locality。如果RegionServer接手了一个Region，那么大多数数据块不在本地的NameNode上，读写性能会有下降，但会在后续的Compact过程中逐渐将文件写入本地的DataNode，从而恢复Data Locality。当然由于HDFS少了一个DataNode，改DataNode上的数据块都少了一个副本，HDFS也会在其他的DataNode上重新建立这些副本，以保证可靠性。

### 4. 总结 ###

通过Hbase的寻址机制，可以知道Hbase找到RegionServer是向zookeeper请求`-ROOT-`表（`0.96`之前版本Hbase），然后找到`-META-`表，然后在`-META-`表里找到RegionServer信息。如果RegionServer挂了，`它把这个元数据，转移到其它活着的RegionServer上，然后把WAL日志分到其它RegionServer上去重新加载`。记住这里是元数据，数据本身是在hdfs上的，所以数据本身不会挂。元数据可以理解成对文件的索引，是放在内存中的。

--------------------

##### 参考： #####

[HBase学习之路 （七）HBase 原理][HBase_ _HBase]  
[知乎问答][Link 1]

[20181227152739899]: /images/20220320/a54c7a87434842e2a48c52e42ce7f460.png
[20181227152739923]: /images/20220320/79562f025f9c42d58325161854767f70.png
[HBase_ _HBase]: https://www.cnblogs.com/qingyunzong/p/8692430.html
[Link 1]: https://www.zhihu.com/question/20130759