HBase的Region定位

Region定位:

系统如何找到某个row key (或者某个 row key range)所在的region

关于Region的查找,早期的设计(0.96.0)之前是被称之为三层查询架构,如下图所示:

HBase的Region定位_第1张图片

Region:就是要查找的数据所在的Region

.META.是一张元数据表,记录了用户表的Region信息以及RegionServer的服务器地址.META.可以有多个regoin.META.表中的一行记录就是一个Region,记录了该Region的起始行、结束行和该Region的连接信息。

-ROOT-是一张存储.META.表的表,记录了.META.表的Region信息,-ROOT-只有一个region

 

Client访问用户数据之前需要首先访问zookeeper,然后访问-ROOT-表,接着访问.META.表,最后才能找到用户数据的位置去访问,中间需要多次网络操作,不过client端会做cache缓存。

步骤:

(1)用户通过查找zkzookeeper)的/hbase/root-region-server节点来知道-ROOT-表在什么RegionServer上。

(2)访问-ROOT-表,查看需要的数据在哪个.META.表上,这个.META.表在什么RegionServer上。

(3)访问.META.表查看查询的行健在什么Region范围里面。

(4)连接具体的数据所在的RegionServer,这回就真的开始用Scan来遍历row了。

 

说明:

.META.表每行保存一个region的位置信息,row key 采用表名+表的最后一样编码而成。

为了加快访问,.META.表的全部region都保存在内存中。

假设,.META.表的一行在内存中大约占用1KB。并且每个region限制为128MB

那么上面的三层结构可以保存的region数目为:

(128MB/1KB) * (128MB/1KB) = = 2^32region

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


实际上.META.表一直就只有一个,所以-ROOT-中的记录一直都只有一行,-ROOT-表形同虚设。而且,三层机构增加了代码的复杂度,容易产生BUG。
从0.96版本以后,三层架构被改为二层架构,-ROOT-表被去掉了,同时zk中的/hbase/root-region-server也被去掉了。直接把.META.表所在的RegionServer信息存储到了zk中的/hbase/meta-region-server去了。再后来引入了namespace,.META.表这样别扭的名字被修改成了hbase:meta。

HBase的Region定位_第2张图片

HBase的Region定位_第3张图片

二层架构的定位步骤如下:

1)用户通过查找zkzookeeper)的/hbase/meta-region-server节点查询哪台RegionServer上有hbase:meta表。

2)客户端连接含有hbase:meta表的RegionServerHbase:meta表存储了所有Region的行健范围信息,通过这个表就可以查询出你要存取的rowkey属于哪个Region的范围里面,以及这个Region又是属于哪个RegionServer

3)获取这些信息后,客户端就可以直连其中一台拥有你要存取的rowkeyRegionServer,并直接对其操作。

4)客户端会把meta信息缓存起来,下次操作就不需要进行以上加载HBase:meta的步骤了。

你可能感兴趣的:(大数据类)