分布式数据库HBase简介——《大数据技术原理与应用》课程学习总结

Hbase 是针对谷歌 BigTable 的开源实现，是一个高可靠、高性能、高向列、可伸缩的分布式数据库，主要用来存储 半结构化 和 结构化 的松散数据。支持超大规模数据存储。

4.1 概述

4.1.1 从 BigTable 说起

BigTable 是一个分布式存储系统，利用谷歌提出的 MapReduce 分布式并行计算模型来处理海量数据，使用谷歌分布式文件系统 GFS 作为提成数据存储，并采用 Chubby 提供协同服务管理，可以扩展到 PB 级别的数据和上前台机器，具备广泛应用型、可扩展性、高性能和高可用性等特点

总的来说，BigTable 具备以下特征：支持大规模海量数据、分布式并发数据处理效率极高、易于扩展且支持动态伸缩、适合于廉价设备、适合于读操作不适合写操作。

4.1.2 HBase 简介

Hbase 是针对谷歌 BigTable 的开源实现，是一个高可靠、高性能、高向列、可伸缩的分布式数据库，主要用来存储 半结构化 和 结构化 的松散数据。HBase 的目标是处理非常庞大的表，可以通过水平扩展的方式，利用廉价计算机集群处理由超过 10 亿行数据和数百万列元素组成的数据表。

下图，描述了 Hadoop 生态系统中 HBase 与其部分的关系：

HBase 利用 Hadoop MapReduce 来处理 HBase 中的海量数据，实现高性能计算；利用 Zookeeper 作为协同服务，实现稳定服务和失败恢复；利用 HDFS 作为高可靠的底层存储，利用廉价集群提供海量数据存储能力。此外，Sqoop 为 HBase 提供高效、便捷的 RDBMS 数据导入功能，Pig 和 Hive 为 HBase 提供了高层语言支持。

4.1.3 HBase 与传统关系数据库的对比分析

\	关系数据库	HBase
数据类型	采用关系模型，具有丰富的数据类型和存储方式	采用更加简单的数据模型，把数据存储为未经解释的字符串，用户可以把不同格式的结构化数据和非结构化数据都序列化成字符串保存在 HBase 中，用户需要自己解析字符串。
数据操作	增删改查，涉及复杂的多表连接	HBase 不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等
存储模式	关系数据库是基于行模式存储的	基于列存储
数据索引	可以针对不同列构建复杂的多个索引	只有一个索引——行键
数据维护	更新操作会用最新的当前值去替换记录中原来的旧值	执行更新操作时，不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留
可伸缩性	很难实现横向扩展，纵向扩展的空间也比较有限	可以灵活的进行水平扩展。轻易地通过在集群中增加或减少硬件数量来实现性能的伸缩

4.3 HBase 数据模型

4.3.1 数据模型概述

HBase 是一个稀疏、多维度、排序的映射表，这张表的索引是 行键、列族、列限定符 和 时间戳。每个值是一个未经解释的字符串，没有数据类型。表在水平方向由一个过多个列族组成，一个列族中可以包含任意多个列，同一个列族里面的数据存储在一起。

在 HBase 中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有版本仍然保留。客户端可以选择获取距离某个时间最近的版本，或者一次获取所有版本。如果在查询的时候不提供时间戳，那么会返回距离现在最近的那一个版本的数据。HBase 提供了两种数据版本回收方式：一是保存数据的最后 n 个版本；二是保存最近一段时间内的版本。

4.3.2 数据模型相关概念

1. 表

HBase 采用表来组织数据，表由行和列组成，列划分为若干列族。

2. 行

每个 HBase 表都由若干行组成，每个行由 行键（Row Key） 来标识。

访问表中的行只有三种方式：

1. 通过单个行键访问；
2. 通过一个行键的区间来访问；
3. 全表扫描。

行键可以是任意字符串，但是在 HBase 内部，行键保存为字节数组。

3. 列族

一个 HBase 表被分组成为许多“列族”集合，它是基本的访问控制单元。列族是在表创建时就已经定义好的，数量不能太多，不要频繁修改。存储在一个列族当中的数据，通常都是属于同一种数据类型，这通常意味着具有更高的压缩率。

表中的每个 列 都归属于某个列族，数据可以被存放到列族的某个列下面。列名都以列族作为前缀，例如，courses:history 和 courses:math 这连个列都属于 courses 这个列族。

在 HBase 中，访问控制、磁盘和内存的使用统计都是在列族层面进行的。实际应用中，可以借助列族上的控制权限实现特定的目的。比如：可以允许一些应用能够向表中添加新的数据，而另一些应用则只允许浏览数据。HBase 列族还可以被配置成支持不同类型的访问模式。比如：一个列族也可以被设置成放入内存中，一消耗内存为代价，从而换取更好的响应性能。

4. 列限定符

列族里的数据通过列限定符来定位。列限定符不用事先定义，也不需要在不同行之间保持一致。列限定符没有数据类型 ，总被视为字节数组 byte[]

5. 单元格

在 HBase 表中，通过行、列族和列限定符确定一个“单元格”。单元格中存储的数据没有数据类型，总被视为字节数组 byte[]。每个单元格可以保存一个数据的多个版本，每个版本对用一个不同的时间戳。

6. 时间戳

每个单元格都保存着同一份数据的多个版本，那些版本采用时间戳进行索引。每次对一个单元格执行操作（新建、修改、删除）时，HBase 都会隐式地总动生成并存储一个时间戳。一个单元格的不同版本是根据时间戳降序的顺序进行存储的，最新的版本被最先读取。

4.3.3 数据坐标

HBase 使用坐标来定位表中的数据，每个值都是通过坐标来访问的。在HBase 中需要行键、列族、列限定符和时间戳来确定一个单元格，因此可以视为一个“四维坐标”，即[行键, 列族, 列限定符, 时间戳]。

如果把所有坐标看成一个整体，视为“键”，把四维坐标对应的单元格中的数据视为“值”，那么，HBase 也可以看成一个键值数据库。

4.3.4 概念视图

在 HBase 的概念视图中，一个表可以视为一个稀疏、多维的映射关系。下图就是一个概念视图，它是一个存储网页的 HBase 表的片段。可以采用“四维坐标”来定位单元格中的数据，比如，[“com.cnn.www”, “anchor”, “anchor:cnnsi.com”, t5] 对应的单元格里面存储的是 “CNN”。可以看出来，在一个 HBase 表的概念视图中，每个行都包含相同的列族，尽管行不需要在每个列族里存储数据。从这个角度来讲，HBase 表是一个稀疏的映射关系，即里面存在很多空的单元格。

4.3.5 物理视图

从概念视图层面，HBase 中的每个表是由许多行组成的，但是在物理层面，它是采用了 基于列的存储方式，而不是传统数据库那样采用基于行的存储方式，这也是这两种数据库很重要的区别。上图中的概念视图在物理存储的时候，会存成下标中的两个小片段，HBase会按照 contents 和 anchor 这两个列族分别存放，属于同一列族的数据存放在一起，同时，和每个列族一起存放的还包括时间戳和行键。

在物理视图中，空的列是不会被存储的，当请求这些空白的单元格的时候，会返回 null 值。

4.3.6 面向列的存储

HBase 是一个面向列的存储，也就是说，HBase 是 一个“列式数据库”；而传统的关系数据库采用的是面向行的存储，被称为“行式数据库”。

面向行的数据库（行式数据库）使用 NSM（N-ary Storage Model） 存储模型，一个元组会被连续地存储在磁盘页上，也就是说，数据是一行一行被存储的。在从磁盘中读取数据时，需要从磁盘中顺序扫描每个元组的完整内容，然后从每个元组中筛选出查询所需要的属性。如果每个元组只有少量属性的值对于查询是有用的，那么 NSM 就会浪费许多磁盘空间和内存宽带。

列式数据库采用 DSM（Decomposition Storage Model） 存储模型，可以 最小化无用的 I/O。采用 DSM 存储模型的关系数据库而言，DSM 会对关系进行垂直分解，并未每个熟悉分配一个子关系。因此，一个具有 n 个属性的关系会被分解成 n 个子关系，每个子关系单独存储，只有当其相应的属性被请求是才会被访问。也就是说，DSM 是以关系数据库中的属性或者列为单位进行存储。

列式数据库的优点：

1. 可以降低 I/O 开销，支持大量并发用户查询，其数据处理速度比传统方法快 100 倍；
2. 具有较高的数据压缩比。

DSM 存储模型的缺陷是：

1. 执行连接操作时需要昂贵的元组重构代价，因为一个元组的不同属性被分散到不同磁盘页中存储。
2. 对于联机事务数据处理而言，需要频繁对一个元组进行修改，如果采用 DSM 存储模型，需要高昂的开销。

如果严格从关系数据库的角度来看，HBase 并不是一个列式存储的数据库，毕竟 HBase 是以列族为单位进行分解存储的，而不是每个列都单独存储，但是 HBase 借鉴和利用了磁盘上的这种列存储格式，可以把HBase视为列式数据库。

4.4 HBase 的实现原理

HBase 的功能组件

HBase 的实现包括3个主要的功能组件：

• 库函数，链接到每个客户端；
• 一个 Master 主服务器；
• 许多个 Region 服务器。

Region 服务器负责存储和维护分配给自己的 Region，处理来自客户端的读写请求。

主服务器 Master 负责管理和维护 HBase 表的分区信息，比如，一个表分成了哪些 Region，每个 Region 被存放在哪台 Region 服务器上同时也负责维护 Region 服务器列表。Master 会实时监测集群中 Region 服务器，把特定的 Region 服务器分配到可用的 Region 服务器上，并确保整个集群内部不同 Region 服务器之间负载均衡，当某个 Region 服务器因出现故障而失效时，Master 会把该故障服务器上存储的 Region 重新分配给其他可用的 Region 服务器。

客户端并不是直接从 Master 服务器上读取数据，而是在获取 Region 的存储位置信息后，直接从 Region 服务器上读取数据。HBase 客户端是不依赖于 Master的，而是借助于 Zookeeper 来获取 Region 的位置信息的，所以大多数客户端从来不和主服务器 Master 通信，这种设计方式使 Master 的负载很小。

4.4.2 表和 Region

在 HBase 中，会有许多表。对于每个表而言，表中的行式根据行键的值的字典进行维护的，表中包含的行的数量可能非常庞大，无法存储在一台机器中，需要分布存储到多台机器上。因此，需要根据行键的值对表中的行进行分区，每个行区间构成一个 分区，被称为 Region，包含了位于某个值域区间内的所有数据，它是负载均衡和数据分发的基本单位，这些 Region 会被分发到不同的 Region 服务器上。

初始时，每个表只包含一个 Region，随着数据的不断插入，Region 会持续增大，当一个 Region 中包含的行数量达到一个阈值时，就会被自动等分为两个新的 Region。

4.4.3 Region 的定位

HBase 使用类似 B+ 树的三层结构来保存 Region 位置信息：

层次	名称	作用
第一层	Zookeeper 文件	记录了-ROOT-表的位置信息
第二层	-ROOT-表	记录了 .META. 表的 Region 位置信息，-ROOT- 表只能有一个 Region。通过 -ROOT-表就可以访问 .META. 表中的数据
第三层	.META.表	记录了用户数据表的 Region 位置信息，.META.表可以有多个 Region，保存了 HBase 中所有用户数据表的 Region 位置信息

4.5 HBase 运行机制

4.5.1 HBase 系统架构

HBase 的系统架构一般包括，客户端、Zookeeper 服务器、Master 主服务器、Region 服务器。HBase 一般采用 HDFS 作为底层数据存储，因此下图加入了 HDFS 和 Hadoop

4.5.2 Region 服务器的工作原理

Region 服务器内部管理了一系列 Region 对象和一个 HLog 文件，其中 HLog 是磁盘上面的记录文件，他记录着所有的更新操作。每个 Region 对象又是由多个 Store 组成，每个 Store 对应了表中的一个列族的存储。每个 Store 又包含了一个 MemStore 和若干个 StoreFile，其中，MemStore 是在内存中的缓存，保存最近更新的数据；StoreFile 是磁盘中的文件，这些文件都是 B 树结构的，方便快速读取。StoreFile 在底层的实现方式是 HDFS 文件系统的 HFile，HFile 的数据块通常采用压缩方式存储，压缩之后可以大大减少网络 I/O 和磁盘 I/O。

4.5.3 Store 的工作原理

MemStore 是排序的内存缓冲区，当用户写入数据时，系统首先把数据放入 MemStore 缓存，当 MemStore 缓存满时，就会刷新到磁盘中的一个 StoreFile 文件中。

随着 StoreFile 文件数量不断增加，当达到实现设定的数量时，就会触发文件合并操作，多个 StoreFile 文件会被合并成一个大的 StoreFile 文件。当多个 StoreFile 文件合并后，会逐步形成越来越大的 StoreFile 文件，当单个 StoreFile 文件大小超过一定阈值时，就会触发文件分裂操作。同时，当前的 1 个符 Region 会被分裂成 2 个子 Region，父 Region 会下线，新分裂出的 2 个子 Region 会被 Master 分配到相应的 Region 服务器上。

4.5.4 HLog 的工作原理

在分布式环境下，必须考虑到系统出错的情形，比如当 Region 服务器发生故障是，MemStore 缓存中的数据会全部丢失。因此，HBase 采用 HLog 来保证系统发生故障时能够恢复到正常的状态。

HBase 系统为每个 Region 服务器配置一个 HLog 文件，它是一个预写式日志，用户更新数据必须首先被记入日志后才能写入 MemStore 缓存，并且知道 MemStore 缓存内容对应的日志已经被写入磁盘之后 ，该缓存内容才会被刷新写入磁盘。