HBase架构核心模块

Posted 2021-04-19 ITPUB

Hbase物理模型架构体系

     

hbase工作流程

HRegionServer负责打开region，并创建HRegion实例，它会为每个表的HColumnFamily（用户创建表时定义的）创建一个 Store实例，每个Store实例包含一个或多个StoreFile实例。是实际数据存储文件HFile的轻量级封装，每个Store会对应一个 MemStore。写入数据时数据会先写入Hlog中成功后在写入MemStore中。Memstore中的数据因为空间有限，所以需要定期flush到文件StoreFile中，每次flush都是生成新的StoreFile。HRegionServer在处理Flush请求时，将数据写成HFile文件永久存储到HDFS上，并且存储最后写入的数据序列号。

Client 

整合HBase集群的入口

使用HBase RPC机制与HMaster和HRegionserver通信

与HMaster通信进行管理类的操作

与HRegionserver通信进行读写类操作

包含访问hbase 的接口，client 维护着一些cache 来加快对hbase 的访问，比如regione 的位置信息

Zookeeper

保证任何时候，集群中只有一个running master，Master与RegionServers启动时会向ZooKeeper注册默认情况下，HBase 管理ZooKeeper 实例，比如，启动或者停止ZooKeeperZookeeper的引入使得Master不再是单点故障存贮所有Region 的寻址入口

实时监控RegionServer 的状态，将Regionserver 的上线和下线信息，实时通知给Master存储Hbase的schema和table元数据

Master

管理用户对Table的增删改查操作

在RegionSplit后，分配新region的分配

负责regionserver的负载均衡，调整region分布

在RegionServer停机后，负责失效Regionserver上region的重新分配

HMaster失效仅会导致所有元数据无法修改，表达数据读写还是可以正常运行

Region Server

Regionserver维护region，处理对这些region的IO请求

Regionserver负责切分在运行过程中变得过大的region

由上图可以看出，client 访问hbase上数据的过程并不需要master 参与，寻址访问先zookeeper再regionserver，数据读写访问regioneserver。

HRegionServer主要负责响应用户I/O请求，向HDFS文件系统中读写数据，是HBase中最核心的模块。

物理存储

     
1.table中的所有行都是按照rowkey的字典排序

2.table在行的方向上分割为多个Region

3.Region按大小分割，每个表开始只有一个region，随着数据增多，region不断增大，但到达阈值时，region就会分割成两个新的region，因此region会越来越多。

     

4.region是hbase中分布式存储和负载均衡的最小单元，不同的regioon分布到不同的regionserver上，但Region不会拆分到不同的Region Server上。

Table 在行的方向上分割为多个HRegion，一个region由[startkey,endkey)表示

     

Region是分布式存储的最小单元，但不是存储的最小的单元。

    1. region由一个或多个Store组成，每个Store保存一个columnfamily

    2. 每个Store又由一个memStore和0个或多个StoreFile组成

    3. memStore存储在内存中，StoreFile存储在HDFS上

Table中Region内部结构

     

1.一个表会按照行（看数据量）划分为若干个region每一个region分配给一台特定的regionserver管理

2.每一个region内部还要依据列族划分为若干个HStore

3.每个HStore中的数据会落地到若干个HFILE文件中

4.region体积会随着数据插入而不断增长，到一定阈值后会分裂

5.随着region的分裂，一台regionserver上管理的region会越来越多

6.HMASTER会根据regionserver上管理的region数做负载均衡

7.region中的数据拥有一个内存缓存：memstore，数据的访问优先在memstore中进行

8.memstore中的数据因为空间有限，所以需要定期flush到文件storefile中，每次flush都是生成新的storefile

9.storefile的数量随着时间也会不断增加，regionserver会定期将大量storefile进行合并（merge）

StoreFile

      

Data Block 段–保存表中的数据，这部分可以被压缩

Meta Block 段 (可选的)–保存用户自定义的kv对，可以被压缩。

File Info 段–Hfile的元信息，不被压缩，用户也可以在这一部分添加自己的元信息。

Data Block Index 段–Data Block的索引。每条索引的key是被索引的block的第一条记录的key。

Meta Block Index段 (可选的)–Meta Block的索引。

Trailer–这一段是定长的。保存了每一段的偏移量，读取一个HFile时，会首先读取Trailer，Trailer保存了每个段的起始位置(段的Magic Number用来做安全check)，然后，DataBlock Index会被读取到内存中，这样，当检索某个key时，不需要扫描整个HFile，而只需从内存中找到key所在的block，通过一次磁盘io将整个block读取到内存中，再找到需要的key。DataBlock Index采用LRU机制淘汰。

HFile的Data Block，Meta Block通常采用压缩方式存储，压缩之后可以大大减少网络IO和磁盘IO，随之而来的开销当然是需要花费cpu进行压缩和解压缩。目标Hfile的压缩支持两种方式：Gzip，Lzo。

HFile格式

     

HFile文件长度不固定，长度固定的块只有两个：Trailer和FileInfo

Trailer中指针指向其他数据块的起始点，它是在持久化数据到文件结束时写入的，即确定为不可变的存储文件。

File Info中记录了文件的一些Meta信息，例如：

AVG_KEY_LEN,AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等

Data Index和Meta Index块记录了每个Data块和Meta块的起始点

Data Block是HBase I/O的基本单元，为了提高效率，HRegionServer中有基于LRU的Block Cache机制。

每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询.

每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字，目的是防止数据损坏。

 HFile里面的每个KeyValue对就是一个简单的byte数组。这个byte数组里面包含了很多项，并且有固定的结构。

KeyValue格式

     

KeyLength和ValueLength：两个固定的长度，分别代表Key长度和Value的长度，因此可以忽略键直接访问，用户可以实现在数据中跳跃。

Key部分：Row Length是固定长度的数值，表示RowKey的长度，Row 就是RowKey，Column Family Length是固定长度的数值，表示Family的长度接着就是Column Family，再接着是Qualifier，然后是两个固定长度的数值，表示Time Stamp和Key Type（Put/Delete）

Value部分没有这么复杂的结构，就是纯粹的二进制数据

Zookeeper的作用

     

1.HBase依赖ZooKeeper，默认情况下，HBase管理ZooKeeper（开启和关闭）

2.Master与RegionServer启动时会向Zookeeper注册。

3.Zookeeper的引入使得Master不再是单点故障。

Redion定位

     

 寻找RegionServer

1.ZooKeeper（可以找到ROOT表的位置）

2. -ROOT-（只会存储在一个region上，从ROOT表上找到.META表的位置）

3.META（存储了用户世实际存储的位置，如用户表）

4.用户表

-ROOT-

1.表包含.META.表所在的region列表，该表只会存储在一个表中

2.ZooKeeper中记录了-ROOT-表的location

 因此访问流程为Client访问用户数据之前需要首先访问zookeeper，然后访问-ROOT-表，接着问.META.表，最后才能找到用户数据的位置去访问。

HBase容错性

Master容错：Zookeeper重新选择一个新的Master

1.无Master过程中，数据读取仍照常进行；

2.无master过程中，region切分、负载均衡等无法进行；

RegionServer容错：定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，

1.Master将该RegionServer上的Region重新分配到其他RegionServer上，

2.失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer

Zookeeper容错：Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例

Write-Ahead-Log 

     

 Write-Ahead-Log  该机制用于数据的容错和恢复：

每个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中（HLog文件格式见后续），HLog文件定期会滚动出新的，并 删除旧的文件（已持久化到StoreFile中的数据）。

当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的 HLog文件，将 其中不同Region的Log数据进行拆分，分别放到相应region的目录下，然后再将失效的region重新分配，领取到这些region的 HRegionServer在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复

Write-Ahead-Log(WAL)预写日志

1.Client向RegionServer端提交数据的时候，会优先写WAL日志(WAL)，当WAL日志写入成功后，Client才会被告知提交数据成功，如果写入WAL失败，会告诉客户端提交失败。可以通过WAL日志恢复失败的数据。

2.一个Regionserver上所有的Region都共享一个HLog,一次提交先写WAL，在写memStore。

本文来自ITPUB技术博客。

博主：熊深圳

http://blog.itpub.net/30172158/viewspace-2112863/