HBase - ROOT 和 META 表结构 (region定位原理)

╰半橙微兮° 2022-01-16 22:55 256阅读 0赞

### **1. HBase读写流程** ###

![Image 1][]

上图是RegionServer数据存储关系图。上文提到，HBase使用MemStore和StoreFile存储对表的更新。数据在更新时首先写入HLog和MemStore。MemStore中的数据是排序的，当MemStore累计到一定阈值时，就会创建一个新的MemStore，并且将老的MemStore添加到Flush队列，由单独的线程Flush到磁盘上，成为一个StoreFile。与此同时，系统会在Zookeeper中记录一个CheckPoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致MemStore中的数据丢失，此时使用HLog来恢复CheckPoint之后的数据。

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

**1.1 写操作流程**

(1) **Client通过Zookeeper的调度，向RegionServer发出写数据请求，在Region中写数据**。

(2) **数据被写入Region的MemStore，直到MemStore达到预设阈值**。

(3) **MemStore中的数据被Flush成一个StoreFile**。

(4) **随着StoreFile文件的不断增多，当其数量增长到一定阈值后，触发Compact合并操作，将多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除**。

(5) **StoreFiles通过不断的Compact合并操作，逐步形成越来越大的StoreFile。**

**(6) 单个StoreFile大小超过一定阈值后，触发Split操作，把当前Region Split成2个新的Region。父Region会下线，新Split出的2个子Region会被HMaster分配到相应的RegionServer上，使得原先1个Region的压力得以分流到2个Region上**。

可以看出HBase只有增添数据，所有的更新和删除操作都是在后续的Compact历程中举行的，使得用户的写操作只要进入内存就可以立刻返回，实现了HBase I/O的高性能。

**1.2 读操作流程**

(1) Client访问Zookeeper，查找-ROOT-表，获取.META.表信息。

(2) 从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。

(3) 通过RegionServer获取需要查找的数据。

(4) **Regionserver的内存分为MemStore和BlockCache两部分**，**MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache**。

寻址过程：**client–>Zookeeper–>-ROOT-表–>META表–>RegionServer–>Region–>client**

### **HBase中有两个特殊的表：`-ROOT-`和`.META.`。** ###

### 2.ROOT表和META表 ###

**2.1 -ROOT-表结构**

HBase的用-**ROOT-表来记录.META.的Region信息**，就和.**META.记录用户表的Region信息一模一样**。-**ROOT-只会有一个Region。**

这么一来Client端就需要先去访问-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。这个地址被存在ZooKeeper中。默认的路径是：

/hbase/root-region-server

![Image 1][]

**2.2 .META.表结构**

![Image 1][]

**2.3 两个表的关系**

**HBase的所有Region元数据被存储在.META.表中2.1，随着Region的增多，.META.表中的数据也会增大，并分裂成多个新的Region。为了定位.META.表中各个Region的位置，把.META.表中所有Region的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息**。所有客户端访问用户数据前，**需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置**，如下图所示。

![Image 1][]

\-**ROOT-表永远不会被分割，它只有一个Region**，这样可以保证最多只需要三次跳转就可以定位任意一个Region。为了加快访问速度，.META.表的所有Region全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META.表在哪里。最后，如果前面的信息全部失效，则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的Region。

作者：liuzx32  
链接：https://www.jianshu.com/p/c4ed9792ecc2

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

### region定位原理 ###

在HBase中，大部分的操作都是在RegionServer完成的，Client端想要插入，删除，查询数据都需要先找到相应的RegionServer。什么叫相应的RegionServer？就是管理你要操作的那个Region的RegionServer。Client本身并不知道哪个RegionServer管理哪个Region，那么它是如何找到相应的RegionServer的？本文就是在研究源码的基础上揭秘这个过程。

在前面的文章“HBase存储架构”中我们已经讨论了HBase基本的存储架构。在此基础上我们引入两个特殊的概念：-ROOT-和.META.。这是什么？它们是HBase的两张内置表，从存储结构和操作方法的角度来说，它们和其他HBase的表没有任何区别，你可以认为这就是两张普通的表，对于普通表的操作对它们都适用。它们与众不同的地方是HBase用它们来存贮一个重要的系统信息——Region的分布情况以及每个Region的详细信息。

好了，既然我们前面说到**-ROOT-**和**.META.**可以被看作是两张普通的表，那么它们和其他表一样就应该有自己的表结构。没错，它们有自己的表结构，并且这两张表的表结构是相同的，在分析源码之后我将这个表结构大致的画了出来：

**-ROOT-和.META.表结构**

![\-ROOT-å.META.è¡¨ç»æ][-ROOT-_.META.]

我们来仔细分析一下这个结构，每条Row记录了一个Region的信息。

首先是RowKey，RowKey由三部分组成：**TableName, StartKey 和 TimeStamp**。RowKey存储的内容我们又称之为Region的Name。哦，还记得吗？我们在前面的文章中提到的，用来存放Region的文件夹的名字是RegionName的Hash值，因为RegionName可能包含某些非法字符。现在你应该知道为什么RegionName会包含非法字符了吧，因为StartKey是被允许包含任何值的。将组成RowKey的三个部分用逗号连接就构成了整个RowKey，这里TimeStamp使用十进制的数字字符串来表示的。这里有一个RowKey的例子：

Table1,RK10000,12345678

然后是表中最主要的Family：**info，info里面包含三个Column：regioninfo, server, serverstartcode**。其中regioninfo就是Region的详细信息，包括StartKey, EndKey 以及每个Family的信息等等。server存储的就是管理这个Region的RegionServer的地址。

所以当Region被拆分、合并或者重新分配的时候，都需要来修改这张表的内容。

到目前为止我们已经学习了必须的背景知识，下面我们要正式开始介绍Client端寻找RegionServer的整个过程。我打算用一个假想的例子来学习这个过程，因此我先构建了假想的-ROOT-表和.META.表。

我们先来看.META.表，假设HBase中只有两张用户表：Table1和Table2，Table1非常大，被划分成了很多Region，因此在.META.表中有很多条Row用来记录这些Region。而Table2很小，只是被划分成了两个Region，因此在.META.中只有两条Row用来记录。这个表的内容看上去是这个样子的：

**.META.行记录结构**

![.META.行记录结构][.META.]

现在假设我们要从Table2里面插寻一条RowKey是RK10000的数据。那么我们应该遵循以下步骤：

1. 从.META.表里面查询哪个Region包含这条数据。

2. 获取管理这个Region的RegionServer地址。

3. 连接这个RegionServer, 查到这条数据。

好，我们先来第一步。问题是.META.也是一张普通的表，我们需要先知道哪个RegionServer管理了.META.表，怎么办？有一个方法，我们把管理.META.表的RegionServer的地址放到ZooKeeper上面不久行了，这样大家都知道了谁在管理.META.。

貌似问题解决了，但对于这个例子我们遇到了一个新问题。因为Table1实在太大了，它的Region实在太多了，.META.为了存储这些Region信息，花费了大量的空间，自己也需要划分成多个Region。这就意味着可能有多个RegionServer在管理.META.。怎么办？在ZooKeeper里面存储所有管理.META.的RegionServer地址让Client自己去遍历？HBase并不是这么做的。

HBase的做法是用另外一个表来记录.META.的Region信息，就和.META.记录用户表的Region信息一模一样。这个表就是-ROOT-表。这也解释了为什么-ROOT-和.META.拥有相同的表结构，因为他们的原理是一模一样的。

假设.META.表被分成了两个Region，那么-ROOT-的内容看上去大概是这个样子的：

**-ROOT-行记录结构**

![\-ROOT-行记录结构][-ROOT-]

这么一来Client端就需要先去访问-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。这个地址被存在ZooKeeper中。默认的路径是：

/hbase/root-region-server

等等，如果-ROOT-表太大了，要被分成多个Region怎么办？嘿嘿，HBase认为-ROOT-表不会大到那个程度，因此-ROOT-只会有一个Region，这个Region的信息也是被存在HBase内部的。

现在让我们从头来过，我们要查询Table2中RowKey是RK10000的数据。整个路由过程的主要代码在org.apache.hadoop.hbase.client.HConnectionManager.TableServers中：

private HRegionLocation locateRegion(final byte[] tableName,  
            final byte[] row, boolean useCache) throws IOException {  
        if (tableName == null || tableName.length == 0) {  
            throw new IllegalArgumentException("table name cannot be null or zero length");  
        }  
        if (Bytes.equals(tableName, ROOT_TABLE_NAME)) {  
            synchronized (rootRegionLock) {  
                // This block guards against two threads trying to find the root  
                // region at the same time. One will go do the find while the  
                // second waits. The second thread will not do find.  
                if (!useCache || rootRegionLocation == null) {  
                    this.rootRegionLocation = locateRootRegion();  
                }  
                return this.rootRegionLocation;  
            }  
        } else if (Bytes.equals(tableName, META_TABLE_NAME)) {  
            return locateRegionInMeta(ROOT_TABLE_NAME, tableName, row, useCache, metaRegionLock);  
        } else {  
            // Region not in the cache – have to go to the meta RS  
            return locateRegionInMeta(META_TABLE_NAME, tableName, row, useCache, userRegionLock);  
        }  
    }

这是一个递归调用的过程：

获取Table2，RowKey为RK10000的RegionServer 
    => 获取.META.，RowKey为Table2,RK10000, 99999999999999的RegionServer 
    => 获取-ROOT-，RowKey为.META.,Table2,RK10000,99999999999999,99999999999999的RegionServer 
    => 获取-ROOT-的RegionServer => 从ZooKeeper得到-ROOT-的RegionServer 
    => 从-ROOT-表中查到RowKey最接近（小于） .META.,Table2,RK10000,99999999999999,99999999999999的一条Row，并得到.META.的RegionServer 
    => 从.META.表中查到RowKey最接近（小于）Table2,RK10000, 99999999999999的一条Row，并得到Table2的RegionServer => 从Table2中查到RK10000的Row

不是很难理解。

最后要提醒大家注意两件事情：

1. **在整个路由过程中并没有涉及到MasterServer**，也就是说HBase日常的数据操作并不需要MasterServer，不会造成MasterServer的负担。

2. Client端并不会每次数据操作都做这整个路由过程，很多数据都会被Cache起来。至于如何Cache，则不在本文的讨论范围之内。

[Image 1]: 
[-ROOT-_.META.]: /images/20220117/d9c70c148c9c490198f7f7cf83512a87.png
[.META.]: /images/20220117/1cd25c9d0d374d0bbc311e508f525505.png
[-ROOT-]: /images/20220117/427bcab147be4f408e455b463fdb6eb5.png