HBase架构设计及原理分析

我们从以上架构图可以得知HBase存储机制涉及到的组件：

一 ZooKeeper作用:

#存储HBase元数据

#负责HMaster的选择和主备切换

#负责对HRegionServer进行监控：HRegionServer会向ZK注册,ZK创建针对每一个RegionServer创建/hbase/rs/[hostname]状态节点；HMaster同时会对这个节点注册监听。当某一个RegionServer挂掉的时候，ZK在一段时间无法接受该RegionServer的心跳信息，则会删除该状态节点。与此同时，HMaster则会接收到ZooKeeper
的NodeDelete 通知，从而感知到某个节点断开，并立即开始容错工作。

 

 

HBase为什么不直接让HMaster来负责RegionServer的监控呢?如果HMaster直接通过心跳机制等来管理RegionServer的状态，随着集群越来越大，HMaster的管理负担会越来越重，另外它自身也有挂掉的可能，因此数据还需要持久化。在这种情况下，ZooKeeper就成了理想的选择。

 

#对RootRegion的管理

对应HBase集群来说，数据存储的位置信息是记录在元数据HRegion，也就是Root Region上的。每次客户端发起新的请求，需要知道数据的位置，就会去查询RootRegion，而RootRegion自身位置则是记录在ZK上的(默认情况下，是记录在ZK的/hbase/meta-region-server节点中)。当Root Region发生变化，比如Region的手工移动、重新负载均衡或Root
Region所在服务器发生了故障等是，就能够通过ZK来感知到这一变化并做出一系列相应的容灾措施，从而保证客户端总是能够拿到正确的RootRegion信息。

 

#Region 管理

HBase里的HRegion会经常发生变更，这些变更的原因来自于系统故障、负载均衡、配置修改、HRegion分裂与合并等。一旦HRegion发生移动，它就会经历下线(offline)和重新上线(online)的过程。

 

在下线期间数据是不能被访问的，并且HRegion的这个状态变化必须让全局知晓，否则可能会出现事务性的异常。对于大的HBase集群来说，HRegion的数量可能会多达十万级别，甚至更多，这样规模的HRegion状态管理交给ZK来做也是一个很好的选择。

 

#分布式SplitWAL任务管理

当某台HRegionServer服务器挂掉时，由于总有一部分新写入的数据还没有持久化到StoreFile中，因此在迁移该HRegionServer的服务时，一个重要的工作就是从WAL中恢复这部分还在内存中的数据，而这部分工作最关键的一步就是SplitWAL，即HMaster需要遍历该HRegionServer服务器的WAL，并按HRegion切分成小块移动到新的地址下，并进行日志的回放(replay)。

 

由于单个HRegionServer的日志量相对庞大(可能有上千个HRegion，上GB的日志)，而用户又往往希望系统能够快速完成日志的恢复工作。因此一个可行的方案是将这个处理WAL的任务分给多台HRegionServer服务器来共同处理，而这就又需要一个持久化组件来辅助HMaster完成任务的分配。

 

当前的做法是，HMaster会在ZooKeeper上创建一个SplitWAL节点(默认情况下，是/hbase/SplitWAL节点)，将”哪个HRegionServer处理哪个HRegion”这样的信息以列表的形式存放到该节点上，然后由各个HRegionServer服务器自行到该节点上去领取任务并在任务执行成功或失败后再更新该节点的信息，以通知HMaster继续进行后面的步骤。ZK在这里担负起了分布式集群中相互通知和信息持久化的角色。

二 HMaster作用

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

2.2管理HRegionServer，实现其父在均衡,调整Region分布

2.3管理和分配Region：Region分裂后，负责新Region的分配；某一个RegionServer宕机之后，接收到ZooKeeper 的NodeDelete 通知然后开始该失效RegionServer上的Region的迁移

 

三 HRegionServer作用

3.1维护本地的Region,并处理客户端对这些Region读写的I/O请求

3.2负责切分本地Region，当StoreFile大小超过阀值，则会触发Region的split操作，把当前Region切分成2个Region，然后老的Region会下线；新的2个Region会被HMaster分配到相对应的HRegionServer上

HRegionServer内部管理着一系列HRegion对象，每一个HRegion对象对应着Table中的Region。

HRegion由多个HStore组成，每一个HStore对应了Table中的一个ColumnFamily(列簇)的存储。因此可以看出每一个列簇其实就是一个集中的存储单元，因此最好将具备共同I/O特性的列放在一个列簇里，这样可以保证读写的高效

 

四 HStore作用

HStore是HBase存储的核心，主要由2部分组成：MemStore和StoreFile。MemStore就是 SortedMemory Buffer，用户写入的数据首先会放在这个内存缓存中，当缓冲区满了以后，flush 到StoreFile（底层是HFile）中，当StoreFile文件数达到阀值会触发Compact操作，将多个StoreFile进行合并，合并成一个大的StoreFile。合并过程中会进行版本的合并和数据删除，因此所有的更新和删除操作都是在compact阶段完成的，这使得用户的写操作只要写入内存就可以立即返回，保证HBaseI/O高性能

 

当合并之后的StoreFile超过阀值，则会触发HRegion的split操作，将一个HRegion分成2个HRegion，老的HRegion会被下线，新的会被HMaster分配到对应的HRegionServer上，可能是当前HRegionServ

Er也有可能是其他HRegionServer上

 

五 WAL机制的作用

假设在写数据到MemStore的时候，突然HRegionServer挂了,怎么办？

其实在每一次用户写入数据到MemStore的时候，也会把这个数据写入到HLog中，HLog就是实现了WAL的一个类，每一个HRegionSe

Rver都有一个HLog对象。

HLog文件定期会滚动刷新，当MemStore将数据刷到StoreFile的时候，则会把之前记录的数据给删除掉。

HRegionServer挂掉之后，ZK会给HMaster发送一个NodeDelete通知，HMaster收到之后，则会首先处理HLog文件，将该HRegionServer上的所有HLog数据进行拆分，分别放到不同得HRegion目录下，然后再将失效的这些Region重新分配，ZK会记录这些对应地址，其他HRegionServer去ZK领取自己对应的Region，然后去加载这些Region，在加载的过程中，发现有HLog需要处理，因此会将HLog中的数据放到MemStore里面，然后刷新到StoreFile中，完成数据恢复。

 

六 HFile作用

就是HBase中key-value格式的数据存储文件，他是一个二进制的格式的，StoreFile就是针对HFile进行了一个轻量级的封装而已

 

七 HLogFile作用

HBase中 WriteAhead Log(WAL)的存储格式，物理上是一个sequencefile