Hbase源码系列之源码前奏hbase:meta表相关详细介绍

一，基本功能介绍

-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),可以根据源码去实现自己的修补指令。

元数据和用户实际的表信息不一致是很常见的现象，所以这两点后面会详细介绍。