Hbase就不介绍了，直入正题。
为了让客户端找到包含特定主键的region，Hbase0.96之前提供了两张特殊的目录表-ROOT-和.META表，一下简称root和meta。
root表用来查询所有meta表中热region的位置。meta表则是用来查找所有table的region的位置。Hbase原来的设计中只有一个root region，则root从不拆分，从而保证类似于B+树结构的三层查找结构：第一层是zookeeper中包含root region位置信息的节点，第二层是从root表中查找对应meta表的region的位置，第三层是从meta表中查找用户表对应region的位置。
这次不讲region表的构成和怎么查找。
既然0.96之前是这么做的，那为什么只有就舍弃了呢？接下来就好好分析分析。
BigTable的论文论述了meta的region大小为128M时，可以定位2^34个region，这是怎么计算的呢？
假设纪录每个meta位置的一行纪录是1kB，每个region大小是128M(实际可能更大)，那么meta表就能纪录128M/1kB个region，即217个，再加上root表，只有一个region，所以也是128M/1kB，这样，一个region的root和一个region的meta，就可以定位217*217，即234个region，假设每个region128M，那么2ZB的数据都可以定位，这个在一个HBase集群中2ZB是不可想象的，这还是按照最小的情况。
除了三层架构定位的数据过多之外，还有网络请求的原因。
虽然客户端缓存了region的地址，但是初始化需求的时候需要重新查找region，例如：当缓存过期了，并发生了region的拆分、合并或者移动。客户端使用递归查找的方式从目录中重新定位当前region的位置，它从对应的meta表region中查找对应行键的地址。如果对应的meta的region地址无效，它就向root请求当前对应meta表的职位，最后，如果连root都没有用了，就回向zookeeper节点查询root表的新地址。
在最坏的情况下，客户端需要6次网络往返请求来定位一个用户region，这也是三层架构的一个弊端之一。
所以，在0.96之后，将root表去接去掉了，我们再来看看。
没有了root表，直接从meta查询，和上面条件一个，假设一个region有128M，一行地址数据1KB，那么就可以定位128M/1kB个region，有2^24的大小，有16T，因为meta表肯定不止一个region，一个region肯定不止128M，所以，从meta来定位的数据大小远大于16T，对于一个Hbase集群来说，完全够了。
而且，少了一层root，网络请求次数肯定会减少，这也是优势之一。
二层架构的定位步骤如下：
（1）用户通过查找zk（zookeeper）的/hbase/meta-region-server节点查询哪台RegionServer上有hbase:meta表。
（2）客户端连接含有hbase:meta表的RegionServer。Hbase:meta表存储了所有Region的行健范围信息，通过这个表就可以查询出你要存取的rowkey属于哪个Region的范围里面，以及这个Region又是属于哪个RegionServer。
（3）获取这些信息后，客户端就可以直连其中一台拥有你要存取的rowkey的RegionServer，并直接对其操作。
（4）客户端会把meta信息缓存起来，下次操作就不需要进行以上加载HBase:meta的步骤了。