[大数据]大数据原理与技术（五）：分布式数据库HBase

HBase是基于谷歌Bigtable开发的开源分布式数据库，具有高可靠、高性能、面向列、可伸缩等特点。HBase一般运行在HDFS上，主要用来存储非结构化和半结构化数据。HBase通过水平扩展的方式实现大表数据（表的规模可以达到数十亿行以及数百万列）的存储，对大表数据的读、写访问达到实时级别。

一、HBase概述

1.HBase简介

HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库，是谷歌BigTable的开源实现，主要用来存储非结构化和半结构化的松散数据。

• 适合于存储大表数据（表的规模可以达到数十亿以及数百万列），并且对大表数据的读、写访问可以达到实时级别。

• 利用Hadoop HDFS（Hadoop Distributed File System）作为其文件存储系统，提供实时读写的分布式数据库系统。

• 利用ZooKeeper作为协同服务。

2.HBase与传统关系型数据库的区别

HBase与传统的关系数据库的区别主要体现在以下几个方面：
（1）数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式，HBase则采用了更加简单的数据模型，它把数据存储为未经解释的字符串。
（2）数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接。HBase操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等，因为HBase在设计上就避免了复杂的表和表之间的关系。
（3）存储模式：关系数据库是基于行模式存储的。HBase是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的。
（4）数据索引：关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据访问性能。HBase只有一个索引——行键，通过巧妙的设计，HBase中的所有访问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来。
（5）数据维护：在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留。
（6）可伸缩性：关系数据库很难实现横向扩展，纵向扩展的空间也比较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩。

3.HBase的应用场景

HBase适合具有如下需求的应用：

• 海量数据（TB、PB）
• 高吞吐量
• 需要在海量数据中实现高效的随机读取
• 性能可伸缩
• 能够同属处理结构化和非结构化的数据
• 不需要完全拥有传统关系型数据库所具备的ACID特性

ACID原则是数据库事务正常执行的四个特性，分别指原子性、一致性、独立性和持久性。

• 原子性（Atomicity）：指一个事务要么全部执行，要么不执行，也就是说一个事务不可能只执行一半就停止了。
• 一致性（Consistency）：指事务的运行并不改变数据库中数据的一致性。
• 独立性（Isolation）：事务的独立性也可称为隔离性，是指两个以上的事务不会出现交错执行的状态，因为这样肯会导致数据不一致。
• 持久性（Durability）：事务的持久性是指事务执行成功以后，该事务对数据库所作的更改便是持久地保存在数据库之中。

二、HBase的相关概念

1.数据模型概述

HBase是一个稀疏、多维度、排序的映射表，这张表的索引是行键、列族、列限定符和时间戳。每个值是一个未经解释的字符串，没有数据类型。用户在表中存储数据，每一行都有一个可排序的行键和任意多的列。表在水平方向由一个或者多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起。列族支持动态扩展，可以很轻松地添加一个列族或列，无需预先定义列的数量以及类型，所有列均以字符串形式存储，用户需要自行进行数据类型转换。HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留，HBase可以对允许保留的版本数量进行设置。

2.HBase的数据模型

• 表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族。
• 行：每个HBase表都由若干行组成，每个行由行键（row key）来标识。
• 列族：一个HBase表被分组成许多“列族”（Column Family）的集合，它是基本的访问控制单元。
• 列限定符：列族里的数据通过列限定符（或列）来定位。
• 单元格：在HBase表中，通过行、列族和列限定符确定一个“单元格”（cell），单元格中存储的数据没有数据类型，总被视为字节数组byte[]。
• 时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引。

上图是HBase数据模型的一个实例

3.数据坐标

HBase中需要根据行键、列族、列限定符和时间戳来确定一个单元格，因此，可以视为一个“四维坐标”，即[行键, 列族, 列限定符, 时间戳]

4.概念视图

在HBase的概念视图中，一个表可以视为一个稀疏、多维的映射关系。

5.物理视图

从概念视图层面，HBase中的每个表是由许多行组成的，但是在无力存储方面，它是采用了基于列的存储方式。

6.行存储与列存储

• 行存储：数据按行存储在底层文件系统中，通常，每一行会被分配到固定额的空间
  优点：有利于增加/修改整行记录等操作；有利于整行数据的读取操作
  缺点：单列查询时，会读取一些不必要的数据

• 列存储：数据以列为单位，存储在底层文件系统中
  优点：有利于面向单列数据的读取/统计等操作
  缺点：整行读取时，可能需要多次I/O操作

三、HBase的实现原理

1.HBase的功能组件

HBase的实现包括三个主要的功能组件：
（1）库函数：链接到每个客户端
（2）一个Master主服务器
（3）许多个Region服务器
主服务器Master负责管理和维护HBase表的分区信息，维护Region服务器列表，分配Region，负载均衡；Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求。客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据，客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和Master通信，这种设计方式使得Master负载很小

2.表和Region

初始时只有一个Region，随着数据的不断插入，Region会不断增大，当一个Region中包含的行数量达到一个阀值时，就会被分成两个新的Region。随着表中行的数量不断增加，会分裂出越来越多的Region。Region拆分操作非常快，接近瞬间，因为拆分之后的Region读取的仍然是原存储文件，直到“合并”过程把存储文件异步地写到独立的文件之后，才会读取新文件。

下图是一个HBase表被划分成多个Region

下图是一个Region会分裂成多个新的Region

每个Region默认大小是100MB到200MB，是HBase中负载均衡和数据分发的基本单位。Master主服务器会把不同的Region分配到不同的Region服务器上，但是同一个Region不会被分拆到多个Region服务器，每个Region服务器管理一个Region 集合，通常每个Region服务器存储10-1000个Region。每个Region的最佳大小取决于单台服务器的有效处理能力，目前每个Region最佳大小建议1GB-2GB。

上图是不同的Region可以分布在不同的Region服务器上。

3.Region的定位

Region分为元数据Region以及用户Region两类，“元数据表”，又名“.META.表”，存储了Region和Region服务器的映射关系。当HBase表很大时， .META.表也会被分裂成多个Region，为了定位这些Region，新的映射表就是“根数据表”，又名“-ROOT-表”，记录所有元数据的具体位置。-ROOT-表只有唯一一个Region，名字是在程序中被写死的，Master主服务器永远知道他的位置。

综上所述，HBase使用类似B+树的三层结构来保存Region位置信息，下表给出了HBase三层结构中每个层次的名称及具体作用。

为了加快访问速度，.META.表的全部Region都会被保存在内存中。假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为128MB，那么，上面的三层结构可以保存的用户数据表的Region数目的计算方法是：（-ROOT-表能够寻址的.META.表的Region个数）×（每个.META.表的 Region可以寻址的用户数据表的Region个数）。一个-ROOT-表最多只能有一个Region，也就是最多只能有128MB，按照每行（一个映射条目）占用1KB内存计算，128MB空间可以容纳128MB/1KB=2的17次行，也就是说，一个-ROOT-表可以寻址2的17次个.META.表的Region。同理，每个.META.表的 Region可以寻址的用户数据表的Region个数是128MB/1KB=2的17次。最终，三层结构可以保存的Region数目是(128MB/1KB) × (128MB/1KB) = 2的34个Region。

客户端访问用户数据之前，需要首先访问ZooKeeper，获取-ROOT-表的位置信息，然后访问-ROOT-表，获得.META.表的信息，接着访问.META.表，找到所需的Region具体位于那个Region服务器，最后才会到该Region服务器读取数据。为了加速寻址过程，一般会在客户端做缓存，把查询过的位置信息缓存起来，这样以后访问相同的数据时，就可以直接从客户端缓存中获取Region的位置信息，而不需要每次都经历一个“三级寻址”过程。

当一个客户端从ZooKeeper服务器上拿到-ROOt-表的地址后，就可以通过“三级寻址”找到用户数据表所在的Region服务器，并直接访问Region服务器获得数据，没有必要再连接服务器Master。

四、HBase的运行机制

1.HBase的系统架构

HBase的系统架构如下图所示，包括客户端、ZooKeeper服务器、Master主服务器、Region服务器。

（1）客户端
客户端包含访问HBase的接口，同时在缓存中维护着已经访问过的Region位置信息，用来加快后续数据访问过程

（2） Zookeeper服务器
在HBase服务器集群中，包含了一个Master和多个Region服务器，Master就是这个HBase集群的“总管”，它必须知道Region服务器的状态。每个Region服务器都需要到ZooKeeper中进行注册，ZooKeeper会实时监控到每个Region服务器的状态并通知给Master，Master就可以通过ZooKeeper随时感知到各个Region服务器的工作状态。

Zookeeper可以帮助选举出一个Master作为集群的总管，并保证在任何时刻总有唯一一个Master在运行，这就避免了Master的“单点失效”问题。

（3） Master
主服务器Master主要负责表和Region的管理工作：

• 管理用户对表的增加、删除、修改、查询等操作
• 实现不同Region服务器之间的负载均衡
• 在Region分裂或合并后，负责重新调整Region的分布
• 对发生故障失效的Region服务器上的Region进行迁移

（4）Region服务器
Region服务器是HBase中最核心的模块，负责维护分配给自己的Region，并响应用户的读写请求。

2.Region服务器的工作原理

Region服务器是HBase中最核心的模块，Region服务器内部管理了一系列Region对象和一个HLog文件，其中HLog是磁盘上面的记录文件，它记录着所有的更新操作。每个Region对象又是由多个Store组成的，每个Store对应了表中的一个列族的存储。每个Store又包含了一个MemStore和若干个StoreFile，其中，MemStore是在内存中的缓存，保存最近更新的数据；StoreFile是磁盘中的文件，这些文件都是B树结构的，方便快速读取。
下图是Region服务器向HDFS文件系统中读写数据

（1）用户读数据过程
用户写入数据时，被分配到相应Region服务器去执行。用户数据首先被写入到MemStore和Hlog中。只有当操作写入Hlog之后，commit()调用才会将其返回给客户端。当用户读取数据时，Region服务器会首先访问MemStore缓存，如果找不到，再去磁盘上面的StoreFile中寻找
（2）缓存的刷新
Memstore缓存的容量有限，系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文件中，清空缓存，并在Hlog里面写入一个标记用来表示缓存中的内容已经写入StoreFile文件中。每次缓存刷新都生成一个新的StoreFile文件，因此，每个Store包含多个StoreFile文件。

每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务。
（3）StoreFile的合并
每次刷写都生成一个新的StoreFile，数量太多，影响查找速度，为了减少查找时间，系统一般调用Store.compact()把多个合并成一个大文件。由于合并操作比较耗费资源，只有数量达到一个阈值才启动合并操作。

3.Store的工作原理

Region服务器是HBase的核心模块，而Store则是Region服务器的核心。每个Store对应了表中的一个列族的存储，每个Store包含一个MemStore缓存和若干个StoreFile文件。

MemStore是排序中的内缓冲区，当用户写入数据时，系统首先把数据放入MemStore缓存，当MemStore缓存满时，就会刷新磁盘中的一个StoreFile文件中。随着StoreFile文件数量的不断增加，当事先达到设定的数量时，就会触发文件合并操作，多个StoreFile文件会被合并成一个大的StoreFile文件。当多个StoreFile文件合并后，会逐步形成越来越大的StoreFile文件，当单个StoreFile文件大小超过一定阀值时，就会触发文件分裂操作。

4.HLog的工作原理

在分布式环境中必须要考虑系统出错，HBase采用HLog保证系统恢复到正确的状态。HBase系统为每个Region服务器配置了一个HLog文件，它是一种预写式日志（Write Ahead Log），用户更新数据必须首先写入日志后，才能写入MemStore缓存，并且，直到MemStore缓存内容对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘。

Zookeeper会实时监测每个Region服务器的状态，当某个Region服务器发生故障时，Zookeeper会通知Master。Master首先会处理该故障Region服务器上面遗留的HLog文件，这个遗留的HLog文件中包含了来自多个Region对象的日志记录。系统会根据每条日志记录所属的Region对象对HLog数据进行拆分，分别放到相应Region对象的目录下，然后，再将失效的Region重新分配到可用的Region服务器中，并把与该Region对象相关的HLog日志记录也发送给相应的Region服务器。Region服务器领取到分配给自己的Region对象以及与之相关的HLog日志记录以后，会重新做一遍日志记录中的各种操作，把日志记录中的数据写入到MemStore缓存中，然后，刷新到磁盘的StoreFile文件中，完成数据恢复。

在HBase系统中，每个Region服务器只需要维护一个HLog文件，所有Region对象共用一个HLog，而不是每个Region使用一个HLog。

总结

本节介绍了分布式数据库HBase相关概念、数据模型、系统架构以及实现原理，本篇文章借鉴了下面两本大数据书籍，在此郑重感谢。

《大数据技术原理与应用（第2版）》 林子雨编著
《大数据原理与技术》 黄史浩编著