Region的name：
<表名,startRowkey,创建时间>， 如：quote_data,3,1473384408919
（因此一个region只能记录一个表？一个表可以有多个 region，但是一个region只能记录一个表的数据？？？）
（1）0.94- 版本
之前讲到，Zookeeper中记录了所有Region的寻址入口，此处说的是入口（此处入口其实指的是.META.表的存放位置信息），不是真正的Region地址。真正的地址存放在.META.表中
HBASE中有两张特殊的表：.META. 和-ROOT-表，这两张表跟HBase其它表在访问上没有任何区别，只是他们记录了HBase中的系统信息。Region分配到那个Region Server是随机的，因此需要一种机制对Region进行定位。
用户表的所有Region信息记录在.META.表中，表中的一条记录对应一条region的详细信息，包括server的具体地址等：
--Rowkey：Region的name，其中包含了表名等信息
--Column Family：info， 包含了如下三列：regioninfo,server和serverstartcode。 其中 regioninfo包含了 NAME, STARTKEY, ENDKEY 等信息。
当用户表非常大的时候，.META.的region也会不断增加，HBase引入了第二张特殊表-ROOT-，用来记录.META.的Region信息。-ROOT-表的结构与.META.的结构一样。
由于只有一个region，regioninfo字段中的开始字段startkey和结束字段endkey都为空。
根据region的命名规则，知道-ROOT-中记录的都是.META.表的信息，所以从上图可以看到-ROOT-的rowkey类似于.META.,,1,只是它的rowkey里没有时间戳，而直接是一个数字。
那么如果-ROOT-表太大了，要被分成多个Region怎么办？HBase认为-ROOT-表不会大到那个程度，因此-ROOT-只会有一个Region，这个Region的信息也是被存在HBase内部的，具体是存放在Zookeeper中 /hbase/rs下的，因为-Root-表的Region只有一个，所以不存在寻址问题，直接记录在Zookeeper中，寻址过程如图所示：
可以将-ROOT-表看成是简表，.META.表看成是详表：
这就是HBase的三级定位寻址法（最多三次，如果已经在Memstore中就不需要再访问这么多次了）
（2）0.96+版本
hbase0.96版本后删除了root 表，因为觉的目的是根据root表获取meta地址，过程是通过zookeeper获取root表地址，再根据root表记录meta表地址进行访问，还不如和zookeeper通讯一次。新增了namespace，详细见patch设计。
同时将.META.表重命名为：hbase:meta （放在名为hbase的表空间下）, 在hbase:meta表中的column family info中增加了一列：seqnumDuringOpen. 而且rowkey(region 的name ）重新定义如下：
<表名,startRowkey,创建时间时间戳+"."+encode值+"."> （旧版的不包含encoded值）
如下为hbase:meta表的一条记录：rowkey=iqm:instrument_common_index,66666660,1474393055082.adcf19159f1116c6e1e194b3d10a7c79., 该记录的encoded值为： adcf19159f1116c6e1e194b3d10a7c79
- startKey，region的开始key，第一个region的startKey是空字符串；
- endKey，region的结束key，最后一个region的endKey是空字符串；
- encode值，该值会作为hdfs文件系统的一个目录，假设encode值为： da1aec29c13725e29786e920bcc2d7b0 ，存放如下如图：
- 用来存放region的文件夹的名字是region name的哈希值，因为region的name中有startkey，所以可能含有非法字符，所以取它的hash值来作为目录名称存放region文件。
改造后的寻址示意图如下：
