深入理解HBase的系统架构

妖狐艹你老母 2022-06-14 01:19 244阅读 0赞

*  HBase的构成
 *  Regions
 *  HBase的HMaster
 *  ZooKeeper
 *  HBase各组成部分之间的合作
 *  HBase的第一次读写
 *  HBase的META table
 *  Region Server的组成
 *  HBase的写操作步骤
    
     *  步骤一
     *  步骤二
 *  HBase的MemStore
 *  HBase Region Flush
 *  HFile
 *  HFile的结构
    
     *  HFile的索引
 *  HBase的读合并（Read Merge）以及读放大（Read amplification）
 *  HBase的Compaction
    
     *  Minor Compaction
     *  Major Compaction
 *  Region的分割（Region split）
 *  读操作的负载均衡（Read Load Balancing）
 *  HDFS的数据备份（Data Replication）
 *  HBase的异常恢复（Crash Recovery）
 *  数据恢复（Data Recovery）
 *  Apache HBase的优缺点
    
     *  优点
     *  缺点

> 初次接触HBase的读者，建议先阅读[浅析HBase：为高效的可扩展大规模分布式系统而生][HBase]

# HBase的构成 #

物理上来说，HBase是由三种类型的服务器以主从模式构成的。这三种服务器分别是：**Region server**，**HBase HMaster**，**ZooKeeper**。

其中Region server负责数据的读写服务。用户通过沟通Region server来实现对数据的访问。

HBase HMaster负责Region的分配及数据库的创建和删除等操作。

ZooKeeper作为HDFS的一部分，负责维护集群的状态（某台服务器是否在线，服务器之间数据的同步操作及master的选举等）。

另外，Hadoop DataNode负责存储所有Region Server所管理的数据。HBase中的所有数据都是以HDFS文件的形式存储的。出于使Region server所管理的数据更加本地化的考虑，Region server是根据DataNode分布的。HBase的数据在写入的时候都存储在本地。但当某一个region被移除或被重新分配的时候，就可能产生数据不在本地的情况。这种情况只有在所谓的compaction之后才能解决。

NameNode负责维护构成文件的所有物理数据块的元信息（metadata）。

HBase结构如下图所示：

![HBase architecture][]

# Regions #

HBase中的表是根据row key的值水平分割成所谓的region的。一个region包含表中所有row key位于region的起始键值和结束键值之间的行。集群中负责管理Region的结点叫做Region server。Region server负责数据的读写。每一个Region server大约可以管理1000个region。Region的结构如下图所示：

![Region architecture][]

# HBase的HMaster #

HMaster负责region的分配，数据库的创建和删除操作。

具体来说，HMaster的职责包括：

*  调控Region server的工作  
    
    
     *  在集群启动的时候分配region，根据恢复服务或者负载均衡的需要重新分配region。
     *  监控集群中的Region server的工作状态。（通过监听zookeeper对于ephemeral node状态的通知）。
 *  管理数据库  
    
    
     *  提供创建，删除或者更新表格的接口。

HMaster的工作如下图所示：

![HMaster structure][]

# ZooKeeper #

HBase利用ZooKeeper维护集群中服务器的状态并协调分布式系统的工作。ZooKeeper维护服务器是否存活，是否可访问的状态并提供服务器故障/宕机的通知。ZooKeeper同时还使用一致性算法来保证服务器之间的同步。同时也负责Master选举的工作。需要注意的是要保证良好的一致性及顺利的Master选举，集群中的服务器数目必须是奇数。例如三台或五台。

ZooKeeper的工作如下图所示：

![Zookeeper structure][]

# HBase各组成部分之间的合作 #

ZooKeeper用来协调分布式系统的成员之间共享的状态信息。Region Server及HMaster也与ZooKeeper连接。ZooKeeper通过心跳信息为活跃的连接维持相应的ephemeral node。如下图所示：

![HBase-Components coordination][]

每一个Region server都在ZooKeeper中创建相应的ephemeral node。HMaster通过监控这些ephemeral node的状态来发现正常工作的或发生故障下线的Region server。HMaster之间通过互相竞争创建ephemeral node进行Master选举。ZooKeeper会选出区中第一个创建成功的作为唯一一个活跃的HMaster。活跃的HMaster向ZooKeeper发送心跳信息来表明自己在线的状态。不活跃的HMaster则监听活跃HMaster的状态，并在活跃HMaster发生故障下线之后重新选举，从而实现了HBase的高可用性。

如果Region server或者HMaster不能成功向ZooKeeper发送心跳信息，则其与ZooKeeper的连接超时之后与之相应的ephemeral node就会被删除。监听ZooKeeper状态的其他节点就会得到相应node不存在的信息，从而进行相应的处理。活跃的HMaster监听Region Server的信息，并在其下线后重新分配Region server来恢复相应的服务。不活跃的HMaster监听活跃HMaster的信息，并在起下线后重新选出活跃的HMaster进行服务。

# HBase的第一次读写 #

HBase中有一个特殊的起目录作用的表格，称为META table。META table中保存集群region的地址信息。ZooKeeper中会保存META table的位置。

当用户第一次想HBase中进行读或写操作时，以下步骤将被执行：

1.  客户从ZooKeeper中得到保存META table的Region server的信息。
2.  客户向该Region server查询负责管理自己想要访问的row key的所在的region的Region server的地址。客户会缓存这一信息以及META table所在位置的信息。
3.  客户与负责其row所在region的Region Server通信，实现对该行的读写操作。

在未来的读写操作中，客户会根据缓存寻找相应的Region server地址。除非该Region server不再可达。这时客户会重新访问META table并更新缓存。这一过程如下图所示：

![First read or write][]

# HBase的META table #

*  META table中保存了HBase中所有region的信息。
 *  META table的格式类似于B tree。
 *  META table的结构如下：  
    
    
     *  键：region的起始键，region id。
     *  值：Region server

如下图所示：

![META table][]

# Region Server的组成 #

运行在HDFS DataNode上的Region server包含如下几个部分：

*  WAL：既Write Ahead Log。WAL是HDFS分布式文件系统中的一个文件。WAL用来存储尚未写入永久性存储区中的新数据。WAL也用来在服务器发生故障时进行数据恢复。
 *  Block Cache：Block cache是读缓存。Block cache将经常被读的数据存储在内存中来提高读取数据的效率。当Block cache的空间被占满后，其中被读取频率最低的数据将会被杀出。
 *  MemStore：MemStore是写缓存。其中存储了从WAL中写入但尚未写入硬盘的数据。MemStore中的数据在写入硬盘之前会先进行排序操作。每一个region中的每一个column family对应一个MemStore。
 *  Hfiles：Hfiles存在于硬盘上，根据排序号的键存储数据行。

Region server的结构如下图所示：

![Region server component][]

# HBase的写操作步骤 #

## 步骤一 ##

当HBase的用户发出一个`PUT`请求时（也就是HBase的写请求），HBase进行处理的第一步是将数据写入HBase的write-ahead log（WAL）中。

*  WAL文件是顺序写入的，也就是所有新添加的数据都被加入WAL文件的末尾。WAL文件存在硬盘上。
 *  当server出现问题之后，WAL可以被用来恢复尚未写入HBase中的数据（因为WAL是保存在硬盘上的）。

如下图所示：

![HBase write step 1][]

## 步骤二 ##

当数据被成功写入WAL后，HBase将数据存入MemStore。这时HBase就会通知用户PUT操作已经成功了。

过程如下图所示：

![HBase write step 2][]

# HBase的MemStore #

Memstore存在于内存中，其中存储的是按键排好序的待写入硬盘的数据。数据也是按键排好序写入HFile中的。每一个Region中的每一个Column family对应一个Memstore文件。因此对数据的更新也是对应于每一个Column family。

如下图所示：

![Memstore][]

# HBase Region Flush #

当MemStore中积累了足够多的数据之后，整个Memcache中的数据会被一次性写入到HDFS里的一个新的HFile中。因此HDFS中一个Column family可能对应多个HFile。这个HFile中包含了相应的cell，或者说键值的实例。这些文件随着MemStore中积累的对数据的操作被flush到硬盘上而创建。

需要注意的是，MemStore存储在内存中，这也是为什么HBase中Column family的数目有限制的原因。每一个Column family对应一个MemStore，当MemStore存满之后，里面所积累的数据就会一次性flush到硬盘上。同时，为了使HDFS能够知道当前哪些数据已经被存储了，MemStore中还保存最后一次写操作的序号。

每个HFile中最大的序号作为meta field存储在其中，这个序号标明了之前的数据向硬盘存储的终止点和接下来继续存储的开始点。当一个region启动的时候，它会读取每一个HFile中的序号来得知当前region中最新的操作序号是什么（最大的序号）。

如下图所示：

![Region flush][]

# HFile #

HBase中的键值数据对存储在HFile中。上面已经说过，当MemStore中积累足够多的数据的时候就会将其中的数据整个写入到HDFS中的一个新的HFile中。因为MemStore中的数据已经按照键排好序，所以这是一个顺序写的过程。由于顺序写操作避免了磁盘大量寻址的过程，所以这一操作非常高效。

如下图所示：

![HFile][]

# HFile的结构 #

HFile中包含了一个多层索引系统。这个多层索引是的HBase可以在不读取整个文件的情况下查找数据。这一多层索引类似于一个B+树。

*  键值对根据键大小升序排列。
 *  索引指向64KB大小的数据块。
 *  每一个数据块还有其相应的叶索引（leaf-index）。
 *  每一个数据块的最后一个键作为中间索引（intermediate index）。
 *  根索引（root index）指向中间索引。

文件结尾指向meta block。因为meta block是在数据写入硬盘操作的结尾写入该文件中的。文件的结尾同时还包含一些别的信息。比如`bloom filter`及时间信息。`Bloom filter`可以帮助HBase加速数据查询的速度。因为HBase可以利用`Bloom filter`跳过不包含当前查询的键的文件。时间信息则可以帮助HBase在查询时跳过读操作所期望的时间区域之外的文件。

如下图所示：

![HFile structure][]

## HFile的索引 ##

HFile的索引在HFile被打开时会被读取到内存中。这样就可以保证数据检索只需一次硬盘查询操作。

如下图所示：

![HFile index][]

# HBase的读合并（Read Merge）以及读放大（Read amplification） #

通过上面的论述，我们已经知道了HBase中对应于某一行数据的cell可能位于多个不同的文件或存储介质中。比如已经存入硬盘的行位于硬盘上的HFile中，新加入或更新的数据位于内存中的MemStore中，最近读取过的数据则位于内存中的Block cache中。所以当我们读取某一行的时候，为了返回相应的行数据，HBase需要根据Block cache，MemStore以及硬盘上的HFile中的数据进行所谓的读合并操作。

1.  HBase会首先从Block cache（HBase的读缓存）中寻找所需的数据。
2.  接下来，HBase会从MemStore中寻找数据。因为作为HBase的写缓存，MemStore中包含了最新版本的数据。
3.  如果HBase从Block cache和MemStore中没有找到行所对应的cell所有的数据，系统会接着根据索引和`bloom filter`从相应的HFile中读取目标行的cell的数据。

如下图所示：

![HBase read merge][]

这里一个需要注意的地方是所谓的读放大效应（Read amplification）。根据前文所说，一个MemStore对应的数据可能存储于多个不同的HFile中（由于多次的flush），因此在进行读操作的时候，HBase可能需要读取多个HFile来获取想要的数据。这会影响HBase的性能表现。

如下图所示：

![HBase read amplification][]

# HBase的Compaction #

## Minor Compaction ##

HBase会自动选取一些较小的HFile进行合并，并将结果写入几个较大的HFile中。这一过程称为Minor compaction。Minor compaction通过Merge sort的形式将较小的文件合并为较大的文件，从而减少了存储的HFile的数量，提升HBase的性能。

这一过程如下图所示：

![Minor compaction][]

## Major Compaction ##

所谓Major Compaction指的是HBase将对应于某一个Column family的所有HFile重新整理并合并为一个HFile，并在这一过程中删除已经删除或过期的cell，更新现有cell的值。这一操作大大提升读的效率。但是因为Major compaction需要重新整理所有的HFile并写入一个HFile，这一过程包含大量的硬盘I/O操作以及网络数据通信。这一过程也称为写放大（Write amplification）。在Major compaction进行的过程中，当前Region基本是处于不可访问的状态。

Major compaction可以配置在规定的时间自动运行。为避免影响业务，Major compaction一般安排在夜间或周末进行。

需要注意的一点事，Major compaction会将当前Region所服务的所有远程数据下载到本地Region server上。这些远程数据可能由于服务器故障或者负载均衡等原因而存储在于远端服务器上。

这一过程如下图所示：

![Major compaction][]

# Region的分割（Region split） #

首先我们快速复习一下Region：

*  HBase中的表格可以根据行键水平分割为一个或几个region。每个region中包含了一段处于某一起始键值和终止键值之间的连续的行键。
 *  每一个region的默认大小为1GB。
 *  相应的Region server负责向客户提供访问某一region中的数据的服务。
 *  每一个Region server能够管理大约1000个region（这些region可能来自同一个表格，也可能来自不同的表格）。

如下图所示：

![Region][]

每一个表格最初都对应于一个region。随着region中数据量的增加，region会被分割成两个子region。每一个子region中存储原来一半的数据。同时Region server会通知HMaster这一分割。出于负载均衡的原因，HMaster可能会将新产生的region分配给其他的Region server管理（这也就导致了Region server服务远端数据的情况的产生）。

如下图所示：

![Region split][]

# 读操作的负载均衡（Read Load Balancing） #

Region的分割最初是在Region server本地发生的。但是出于负载均衡的原因，HMaster可能会将新产生的region分配给其他的Region server进行管理。这也就导致了Region server管理存储在远端服务器上的region情况的产生。这一情况会持续至下一次Major compaction之前。如上文所示，Major compaction会将任何不在本地的数据下载至本地。

也就是说，HBase中的数据在写入时总是存储在本地的。但是随着region的重新分配（由于负载均衡或数据恢复），数据相对于Region server不再一定是本地的。这种情况会在Major compaction后得到解决。

如下图所示：

![Read load balancing][]

# HDFS的数据备份（Data Replication） #

HDFS中所有的数据读写操作都是针对主节点进行的。HDFS会自动备份WAL和HFile。HBase以来HDFS来提供可靠的安全的数据存储。当数据被写入HDFS本地时，另外两份备份数据会分别存储在另外两台服务器上。

如下图所示：

![HDFS data replication][]

# HBase的异常恢复（Crash Recovery） #

WAL文件和HFile都存储于硬盘上且存在备份，因此恢复它们是非常容易的。那么HBase如何恢复位于内存中的MemStore呢？

![Crash recovery][]

当Region server宕机的时候，其所管理的region在这一故障被发现并修复之前是不可访问的。ZooKeeper负责根据服务器的心跳信息来监控服务器的工作状态。当某一服务器下线之后，ZooKeeper会发送该服务器下线的通知。HMaster收到这一通知之后会进行恢复操作。

HMaster会首先将宕机的Region server所管理的region分配给其他仍在工作的活跃的Region server。然后HMaster会将该服务器的WAL分割并分别分配给相应的新分配的Region server进行存储。新的Region server会读取并顺序执行WAL中的数据操作，从而重新创建相应的MemStore。

如下图所示：

![Crash recovery][Crash recovery 1]

# 数据恢复（Data Recovery） #

WAL文件之中存储了一系列数据操作。每一个操作对应WAL中的一行。新的操作会顺序写在WAL文件的末尾。

那么当MemStore中存储的数据因为某种原因丢失之后应该如何恢复呢？HBase以来WAL对其进行恢复。相应的Region server会顺序读取WAL并执行其中的操作。这些数据被存入内存中当前的MemStore并排序。最终当MemStore存满之后，这些数据被flush到硬盘上。

如下图所示：

![Data recovery][]

# Apache HBase的优缺点 #

## 优点 ##

*  强一致性模型  
    
    
     *  当一个写操作得到确认时，所有的用户都将读到同一个值。
 *  可靠的自动扩展  
    
    
     *  当region中的数据太多时会自动分割。
     *  使用HDFS分布存储并备份数据。
 *  内置的恢复功能  
    
    
     *  使用WAL进行数据恢复。
 *  与Hadoop集成良好  
    
    
     *  MapReduce在HBase上非常直观。

## 缺点 ##

*  WAL回复较慢。
 *  异常恢复复杂且低效。
 *  需要进行占用大量资源和大量I/O操作的Major compaction。

[HBase]: http://blog.csdn.net/yaokai_assultmaster/article/details/72830723
[HBase architecture]: /images/20220614/9600cd735e4a4f979348fc29758dc250.png
[Region architecture]: /images/20220614/058ed6f233f949fbbc338878aa09dbdd.png
[HMaster structure]: /images/20220614/a2cf3fc45bb3415fa38400d6edafed98.png
[Zookeeper structure]: /images/20220614/1edacc4a9701421e8ab112180c461b82.png
[HBase-Components coordination]: /images/20220614/87487f1da22f444aa32c06f62cc4aaa3.png
[First read or write]: /images/20220614/ffc43327a15d404ca8633d104a39c3fa.png
[META table]: /images/20220614/5bac4270ba5148cea25667d55dfdeb07.png
[Region server component]: /images/20220614/1a29c157796f4ec693d3f986cafdcf77.png
[HBase write step 1]: /images/20220614/5e65c357ccfc4bd1a959cd81b3def733.png
[HBase write step 2]: /images/20220614/19399ffe947d4364924e73bba2a82a9f.png
[Memstore]: /images/20220614/0fa2a6a78c404485850d26be733f5dca.png
[Region flush]: /images/20220614/52475d01d5d84520b97f44b843f06823.png
[HFile]: /images/20220614/103c46795f5e4c59993364e110895985.png
[HFile structure]: /images/20220614/6bbdc3314cb64252b2c01b10b5310550.png
[HFile index]: /images/20220614/5b0305dcb498464583d99cf767391a3a.png
[HBase read merge]: /images/20220614/affe2ea6fb2a40fe99ee29a5f85cf5cd.png
[HBase read amplification]: /images/20220614/de562fdb2a9f49d0a8e7a9d3d306bb18.png
[Minor compaction]: /images/20220614/3aa6a229b7a24e6e8a1537ae468cb5da.png
[Major compaction]: /images/20220614/66219eb7f2e34795ab893aed727cb2c2.png
[Region]: /images/20220614/aebb10b3950447cf9b0f25db466b76ab.png
[Region split]: /images/20220614/f21b5434bc6f4c7489b0f88ad45d427e.png
[Read load balancing]: /images/20220614/1ebecfe3cea54b5cb412cb3c5f0ff849.png
[HDFS data replication]: /images/20220614/b348f1de1ac3407caa7c542cad28d9fd.png
[Crash recovery]: /images/20220614/78d46fbecca1495fb8c065337cf0253e.png
[Crash recovery 1]: /images/20220614/9e4da2ce7ea44f70bed96e45665a5562.png
[Data recovery]: /images/20220614/2bc75d2ae2ee4c92940d9a0f1b54f1ec.png
[An In-Depth Look at the HBase Architecture]: https://mapr.com/blog/in-depth-look-hbase-architecture/