深入HBase——引入

引入

前面我们通过深入HDFS到深入MapReduce ，从设计和落地，去深入了解了大数据最底层的基石------存储与计算是如何实现的。

这个专栏则开始来看大数据的三驾马车中最后一个。

通过前面我们对于GFS和MapReduce论文实现的了解，我们知道GFS在数据写入时，只对顺序写入有比较弱的一致性保障，而对于数据读取，虽然GFS支持随机读取，但在当时的硬件条件下，实际上也是支撑不了真正的高并发读取的；此外，MapReduce虽然是一个批量处理数据的框架，吞吐量很大，但其延时和额外开销也不小。

在计算机数据存储领域，一直是关系数据库（RDBMS）的天下，以至于在传统企业的应用领域，许多应用系统设计都是面向数据库设计，也就是先设计数据库然后设计程序，从而导致关系模型绑架对象模型，并由此引申出旷日持久的业务对象贫血模型（业务逻辑由服务层处理，领域对象只包含数据。服务层通过调用领域对象的属性和方法来完成业务逻辑。）与充血模型（业务逻辑在领域对象中实现。领域对象不仅包含数据，还包含与数据相关的业务逻辑。服务层只负责接收用户的请求，并调用领域对象的方法来完成业务逻辑。）之争。

业界为了解决关系数据库的不足，提出了诸多方案，比较有名的是对象数据库，但是这些数据库的出现似乎只是进一步证明关系数据库的优越而已。直到人们遇到了关系数据库难以克服的缺陷------糟糕的海量数据处理能力及僵硬的设计约束，局面才有所改善。从Google的BigTable开始，一系列的可以进行海量数据存储与访问的数据库被设计出来，更进一步说，NoSQL这一概念被提了出来。

NoSQL主要指非关系的、分布式的、支持海量数据存储的数据库设计模式。不过随着技术的演进，NoSQL的解释也从最初的"No SQL"到现在的"Not Only SQL"，表示NoSQL只是关系数据库的补充，而不是替代方案。其中，HBase是这一类NoSQL系统的杰出代表。

HBase之所以能够具有海量数据处理能力，其根本在于和传统关系型数据库设计的不同思路。传统关系型数据库对存储在其上的数据有很多约束，学习关系数据库都要学习数据库设计范式，事实上，是在数据存储中包含了一部分业务逻辑。而NoSQL数据库则简单暴力地认为，数据库就是存储数据的，业务逻辑应该由应用程序去处理。

我们可以梳理出来，Bigtable要解决核心问题就是：如何支撑业务海量数据的随机读写（例如百万级别的随机读写IOPS）。

我们自然而然能想到的就是借鉴GFS的设计思路，除此之外还需要考虑到实时处理场景下如何提高容错。

Bigtable的答案，其实总结起来就三点：

1. 将整个系统的存储层，搭建在GFS上。然后通过单Master调度多Tablets的方式，使得整个集群非常容易伸缩和维护。

2. 通过MemTable+SSTable这样一个底层文件格式，解决高速随机读写数据的问题。

3. 通过Chubby这个高可用的分布式锁服务解决一致性的挑战。

而本专栏的主角HBase，就是源自于Google的Bigtable论文。

HBase 同样利用 HDFS 作为底层存储，但是并不是简单地使用原本的数据，只是使用 HDFS 作为它的存储系统。也就是说，HBase 只是利用 Hadoop 的 HDFS 帮助其管理数据的持久化文件。HBase 提供超大规模数据集的实时随机读写，弥补了早期 Hadoop只能离线处理数据的不足。

一句话概括的话，HBase就是基于Hadoop构建的一个高可用、高性能、多版本的分布式NoSQL数据库，是Google BigTable的开源实现，通过在廉价服务器上搭建大规模结构化存储集群，提供海量数据高性能的随机读写能力。

下面我们先通过HBase的一些核心概念去初步了解一下它。

基本概念

1. 表（Table）：HBase中的表由行和列组成，一个表包含多行数据。表中的数据按照RowKey进行排序存储，支持范围查询。

2. 行（row）：，一行数据包含一个唯一标识rowkey、多个column以及对应的值。在HBase中，一张表中所有row都按照rowkey的字典序由小到大排序。

3. 行键（Row Key）：行是表中数据的基本单位，由RowKey标识。RowKey是字节序列，可以是任意长度，通常设计为能够反映数据的逻辑顺序。这是我们一行数据的唯一标识，比如说我们平时的数据都会有一个唯一 ID，就可以用来作为 Row Key。但是需要注意的是，HBase 在存储 Row Key 的时候是按照字典顺序存放的，所以如果你的 Row Key 不是以分布均匀的数字或字母开头的，很可能造成存储集中在某一台机器上，这会大大降低查询效率，所以这种时候需要设计存储的 Row Key，比如在每个 ID 的前面都加一个 HASH 值来提升查询性能。

4. 列（column）：，与关系型数据库中的列不同，HBase中的column由column family（列簇）以及qualifier（列名）两部分组成，两者中间使用":"相连。column family在表创建的时候需要指定，用户不能随意增减。一个column family下可以设置任意多个qualifier，因此可以理解为HBase中的列可以动态增加，理论上甚至可以扩展到上百万列。

5. 列簇（Column Family）：列簇是表中数据的物理存储单位，用于组织数据。列簇内的数据具有相同的列前缀，并且通常一起存储在同一个磁盘文件中。可以看作是一组列，实际上一个列簇的作用也是用来管理若干个列，优化查询速度。所以列簇的名字要尽量短，同时对于经常需要一起查询的列放在一个列簇下面。比如说对于用户信息，一个用户的静态属性（姓名、年龄、电话、地址等）可以放在一个列簇下面，动态属性（点赞、收藏、评论等）可以放在一个列簇下面。HBase表中的列簇需要预先定义，如果要新增列簇就要先停用这个表。

6. 列名（Column Qualifier）：是用于唯一标识列簇中具体列的标签。它与列簇一起组成列的完整标识。Qualifier可以动态地添加到列簇中，而无需预先定义，这使得HBase能够适应不同数据模式和需求的变化，而无需对表格的架构进行修改。

7. 单元（Cell） ：指的是一个确定的存储单元。由五元组（row, column, timestamp, type, value）组成的结构，其中type表示 Put/Delete 这样的操作类型，timestamp代表这个cell的版本。这个结构在数据库中实际是以KV结构存储的，其中（row, column, timestamp,type）是K，value字段对应KV结构的V。单元格中的数据没有类型的概念，而是以字节序列的形式存储*( 字符串正常存储，非字符串类型数据底层字节序列会转换成十六进制显示)*。每个列簇中的列可以存储多个版本的数据，每个版本由其对应的时间戳标识，并且每个版本的值都构成一 个单元格。

8. 时间戳（Timestamp）：时间戳用于记录数据的创建或修改时间，并支持多版本数据。每个单元格（Cell）都可以存储多个版本的数据，版本通过时间戳来索引。

9. 区域（Region）：一个 Region 可以看作是多行数据的集合。当一个表的数据逐渐增多，需要进行分布式存储，那么这个表就会自动分裂成多个 Region，然后分配到不同的 RegionServer 上面去。

数据模型

既然HBase是一个数据库，那最核心的自然是怎么组织存储数据了，HBase的数据模型设计主要包括以下几个方面：

1. 面向列的存储模型 ：HBase采用面向列的存储模型，表的基本单元是"列簇*（Column Family）*"。

2. 数据多版本支持：HBase支持数据的多版本，每个单元格的数据可以有多个版本，版本通过时间戳来索引。

3. 稀疏数据支持：HBase支持稀疏数据，即某些列可以为空，不会占用存储空间。

数据目录

HBase的数据目录主要包括以下几个方面：

1. 根目录 ：HBase的根目录在HDFS中是/hbase，这是所有HBase数据的顶级目录。

2. 数据目录 ：在根目录下，有一个名为/data的目录，它是HBase数据的核心存储区域，包含了所有的表数据、日志数据等。

3. Namespace目录 ：HBase中的Namespace是用来组织和管理表的命名空间。在/data目录下，根据Namespace的不同，会有相应的子目录，例如/data/default。

4. 表目录 ：每个表在Namespace目录下都有一个对应的子目录，例如/data/default/mytable。这个目录下包含了该表的所有数据。

5. Region目录 ：HBase中的表会被切分为多个Region，每个Region由一个或多个Store组成。每个Region在表目录下都有一个对应的子目录，例如/data/default/mytable/a3d605ed-33fe-4458-90ad-57c79989c730。

6. ColumnFamily目录 ：每个ColumnFamily在Region目录下都有一个对应的子目录，例如/data/default/mytable/a3d605ed-33fe-4458-90ad-57c79989c730/cf1。这个目录下包含了该ColumnFamily的所有数据。

为了更好理解HBase表存储结构，这里将HBase表存储结构分为表逻辑结构和表物理结构两个部 分介绍。

表逻辑结构

|--------|------------------|------------------|------------------|------------------|
| RowKey | Column Family || Column Family ||
| RowKey | Column Qualifier | Column Qualifier | Column Qualifier | Column Qualifier |
| rowkey | cell | cell | cell | cell |
| rowkey | cell | cell | cell | cell |
| ... | ... | ... | ... | ... |

为了更清晰理解HBase表逻辑结构，填充样例数据如下(其中89c730对应的age为空):

|--------|-------|-----|-----------|-----------|
| RowKey | staticattribute || dynamicattribute ||
| RowKey | name | age | like | favorites |
| 57c799 | chaos | 18 | hadoop | hadoop |
| 89c730 | hbase | | zookeeper | hdfs |
| ... | ... | ... | ... | ... |

表物理结构

在HBase中表数据存储并不是按照表逻辑结构进行存储，而是按照如下方式进行存储*(以先前样例数据为例)*:

|--------|------------------|------------------|-----------|-----------|--------|
| RowKey | Column Family | Column Qualifier | Timestamp | Value | |
| 57c799 | staticattribute | name | 1000 | chaos | Region |
| 57c799 | staticattribute | age | 1000 | 18 | Region |
| 57c799 | dynamicattribute | like | 1000 | hadoop | Region |
| 57c799 | dynamicattribute | favorites | 1000 | hadoop | Region |
| 89c730 | staticattribute | name | 2000 | hbase | Region |
| 89c730 | dynamicattribute | like | 2000 | zookeeper | Region |
| 89c730 | dynamicattribute | favorites | 2000 | hdfs | Region |

注意：在表逻辑结构中的空值在HBase底层不会进行存储。

HBase的物理存储结构设计主要包括以下几个方面：

1. HDFS存储：HBase的数据最终存储在HDFS上，以HFile的形式存在。HFile是HBase的物理存储文件，以列簇为单位进行存储。

2. Region：HBase通过Region来对表进行分片，每个Region负责存储某个RowKey范围内的行。当表中的数据增长到一定程度时，Region会被拆分为两个新的Region。

3. Store：每个列簇对应一个Store，用于管理该列簇的数据。Store由内存中的MemStore和磁盘上的HFile组成。数据先写入MemStore，然后定期将MemStore中的数据刷到磁盘形成HFile。

4. MemStore和HFile：MemStore是内存中的数据结构，用于缓存写入操作。当MemStore达到一定大小后，数据将被刷写到HFile中。HFile是磁盘上的物理存储文件，存储了列簇的数据。

架构设计

HBase建立在Hadoop HDFS之上，底层使用HDFS进行数据存储，HBase集群中主要由以下几个部分组成：

1. Client：Client为访问HBase的客户端，包含访问HBase的接口并维护cache来加快对HBase的访问。Client通过zookeeper获取hbase:meta表位置信息，然后获取要操作的Region信息并与该 region的RegionServer通信，发出读取或写入请求。获取的Region信息会缓存在客户端中，以便后续请求无需经过查找过程。如果Master的负载均衡器重新平衡或者由于HRegionserver宕机，都会重新指定该region的 regionserver，客户端将重新查询hbase:meta表以确定用户region的新位置。

2. HMaster：HMaster是HBase集群的主节点，负责管理RegionServer和Region的元数据、表的创建、分区的拆分和合并、Region的分配和迁移等任务。一个HBase集群中可以有多个 HMaster节点，由zk进行协调，保证只有一个HMaster运行，其余HMaster为Backup Master。

   1. 管理库表的元数据，如表对应Region信息，负责将Region分配给HRegionServer。

   2. 负责HRegionServer的负载均衡。当写入数据时负责将数据均衡的分布到各个Region上，避免HRegionServer数据存储倾斜;当读取数据时，将请求均衡的发送到各个RegionServer上，避免HRegionSever负载过大。

   3. 通过zk发现失效的HRegionServer并重新分配该HRegionServer上的Region。

3. HRegionServer ：HRegionServer可以看成HBase架构中的从节点，习惯上也可称为RegionServer，HBase集群中一般有多台HRegionServer，主要负责数据读写请求。

   一个HRegionServer包含一个HLog和多个HRegion，每个HRegion中有包含多个Store，每个 Store中又包含MemStore和StoreFile。

   1. 管理HMaster分配的Region，处理来自客户端的读写请求(如:put、get请求)，定期向 HMaster汇报Region状态。

   2. 负责Region变大拆分。当一个Region的数据量增大到一定程度，HRegionServer负责将 Region拆分为两个新的Region，实现数据均衡分布。

   3. 负责StoreFile合并。

   4. 负责与HDFS交互，将数据存储到HDFS中。

4. Zookeeper：HBase用Zookeeper进行分布式协调，帮助管理元数据、故障恢复和分布式锁。

   1. 存储HBase元数据，如:HMaster信息、HRegionServer信息、表对应HMaster信息、hbase: meta表位置信息。

   2. 协调HMaster的HA。通过zk保证HBase集群中只有一个HMaster运行，如果HMaster发生异常则通过zk选举新的HMaster提供服务。

   3. 监控RegionServer。zk监控RegionServer状态，当RegionServer异常时，会通知给HMaster 对应RegionServer上下线信息。

5. HDFS：HBase底层使用HFile格式将数据存储在HDFS中，HDFS中数据多副本可以为HBase提供高可靠、高可用性。

优缺点

优点

1. 高扩展性：HBase采用分布式架构，能够轻松扩展到数千个节点，处理PB级别的数据。

2. 高性能：HBase在处理大规模数据时表现出色，特别是在随机读写操作方面。

3. 高可靠性：HBase通过数据冗余和自动故障恢复机制，确保数据的高可用性和系统的稳定性。

4. 灵活的数据模型：HBase支持动态列，可以根据需要随时增加新的列，而无需预先定义表结构。

5. 面向列的存储：HBase采用面向列的存储模型，使得数据的读写操作更加高效，特别适合处理稀疏数据。

6. 适用于实时数据处理：HBase特别适合于实时数据处理、海量数据存储和高速随机读写等应用场景。

缺点

1. 数据模型的限制：

   • 强烈的Schema依赖：HBase的数据模型是基于列簇和列的，这要求在设计表结构时就必须明确定义列簇和列。Schema的修改成本较高，需要进行表结构的重建或者复杂的在线调整，这会影响系统可用性和性能。

   • 缺乏丰富的查询功能：与关系型数据库相比，HBase的查询功能相对简陋。它主要支持基于行键的精确查找以及范围扫描，缺乏复杂的JOIN操作、聚合函数等功能。

   • 数据原子性：HBase的行是原子性的，但列不是。这意味着在一个事务中，你只能更新整行数据，而不能单独更新某一列。

2. 性能方面的问题：

   • 写性能瓶颈：虽然HBase的读写性能都相对较高，但在高并发写操作下，HBase的写性能可能会成为瓶颈。

   • 读性能瓶颈：当数据量非常大时，扫描大量数据可能会导致读性能下降。

   • 热点区域：不均匀的数据分布会导致某些Region Server负载过重，形成热点区域，从而影响整体性能。

3. 可用性和维护性：

   • 数据一致性：HBase采用最终一致性模型，这意味数据在不同节点之间的同步存在延迟。

   • 缺乏成熟的GUI工具：与一些关系型数据库相比，HBase缺乏成熟易用的GUI工具，这给数据的管理和监控带来不便。

   • 数据备份和恢复：HBase的数据备份和恢复也相对复杂，需要额外的工具和策略来保障数据的安全性和可靠性。