一,基本功能介绍
-root-表在HBase 0.9.6以后的版本被移除了。
Hbase 0.9.6以前,三个重要信息:
1,-root-表的位置存储在Zookeeper上(只会存在一个regionserver上),内容是.meta表的存储信息
2,.meta表存储在一个regionserver上,存储的是用户的表的region信息,用户表越大,这个表的region会越多,进而会分布到不同的regionserver。
3,用户的表信息,用户表示存储在各个regionserver上。
Hbase 0.9.6以后,移除了-root-表,用hbase:meta表代替了.meta表,hbase:meta表存的位置直接存储于Zookeeper上。
二,表内容介绍
1,-root-表结构
Key:
Key的格式为:.META.,,1
Values:
info:regioninfo: 序列化的hbase:meta表的HRegionInfo实例。
info:server:存储hbase:meta表的regionserver的server:port
info:serverstartcode:该Regionserver拥用hbase:meta表的起始时间
2,hbase:meta(.meta.)表结构
Key:
Region key的格式是:[table],[region start key],[region id]
Values:
info:regioninfo: 序列化的当前region的HRegionInfo实例。
info:server:存储这个region的regionserver的server:port
info:serverstartcode:该Regionserver拥用该region的起始时间
3,Zookeeper的存储位置
hbase:meta的存储节点为,直接获取其值(protocolbuffer序列化的):
/hbase/meta-region-server
4,数据访问流程
A),0.9.6以前的版本
Client--------->zookeeper--------->-ROOT-(单region)----->.META.------------->用户表region
比下面多了一个定位-ROOT-表的过程。
B),0.9.6及以后的版本
Client--------->zookeeper-------->hbase:meta--------->用户表region
Client的会从Zookeeper找到hbase:meta的位置,然后扫描该表找到我们需要请求的region信息,直接跟存储该region的regionserver建立连接,请求数据,而不是经由master。这些信息会被客户端缓存,避免多次请求,但是在master进行balance或者regionserver挂掉的话回去重新获取该信息。
三,总结
这样减少我们与master的交互,master只负责管理类的操作,数据的读写完全与其无关,减少了很多中间环节。只需要两次查找(找到hbase:meta位置和定位region),就可以定位到region,然后直接进行读写数据。数据的读写很类似kafka的,后面详细给大家对比。
那么,既然hbase:meta表这么重要,我们肯定会对其安全性及跟用户数据对比的一致性有很高的要求。那么下面提几点,大家都会关心:
1,hbase:meta所在的regionserver宕机了怎么办。
采用hdfs副本和wal技术。Hbase:meta所在的regionserver宕机后会重新分配给其它的regionserver。每次修改都会更新RS的wal的。
2,hbase:meta和用户region信息不一致怎么处理。
A),hbase提供的有修复指令。
B),可以根据源码去实现自己的修补指令。
元数据和用户实际的表信息不一致是很常见的现象,所以这两点后面会详细介绍。