HBase工作原理学习

共计 6833 个字符，预计需要花费 18 分钟才能阅读完成。

HBase 工作原理学习

HBase 是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用 HBase 技术可在廉价 PC Server 上搭建大规模结构化的存储集群。HBase 的目标是存储并处理大型数据，具体来说是仅需使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。

与 MapReduce 的离线批处理计算框架不同，HBase 是一个可以随机访问的存储和检索数据平台，弥补了 HDFS 不能随机访问数据的缺陷，适合实时性要求不是非常高的业务场景。HBase 存储的都是 Byte 数组，它不介意数据类型，允许动态、灵活的数据模型。

HBase 工作原理学习

上图描述了 Hadoop 2.0 生态系统中的各层结构。其中 HBase 位于结构化存储层，HDFS 为 HBase 提供了高可靠性的底层存储支持，MapReduce 为 HBase 提供了高性能的批处理能力，Zookeeper 为 HBase 提供了稳定服务和 failover 机制，Pig 和 Hive 为 HBase 提供了进行数据统计处理的高层语言支持，Sqoop 则为 HBase 提供了便捷的 RDBMS 数据导入功能，使业务数据从传统数据库向 HBase 迁移变的非常方便。

HBase 是一个分布式的数据库，使用 Zookeeper 管理集群，使用 HDFS 作为底层存储。在架构层面上由 HMaster（Zookeeper 选举产生的 Leader）和多个 HRegionServer 组成，基本架构如下图所示：

HBase 工作原理学习

在 HBase 的概念中，HRegionServer 对应集群中的一个节点，一个 HRegionServer 负责管理多个 HRegion，而一个 HRegion 代表一张表的一部分数据。在 HBase 中，一张表可能会需要很多个 HRegion 来存储数据，每个 HRegion 中的数据并不是杂乱无章的。HBase 在管理 HRegion 的时候会给每个 HRegion 定义一个 Rowkey 的范围，落在特定范围内的数据将交给特定的 Region，从而将负载分摊到多个节点，这样就充分利用了分布式的优点和特性。另外，HBase 会自动调节 Region 所处的位置，如果一个 HRegionServer 过热，即大量的请求落在这个 HRegionServer 管理的 HRegion 上，HBase 就会把 HRegion 移动到相对空闲的其它节点，依次保证集群环境被充分利用。

HBase 由 HMaster 和 HRegionServer 组成，同样遵从主从服务器架构。HBase 将逻辑上的表划分成多个数据块即 HRegion，存储在 HRegionServer 中。HMaster 负责管理所有的 HRegionServer，它本身并不存储任何数据，而只是存储数据到 HRegionServer 的映射关系（元数据）。集群中的所有节点通过 Zookeeper 进行协调，并处理 HBase 运行期间可能遇到的各种问题。HBase 的基本架构如下图所示：

HBase 工作原理学习

Client：使用 HBase 的 RPC 机制与 HMaster 和 HRegionServer 进行通信，提交请求和获取结果。对于管理类操作，Client 与 HMaster 进行 RPC；对于数据读写类操作，Client 与 HRegionServer 进行 RPC。

Zookeeper：通过将集群各节点状态信息注册到 Zookeeper 中，使得 HMaster 可随时感知各个 HRegionServer 的健康状态，而且也能避免 HMaster 的单点问题。

HMaster：管理所有的 HRegionServer，告诉其需要维护哪些 HRegion，并监控所有 HRegionServer 的运行状态。当一个新的 HRegionServer 登录到 HMaster 时，HMaster 会告诉它等待分配数据；而当某个 HRegion 死机时，HMaster 会把它负责的所有 HRegion 标记为未分配，然后再把它们分配到其他 HRegionServer 中。HMaster 没有单点问题，HBase 可以启动多个 HMaster，通过 Zookeeper 的选举机制保证集群中总有一个 HMaster 运行，从而提高了集群的可用性。

HRegion：当表的大小超过预设值的时候，HBase 会自动将表划分为不同的区域，每个区域包含表中所有行的一个子集。对用户来说，每个表是一堆数据的集合，靠主键（RowKey）来区分。从物理上来说，一张表被拆分成了多块，每一块就是一个 HRegion。我们用表名 + 开始 / 结束主键，来区分每一个 HRegion，一个 HRegion 会保存一个表中某段连续的数据，一张完整的表数据是保存在多个 HRegion 中的。

HRegionServer：HBase 中的所有数据从底层来说一般都是保存在 HDFS 中的，用户通过一系列 HRegionServer 获取这些数据。集群一个节点上一般只运行一个 HRegionServer，且每一个区段的 HRegion 只会被一个 HRegionServer 维护。HRegionServer 主要负责响应用户 I / O 请求，向 HDFS 文件系统读写数据，是 HBase 中最核心的模块。HRegionServer 内部管理了一系列 HRegion 对象，每个 HRegion 对应了逻辑表中的一个连续数据段。HRegion 由多个 HStore 组成，每个 HStore 对应了逻辑表中的一个列族的存储，可以看出每个列族其实就是一个集中的存储单元。因此，为了提高操作效率，最好将具备共同 I / O 特性的列放在一个列族中。

HStore：它是 HBase 存储的核心，由 MemStore 和 StoreFiles 两部分组成。MemStore 是内存缓冲区，用户写入的数据首先会放入 MemStore，当 MemStore 满了以后会 Flush 成一个 StoreFile（底层实现是 HFile），当 StoreFile 的文件数量增长到一定阈值后，会触发 Compact 合并操作，将多个 StoreFiles 合并成一个 StoreFile，合并过程中会进行版本合并和数据删除操作。因此，可以看出 HBase 其实只有增加数据，所有的更新和删除操作都是在后续的 Compact 过程中进行的，这样使得用户的写操作只要进入内存就可以立即返回，保证了 HBaseI/ O 的高性能。当 StoreFiles Compact 后，会逐步形成越来越大的 StoreFile，当单个 StoreFile 大小超过一定阈值后，会触发 Split 操作，同时把当前的 HRegion Split 成 2 个 HRegion，父 HRegion 会下线，新分出的 2 个子 HRegion 会被 HMaster 分配到相应的 HRegionServer，使得原先 1 个 HRegion 的负载压力分流到 2 个 HRegion 上。

HLog：每个 HRegionServer 中都有一个 HLog 对象，它是一个实现了 Write Ahead Log 的预写日志类。在每次用户操作将数据写入 MemStore 的时候，也会写一份数据到 HLog 文件中，HLog 文件会定期滚动刷新，并删除旧的文件（已持久化到 StoreFile 中的数据）。当 HMaster 通过 Zookeeper 感知到某个 HRegionServer 意外终止时，HMaster 首先会处理遗留的 HLog 文件，将其中不同 HRegion 的 HLog 数据进行拆分，分别放到相应 HRegion 的目录下，然后再将失效的 HRegion 重新分配，领取到这些 HRegion 的 HRegionServer 在加载 HRegion 的过程中，会发现有历史 HLog 需要处理，因此会 Replay HLog 中的数据到 MemStore 中，然后 Flush 到 StoreFiles，完成数据恢复。

HBase 的所有 HRegion 元数据被存储在.META. 表中，随着 HRegion 的增多，.META. 表中的数据也会增大，并分裂成多个新的 HRegion。为了定位.META. 表中各个 HRegion 的位置，把.META. 表中所有 HRegion 的元数据保存在 -ROOT- 表中，最后由 Zookeeper 记录 -ROOT- 表的位置信息。所有客户端访问用户数据前，需要首先访问 Zookeeper 获得 -ROOT- 的位置，然后访问 -ROOT- 表获得.META. 表的位置，最后根据.META. 表中的信息确定用户数据存放的位置，如下图所示。

HBase 工作原理学习

-ROOT- 表永远不会被分割，它只有一个 HRegion，这样可以保证最多只需要三次跳转就可以定位任意一个 HRegion。为了加快访问速度，.META. 表的所有 HRegion 全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问相关.META. 表的 Region 服务器，试图获取数据的位置，如果还是失败，则询问 -ROOT- 表相关的.META. 表在哪里。最后，如果前面的信息全部失效，则通过 ZooKeeper 重新定位 HRegion 的信息。所以如果客户端上的缓存全部是失效，则需要进行 6 次网络来回，才能定位到正确的 HRegion。

HBase 是一个类似于 BigTable 的分布式数据库，它是一个稀疏的长期存储的（存在 HDFS 上）、多维度的、排序的映射表。这张表的索引是行关键字、列关键字和时间戳。HBase 的数据都是字符串，没有类型。

HBase 工作原理学习

可以将一个表想象成一个大的映射关系，通过行键、行键 + 时间戳或行键 + 列（列族：列修饰符），就可以定位特定数据。由于 HBase 是稀疏存储数据的，所以某些列可以是空白的。上表给出了 com.cnn.www 网站的数据存放逻辑视图，表中仅有一行数据，行的唯一标识为“com.cnn.www”，对这行数据的每一次逻辑修改都有一个时间戳关联对应。表中共有四列：contents:html、anchor:cnnsi.com、anchor:my.look.ca、mime:type，每一列以前缀的方式给出其所属的列族。

行键（RowKey）是数据行在表中的唯一标识，并作为检索记录的主键。在 HBase 中访问表中的行只有三种方式：通过某个行键访问、给定行键的范围访问、全表扫描。行键可以是任意字符串（最大长度 64KB）并按照字典序进行存储。对于那些经常一起读取的行，需要对键值精心设计，以便它们能放在一起存储。

HBase 工作原理学习

上图是 HRegionServer 数据存储关系图。上文提到，HBase 使用 MemStore 和 StoreFile 存储对表的更新。数据在更新时首先写入 HLog 和 MemStore。MemStore 中的数据是排序的，当 MemStore 累计到一定阈值时，就会创建一个新的 MemStore，并且将老的 MemStore 添加到 Flush 队列，由单独的线程 Flush 到磁盘上，成为一个 StoreFile。与此同时，系统会在 Zookeeper 中记录一个 CheckPoint，表示这个时刻之前的数据变更已经持久化了。当系统出现意外时，可能导致 MemStore 中的数据丢失，此时使用 HLog 来恢复 CheckPoint 之后的数据。

StoreFile 是只读的，一旦创建后就不可以再修改。因此 Hbase 的更新其实是不断追加的操作。当一个 Store 中的 StoreFile 达到一定阈值后，就会进行一次合并操作, 将对同一个 key 的修改合并到一起，形成一个大的 StoreFile。当 StoreFile 的大小达到一定阈值后，又会对 StoreFile 进行切分操作，等分为两个 StoreFile。

步骤 1：Client 通过 Zookeeper 的调度，向 HRegionServer 发出写数据请求，在 HRegion 中写数据。

步骤 2：数据被写入 HRegion 的 MemStore，直到 MemStore 达到预设阈值。

步骤 3：MemStore 中的数据被 Flush 成一个 StoreFile。

步骤 4：随着 StoreFile 文件的不断增多，当其数量增长到一定阈值后，触发 Compact 合并操作，将多个 StoreFile 合并成一个 StoreFile，同时进行版本合并和数据删除。

步骤 5：StoreFiles 通过不断的 Compact 合并操作，逐步形成越来越大的 StoreFile。

步骤 6：单个 StoreFile 大小超过一定阈值后，触发 Split 操作，把当前 HRegion Split 成 2 个新的 HRegion。父 HRegion 会下线，新 Split 出的 2 个子 HRegion 会被 HMaster 分配到相应的 HRegionServer 上，使得原先 1 个 HRegion 的压力得以分流到 2 个 HRegion 上。

步骤 1：client 访问 Zookeeper，查找 -ROOT- 表，获取.META. 表信息。

步骤 2：从.META. 表查找，获取存放目标数据的 HRegion 信息，从而找到对应的 HRegionServer。

步骤 3：通过 HRegionServer 获取需要查找的数据。

步骤 4：HRegionserver 的内存分为 MemStore 和 BlockCache 两部分，MemStore 主要用于写数据，BlockCache 主要用于读数据。读请求先到 MemStore 中查数据，查不到就到 BlockCache 中查，再查不到就会到 StoreFile 上读，并把读的结果放入 BlockCache。

半结构化或非结构化数据：对于数据结构字段不够确定或杂乱无章，很难按一个概念去进行抽取的数据适合用 HBase。如随着业务发展需要存储更多的字段时，RDBMS 需要停机维护更改表结构，而 HBase 支持动态增加。

记录非常稀疏：RDBMS 的行有多少列是固定的，为空的列浪费了存储空间。而 HBase 为空的列不会被存储，这样既节省了空间又提高了读性能。

多版本数据：根据 RowKey 和列标识符定位到的 Value 可以有任意数量的版本值（时间戳不同），因此对于需要存储变动历史记录的数据，用 HBase 将非常方便。

超大数据量：当数据量越来越大，RDBMS 数据库撑不住了，就出现了读写分离策略，通过一个 Master 专门负责写操作，多个 Slave 负责读操作，服务器成本倍增。随着压力增加，Master 撑不住了，这时就要分库了，把关联不大的数据分开部署，一些 join 查询不能用了，需要借助中间层。随着数据量的进一步增加，一个表的记录越来越大，查询就变得很慢，于是又得搞分表，比如按 ID 取模分成多个表以减少单个表的记录数。经历过这些事的人都知道过程是多么的折腾。采用 HBase 就简单了，只需要在集群中加入新的节点即可，HBase 会自动水平切分扩展，跟 Hadoop 的无缝集成保障了数据的可靠性（HDFS）和海量数据分析的高性能（MapReduce）。

HBase 工作原理学习

HBase 中 Table 和 Region 的关系，有些类似 HDFS 中 File 和 Block 的关系。由于 HBase 提供了配套的与 MapReduce 进行交互的 API 如 TableInputFormat 和 TableOutputFormat，可以将 HBase 的数据表直接作为 Hadoop MapReduce 的输入和输出，从而方便了 MapReduce 应用程序的开发，基本不需要关注 HBase 系统自身的处理细节。

Hadoop+HBase 搭建云存储总结 PDF http://www.linuxidc.com/Linux/2013-05/83844.htm

Ubuntu Server 14.04 下 Hbase 数据库安装 http://www.linuxidc.com/Linux/2016-05/131499.htm

HBase 结点之间时间不一致造成 regionserver 启动失败 http://www.linuxidc.com/Linux/2013-06/86655.htm

Hadoop+ZooKeeper+HBase 集群配置 http://www.linuxidc.com/Linux/2013-06/86347.htm

Hadoop 集群安装 &HBase 实验环境搭建 http://www.linuxidc.com/Linux/2013-04/83560.htm

基于 Hadoop 集群的 HBase 集群的配置 http://www.linuxidc.com/Linux/2013-03/80815.htm‘

Hadoop 安装部署笔记之 -HBase 完全分布模式安装 http://www.linuxidc.com/Linux/2012-12/76947.htm

单机版搭建 HBase 环境图文教程详解 http://www.linuxidc.com/Linux/2012-10/72959.htm

HBase 的详细介绍 ：请点这里
HBase 的下载地址 ：请点这里

本文永久更新链接地址 ：http://www.linuxidc.com/Linux/2016-08/134185.htm