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

╰+攻爆jí腚メ 2023-01-17 09:20 256阅读 0赞

**一，基本功能介绍**

\-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.)表结构**

## 1.meta表存储了在系统上的一系列的region信息。以及meta表的信息存储在zookeeper上。 ##

## 2.meta表结构如下（默认列族为info） ： ##

Key：
    Region key of the format ([table表名],[region start key起始键],[region id])
    
    Values：
    序列化的regioninfo实例
    info:regioninfo (serialized HRegionInfo instance for this region)
    
    包含此region的regionserver
    info:server (server:port of the RegionServer containing this region)
    
    包含此region的regionserver的进程开始时间
    info:serverstartcode (start-time of the RegionServer process containing this region)

## 3.meta表实例数据展示： ##

hbase(main):148:0> scan 'hbase:meta'
    ROW  COLUMN+CELL 
     hbase:namespace,,1512106581988.18a0600b197d7313 column=info:regioninfo, timestamp=1512106686993, value={ENCODED => 18a0600b197d73133f8cdeeca1d9bbe2, NAME => 'hbase:namespace,,1512106581988
     3f8cdeeca1d9bbe2.   .18a0600b197d73133f8cdeeca1d9bbe2.', STARTKEY => '', ENDKEY => ''}  
     hbase:namespace,,1512106581988.18a0600b197d7313 column=info:seqnumDuringOpen, timestamp=1512106686993, value=\x00\x00\x00\x00\x00\x00\x00\x0B   
     3f8cdeeca1d9bbe2.   
     hbase:namespace,,1512106581988.18a0600b197d7313 column=info:server, timestamp=1512106686993, value=slave-1:16020
     3f8cdeeca1d9bbe2.   
     hbase:namespace,,1512106581988.18a0600b197d7313 column=info:serverstartcode, timestamp=1512106686993, value=1512106679061   
     3f8cdeeca1d9bbe2.

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

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

[HBase]: https://cloud.tencent.com/product/hbase?from=10680