HBase架构初探

---

引言

HBase是运行在Hadoop集群上的分布式、NoSQL型、面向列存储的数据库，是Google BigTable的开源实现。它和传统的关系型数据库RDBMS有着本质的区别，RDBMS需要严格满足ACID（atomicity原子性,consistency一致性，isolation隔离性，durability持久性）的标准，而HBase满足的是CAP（consistency一致性，availability可用性，partition tolerance分区容忍性）理论。
有关HBase的很多特效，这里不做太多说明。

HBase vs RDBMS:
1.scale.HBase适用于Big Data（scale out）;RDMS用于Big Data,只能通过提高单节点的性能来做到，即scale up.前者更加实用经济，后者复杂困难且资源消耗大
2.query bottleneck.RDBMS的很多查询不可避免的需要进行join，如果join的表比较多，那么就会很大的影响查询效率，成为查询瓶颈；而HBase通过水平切分表并将表数据分布式存储，从而避免了不必要的join，保持了数据在信息的完整性。

1. HBase架构组成部件

物理上，HBase由三种类型的服务器构成，分别是ZooKeeper服务器、HMaster服务器、regionServer服务器。它是按照主从结构构建的。HMaster是主节点，regoinServer是从节点。ZooKeeper用于维系集群的状态，获取HMaster,regoinServer等心跳，同时也保存着region和regionServer关联的Meta table的位置。HMaster用于DDL（创建、删除表）操作、regionServer的故障恢复、region的分发。regionServer用于实际地操纵数据，为用户提供HBase数据读写服务。当用户需要访问数据的时候，都是直接与regionServer交互的。
HBase的数据在底层是存在是HDFS上，所以HBase需要构建在HDFS上。这些数据已某种固定的格式（HFile）存放在HDFS的dataNode上。

Tips:当用户调用put将数据写入HBase时，数据是放在本地磁盘中，而如果一个region被移走了，那么这部分数据就不存放在本地了，直到HBase进行Major Compaction时才会被移到本地来。

2.Region

什么是Region？简单来说，HBase会将一张表切分成多个块区域（region），这些区域之间是不重叠的，而且同一个region内的记录是一个连续的块（所有包含在startRowKey和endRowKey之间的）。这些region将会由HMaster分发给不同的dataNode,有这些dataNode中一个特殊进行进程管理，这个进程就是RegionServer进程，而这些datNode就是我们所谓的regionServer.一般一个regionServer服务器可以提供1000个region的服务。

3.HBase HMaster

表区域的分配、DDL操作（创建、删除表）、从节点故障恢复都是由Master节点负责。
总体来说，Master节点的工作有：

1. 协同各个regionServer。在启动阶段分配给regionServer分配region、故障恢复的region重分配、负载均衡、管理集群中所有的regionServer实例（监听来自ZooKeeper的通知）
2. 管理员功能。DDL操作（创建、删除、更新表）

4.ZooKeeper:协调者

zooKeeper（a distributed coordination service）作为Hadoop的分布式环境协调者，扮演者园丁的工作。HBase同样适用它来作为HMaster、RegionServer之间的协调者。zooKeeper维系哪个服务是alive、可用的，同时提供服务故障通知。zooKeeper接收来自HBase各个进程的心跳信息，一旦某个进程的心跳超时，就会发出服务故障的通知，通知相关进程进行故障恢复。

5.ZooKeeper、HMaster、RegionServer如何协同工作？

RegionServer和active HMaster通过会话（session）与ZooKeeper连接起来。ZooKeeper通过他们的心跳信息为这些有效的会话创建临时（ephemeral ）节点。
每一个RegionServer创建自己的临时（ephemeral ）节点，HMaster通过管理这些临时节点来获知可用的RegionServer，同样也可以对失效的RegionServer进行故障恢复。
HMaster可能会存在多个，但是同一时刻只会有一个HMaster是有效的（active）,其他的会作为备用节点（backup）。有效的HMaster会向ZooKeeper发送心跳信息，而备用的HMaster节点会监听ZooKeeper的active HMaster失效的信息。
一旦HMaster或者RegionServer发送给ZooKeeper的心跳信息超时，相对应的临时（ephemeral ）节点会被删除，同时相应的故障恢复也会开始工作。

6.HBase第一次读

在HBase中存在一个特殊表，Catalog table，即META table。在这个表中记录了所有region在集群中的存放位置。而这个表的存放位置放置在ZooKeeper中。
客户端第一次读HBase的步骤如下：

1. 客户端从ZooKeeper中获得META表的位置。
2. 客户端通过META表获知待访问的数据所在的RegionServer位置。同时将这个位置信息和META表的位置缓存。
3. 从对应RegionServer获取待访问的数据。

接下来的读取，客户端都会先从缓存中查找是否已经存在待查询的数据，如果存在直接返回，如果不存在，则通过META查询数据，如果还是找不到，就会进行re-query，并更新缓存。

7.META Table

1. META Table中记录了集群中所有的region与regionServer对应信息。
2. 结构逻辑上类似B树

8.RegionServer组成部件

RegionServer是运行在HDFS的dataNode上的Region管理进程，是HBase的基本守护进程之一，它有一下几个主要组成部分：
1. WAL(Write Ahead Log)预写日志。当用户向HBase写数据时，这部分数据会先被记录到WAL中，只有当WAL写入成功后，才会被写入HBase。简单来说，WAL是用于存储那些还未被持久化保存的需要写入HBase的数据。因而当RegionServer宕机的时候，可以根据WAL中的记录进行故障恢复。
2. BlockCache(块缓存)。它是HBase读缓存，一块特殊内存区域。用于记录用户最近读的数据，采用LRU（Least Recently Used）进行更新.
3. MemStore。MemStore是一块特殊的缓存区，用户记录用户写HBase数据，当MemStore满后，系统将会把MemStore中的数据flush到本地，生成一个HFile文件。
4. HFile。HFile是HBase底层数据基本存储文件，存放于HDFS中，以Key-Value序列的形式保存HBase数据。

Tips:HFile存放于HDFS上，所以它的备份、安全等是由HDFS提供的。

9.HBase写流程

1. 当用户向HBase发出写请求时，系统会将数据先写入WAL中，WAL中的编辑记录是一序列的形式组织的，所以文件后面的记录就是用户最新写行为。也正是由于WAL的存在，所以当某个RegionServer宕机后，HMaster就会根据WAL进行故障恢复。
2. 一旦当数据成功写入WAL，这部分Put的数据就会被写入MemStore内存区域。同时系统给客户端发送ACK响应，表示Put成功。
   

   Tips:可见，用户Put到HBase的数据并不会立马就写到本地中，而是先放着内存暂存区域，只有当该区域空间满后，才被flush到本地，生成对应的HFile文件。同时，HBase数据在MemStore的存储方式和在HFile中的存储方式是一样的（按rowKey排序）。

10.HBase MemStore

MemStore是“内存化HFile”,其数据的组织形式与HFile一样，只不过它位于内存中，类似于写缓存。在RegionServer中，每一个Region中可能会有多个列族（column family）,MemStore是与列族一一对应的，即一个column famliy 一个MemStore。这也解释了为什么我们说HBase是colum-based（按列存储的）？因为它是每个列族一个MemStore，那么同一个HFile中的数据一定是同一个列族的（HFile由MemStore flush到本地产生）。

11.HBase Region Flush

上面已经提到，当MemStore空间满时，就会把MemStore里面的数据flush到HDFS，生成一个新的HFile文件。而且，由于MemStore与column family是一一对应的，所以同一个Column Family下会有多个HFile文件与其对应（MemStore多次的Flush）。在HFile中，就保存着实际的HBase数据单元，这些数据单元以Key-Value的形式保存。

Tips:当一个MemStore执行Flush操作时，该RegionServer上所有的MemStore多会进行Flush，很显然这是很耗时的。所以HBase对一张表的column family的数量是由限制。

当进行Flush的时候，系统也会记录最后一次写序列的数量，并将这个信息记录在HFile的元域（meta field）上，用来表示持久化的结束和下面该从哪里开始。当Region启动时，这个信息将会被读取，系统就会知道下面该从哪里进行新的编辑修改了。

这里讲的有点不清楚，大概我的理解是：因为数据存储时为了方便进行顺序存储（减少磁盘寻道时间），所以必须要知道每次数据应该写到哪里（位置信息），那么下面新的数据自然需要从那个位置继续。

12.HBase HFile

数据存放以有序KeyValue的形式存放在HFile文件中。而HFile文件的产生，上面已经有提到，是由MemStore在达到足够的数据后，flush到HDFS上的。这个过程是一个序列写（sequential write）。由于是顺序操作，减少了磁盘寻道时间，速度块。 HFile文件的组织形式类似于B+树，是一个多层索引结构。首先文件是以每64KB一个块（“block”）的形式逻辑分割，而每一个块都有自己的叶子索引（leaf index），同时每一个块的最后一个索引会被放到中间索引（intermeidate index）中。文件的根索引是指向中间索引的。这三种类型的索引在HFile被打开并保存在内存中时，就被HBase加载到BlockCache（读缓存）中。

存在着三种类型的索引：根索引、中间索引和叶子索引。数据查找的方式是，先根据根索引找到对应的中间索引，从中间索引在找到对应的叶子索引，然后从叶子索引找到需要的数据。

13.HBase Read Merge

当我们需要读取HBase表中某一行的数据时，因为这一行数据会根据列族分成多个Key-Value单元存储。所以就需要从多个地方进行读取，并对读出的数据进行拼接。因为HBase特定的架构，所以需要读取的数据可能会出现在blockCache、MemStore、HFile这三个地方。所以步骤是： 1. 先从BlockCache中查找数据。 2. 如果没找到，再从MemStore中查找数据。 3. 如果还是没找到，再从HFile中查找数据。那么这里涉及到使用存放在BlockCache中的索引（根索引、叶子索引、中间索引）以及布隆过滤器（bloom filter）。

Tips:布隆过滤器：简单来说是一个三哈希表。作用是用来判断指定的Key是否在HFile中。需要注意的是，如果bloom filter返回false，那说明这个key是一定不在的，那么也就不用去加载这个HFile文件；如果返回True，那么说明这个key有可能存在这个HFile中。简单来说，bloom filter是一个0 false negitive和存在一定的false positive的过滤器。

14.Compaction(压缩)

HBase存在两种意义上的Compaction,Minor Compaction和Major Compaction。Minor Compaction是一种小规模的HFile合并压缩。它发生在当MemStore产生多个小HFile，达到一定阈值后，系统将会自动地对这些小HFile进行compaction；Major Compaction是一种大规模的HFile合并压缩。它的发生是周期性的，而且是可配置的。在这期间，HBase会将对一个region内的同一个column family下的所有HFile进行合并重新，同时会把之前用户删除的，即已经被系统标注的数据、过期超时的数据进行相应处理。这个过程可以有效地提供系统性能，但是在这个过程期间，系统会十分的繁忙，频繁I/O操作，所以系统对于客户端的响应会出现延迟甚至不响应。这叫做“写震荡”。

Tips:上文也提到过，在Major Compaction时，系统会把那些由于负载均衡或者服务器故障而放在远程的数据，搬迁到本地的regionServer中。

15.Region=连续的键数据

对Region的一些特性做个回顾：

1. 一张表会被水平的分割成一个或多个region区域。一个region区域内的记录是按照rowkey进行排序的，而且是连续的（存在startRowKey和endRowKey）
2. 一个region区域最大是1G
3. 管理region的服务器叫做regionServer
4. 一个regionServer最大能够管理1000个region。这些region可以来自不同的table

16.Region分裂

初始的时候，由于表中记录很少，所以一个region就可以了，当随着表中数据的增多，这个region也会越来越大，当达到一定大小之后，就需要对这个region进行分裂（split），使其分成两个较小region。同时这个过程会通知HMaster，有HMaster决定是否需要进行负载均衡，即把新的region分给别的regionServer进行管理，那么这里就有一个问题，因为对于那个被分配的regionServer来说，新来的region的数据是不在它的本地磁盘中的，而只能等到Major Compaction时，新来的region的数据才会被搬迁到本地HDFS中。

16.HBase RegionServer节点崩溃恢复

正如我们所知道的，HBase是架构在HDFS上，简单来说，HBase的实际数据是以HFile的形式存放在HDFS上的。由HDFS提供数据备份、数据安全等工作。对于HBase RegionServer节点故障恢复，有两样东西起了关键的作用，分别是WAL日志和HDFS文件备份。当一个regionServer失效时，ZooKeeper会率先发现（该节点的心跳信息）这个故障，并将故障通知给HMaster，交由HMaster进行故障修复工作。具体步骤是： 首先，HMaster会将这个RegionServer负责的Region重新分配给别的alive RegionServer。为了恢复MemStore里面的内容，HMaster会从WAL日志中分裂出属于那个失效节点的记录，并作为单独的文件存放在新的regionServer中。每个RegionServer会重新执行WAL中的内容，用于重建MemStore。

总结

HBase的优点：

1. 强一致性模型–当成功写入数据后，所有的客户端读都是一致的
2. 自动扩展–Region分裂和使用HDFS组织基本数据
3. 内置的恢复机制–WAL日志
4. 与Hadoop集成

HBase存在的问题：

1. WAL响应慢–每次update，都需要先WAL写，成功后才能完成操作。
2. 缓慢、复杂的故障恢复
3. Major Compaction的I/O问题–读写震荡