Region 定位(1)

Region就是HBase架构的灵魂。

---

Client在读写的时候是怎么定位到RegionServer的？？？

三层查询架构

关于Region的查找，0.96.0版本之前是被称为三层查询架构

• Region：就是要查找的数据所在的Region
• .META.：是一张元数据表，它存储了所有Region的简要信息。.META.表中的一行记录就是一个Region，该行记录了该Region的起始行、结束行和该Region的连接信息，这样客户端就可以通过这个来判断需要的数据在哪个Region上。
• -ROOT-：是一张存储.META.表的表。.META.可以有很多张，而-ROOT-就是存储了.META.表在什么Region上的信息（.META.表也是一张普通的表，也在Region上）。

通过两层的扩展最多可以支持次幂个Region。即17179869184个，约等于171亿个Region。

通过查询ZooKeeper的/hbase/root-region-server节点来获取-ROOT-表所在的RegionServer。

所以Client查找数据的流程从宏观角度来看是这样的：

（1）用户通过查找zk（ZooKeeper）的/hbase/root-region-server节点来知道-ROOT-表在什么RegionServer上。
（2）访问-ROOT-表，看需要的数据在哪个.META.表上，这个.META.表在什么RegionServer上。
（3）访问.META.表来看你要查询的行键在什么Region范围里面。
（4）连接具体的数据所在的RegionServer，这回就真的开始用Scan来遍历row了。

总体流程如下图：

三层架构的弊端

（1）通过三层架构虽然极大地扩展了可以容纳的Region数量，一直扩展到了171亿个 Region，但是实际情况中是用不到这么多的region的。
（2）虽然设计上是允许多个.META.表存在的，但是实际上在HBase的发展历史中，.META.表一直只有一个，所以-ROOT-中的记录一直都只有一行，-ROOT-表形同虚设。
（3）三层架构增加了代码的复杂度，容易产生BUG。

二层查询架构

从0.96版本之后这个三层查询架构被改成了二层查询架构。-ROOT-表被去掉了，同时zk中的/hbase/root-region-server也被去掉了。直接把.META.表所在的RegionServer信息存储到了zk中的/hbase/meta-region-server节点。
再后来引入了namespace，.META.表这样别扭的名字被修改成了hbase:meta。

二层查询架构如下图所示

（1）客户端先通过ZooKeeper的/hbase/meta-region-server节点查询到哪台RegionServer上有hbase:meta表。
（2）客户端连接含有hbase:meta表的RegionServer。hbase:meta表存储了所有Region的行键范围信息，通过这个表就可以查询出要存取的rowkey属于哪个Region的范围里面，以及这个Region又是属于哪个RegionServer。关于hbase:meta表的结构参见hbase:meta表结构
（3）获取这些信息后，客户端就可以直连其中一台拥有要存取的rowkey的RegionServer，并直接对其操作。
（4）客户端会把meta信息缓存起来，下次操作就不需要进行以上加载hbase:meta的步骤了。

---

《Hbase不睡觉书》笔记