HBase架构深入分析（一）

HBase架构深入分析（一）

1. HBase组件

HBase使用master/slave架构来组件集群，它由以下几个组件构成：HMaster节点、HRegionServer节点、ZooKeeper集群。在持久化层，HBase使用HDFS，所以会和hadoop文件系统的Namenode和Datanode等节点进行交互。总体架构图如下：

此图是《HBase权威指南》上的一个总体，个人觉得该图还漏掉了一个操作：就是当对进行增删改时，Client会直接和HMaster进行交互，但在图中并没有表现出来。

以下介绍各个组件的作用：

HMaster：

(1) 管理HRegionServer，实现其负载均衡

(2) 管理和分配HRegion，比如在HRegion split时分配新的HRegion；在HRegionServer退出时迁移其内的HRegion到其他HRegionServer上

(3) 实现DDL操作（Data Definition Language，namespace和table的增删改，column familiy的增删改等）

(4) 管理namespace和table的元数据（实际存储在HDFS上）

(5) 权限控制（ACL）

HRegionServer节点：

(1) 存放和管理本地HRegion。

(2) 读写HDFS，管理Table中的数据。

(3) Client直接通过HRegionServer读写数据（从HMaster中获取元数据，找到RowKey所在的HRegion/HRegionServer后）。

ZooKeeper集群是协调系统

(1) 存放整个 HBase集群的元数据以及集群的状态信息。

(2) 实现HMaster主从节点的failover。

Hadoop DataNode存储HRegionServer管理的数据。所有HBase数据都存储在HDFS文件中。HRegionServer与HDFS DataNodes的数据最好存放在一起，这使得RegionServers服务在使用的数据的位置尽可能的靠近，提高读取效率。HBase数据在写入时是本地的，但当一个Region被移动时，它不是本地的，直到下一次压缩(compact)，才能继续本地化。

另外，Namenode中维护了所有Datanode中数据块的元数据信息，包括：位置，大小，时间等。

上图说明了一个HBase集群的组成。从上图可以看出以下几点含义：

(1) zookeeper是协调器，它是一个集群，一般由奇数个节点组成。会通过paxos算法选出一个主节点，若主节点宕机会再次选举。他用来维护整个HBase集群的状态，地位非常重要。

(2) HMaster可以有多个，但实际工作的只能有一个，其他的作为备份，当活动的Master宕机时，备份的Master中的一个会自动被激活。保证了HMaster的高可用。

(3) RegionServer和DataNode一般会放在相同的Server上实现数据的本地化，提高Region操作数据的效率。

2. HMaster

HMaster主要负责Region的分配，HBase表的创建、删除、修改等操作。

具体来说HMaster负责的工作内容如下：

协调HRegionServer

(1) 启动时HRegion的分配，以及负载均衡和修复时HRegion的重新分配。

(2) 监控集群中所有HRegionServer实例的状态。该任务是通过监听zookeeper中的发送消息来实现的。

管理功能

(1) 创建、删除、修改HBase表定义。

从上图我们可以得出以下几点结论：

(1) HBase的表定义的增删改是客户端通过HMaster完成的。

(2) 每个RegionServer分配多少Region，重新分配Region，都由HMaster来完成。

3. HRegion

HBase通过RowKey将表水平切割成多个HRegion，一个HRegion有一个startKey和endKey的row key，一个RZegion包含了从startKey到endKey范围内的所有的行（包含startKey，但不包含endKey）。每个Regions被分配到HBase的某个节点上，该节点被称为RegionServer，这些RegionServer负责数据的读取和写入。一个RegionServer可以服务多个region。数量大概是1000个。

一个给定的表可能包含一个或多个HRegion。

4. 协调器：ZooKeeper

HBase使用ZooKeeper作为分布式协调服务来维护集群中的服务器状态。Zookeeper维护哪些服务器存活和可用，并提供服务器故障通知。Zookeeper使用一种选举算法共同选举来保证的共享状态。请注意，应该有三到五台机器达成共识。

5. 组件是如何协调工作的

Zookeeper来维护分布式系统成员的状态信息。Region Server和活动的HMaster的连接信息。Zookeeper通过心跳机制来维护临时节点的活动session的状态。

每个RegionServer都会在Zookeeper上创建一个临时节点。HMaster会监视这些节点，从而发现可用的RegionServer，和宕机的RegionServer。

HMaster也会在Zookeeper中创建临时节点，Zookeeper会选择唯一的一个节点作为可用的HMaster节点。活动的HMaster节点发送心跳给Zookeeper，非活动的HMaster通过Zookeeper监听活动的HMaster节点的宕机事件。

一旦RegionServer或HMaster节点不再向Zookeeper发送心跳，和Zookeeper的session将会终止，对应的临时节点将会被删除。Zookeeper将会发送节点删除的事件通知。监听在RegionServer节点上的活动的HMaster，将会进行恢复RegionServer的操作。而若是活动的HMaster不在发送心跳给Zookeeper，监听在活动节点上的非活动HMaster节点将会收到活动HMaster节点的删除事件，Zookeeper将会再选出一个可用的活动节点。

6. HBase第一次读和写

有一个特殊的HBase目录表，被称为：META表。他保存了HBase集群中regions的位置。而ZooKeeper保存了META表的位置。

第一次客户端(Client)读或写入HBase时将会进行以下步骤：

(1) Client先从Zookeeper中获取托管META表的RegionServer。

(2) Client查询.META.服务，来获取需要访问的RowKey对应的Region Server。Client将这些信息与META表位置一起缓存起来。

(3) 它将从相应的Region Server获取该行的数据。

对于以后的读取操作，Cleint在缓存中查找META的位置和以前已经读取过的RowKey。到后来，它不再需要查询META表（可能大部分的RowKey已经被缓存起来了），除非因为Region的移动而发生了一个错误（RowKey已不在原来的Region上），Client会重新在Zookeeper中进行查询，并更新缓存数据。

7. HBase的Meta表

(1) 该META表是一个HBase表，用于保存系统中所有Region的列表。

(2) .META.表就像一棵b树。

(3) .META.表结构如下：

- 键(Key): region start key，region id。

- 值(Values)：RegionServer

8. RegionServer的组件

RegionServer在HDFS的DataNode节点上运行，并具有以下组件：

(1) WAL(Write Ahead Log)：Write Ahead Log是分布式文件系统上的一个文件。 WAL用于存储尚未持久存储的永久存储的新数据，在故障的情况下用于恢复数据。

(2) BlockCache：是读缓存。它将频繁读取的数据存储在内存中。最近最少使用的数据将会被清除内存。

(3) MemStore：是写缓存。它存储尚未写入磁盘的新数据。在写入磁盘之前将其排序。每个region的每个列族有一个MemStore。

(4) Hfiles将行(row)作为已排序的KeyValues存储在磁盘上。

9. HBase的写步骤

9.1 HBase写入操作--第一步

当Client发送一个put请求时，第一步就是把数据写入到write-ahead log(WAL)：

• 会把put操作的数据写入到WAL，写入时是直接append到WAL的末尾。
• 当部分数据已写入到写缓存MemStore，而此时服务器宕机，WAL用来回放未持久化的数据。
• 若数据写入WAL时失败，就认为写入操作失败。

9.2 HBase写入操作--第二步

一旦将数据写入WAL，就将其放在MemStore中。然后，put请求的确认信息将返回给客户端。写入操作完成。

10. HBase MemStore

MemStore将内存中的更新按排好序的Key-Value进行存储，与将其存储在HFile中的更新相同。每个列族有一个MemStore，更新操作按每个列族进行排序。

参考：

https://mapr.com/blog/in-depth-look-hbase-architecture/