下载掌阅APP，畅读海量书库
立即打开
任务描述：了解HBase的基本概念及相关组件，理解HBase的特性。
HBase是一个可以进行随机访问的数据存储和检索平台。它不要求数据有预定义的模式，可应用于列式存储，允许同一列不同行的数据类型不同，因此可以存储结构化和半结构化的数据。例如，一些网站可以将自己的网页及相关日志数据存储到HBase中。
HBase 最初是 Powerset 公司为处理自然语言搜索产生的海量数据而开展的项目，由查德·沃特斯（Chad Walters）和吉姆·凯勒曼（Jim Kellerman）发起，经过两年发展为Apache软件基金会的顶级项目。HBase的实现源自Google公司在2006年11月发表的一篇关于BigTable的论文，由于BigTable的源码并未对外开放，因此HBase项目发起人根据此论文在2007年2月提出了HBase的原型，并介绍了相关概念及底层数据存储结构的设计。由于HBase基于Hadoop的HDFS，因此HBase的版本需要与Hadoop版本相匹配。2007年10月，第一版HBase随同Hadoop 0.15.0版本一起发布，此版本只实现了最基本的模块，其功能还不完善。2008年1月，Hadoop升级为Apache软件基金会的顶级项目，HBase作为Hadoop的子项目而存在。随后HBase的发展非常活跃，而Hadoop发展逐渐成熟，更新速度逐渐减缓。2010年6月，HBase发布了HBase 0.89.x版本后不再与Hadoop关联发布。2010年，HBase也成为Apache软件基金会的顶级项目，并在2015年2月发布了较为成熟的版本HBase 1.0.0。2017年，HBase 2.0.0-Alpha-1发布，这是一个里程碑式的版本，对PostgreSQL协议的支持、S3备份、缓存性能的提高等使HBase变得更加健壮，适应性强。
HBase官网已发布的HBase版本（截至2023年10月）如图2-1所示。
图2-1 HBase官网已发布的版本（部分）
相关的历史版本可以参考 HBase 的历史归档列表。在实际的生产环境中，我们不建议使用最新版本的HBase，因为它的性能一般不太稳定，而是建议从历史归档列表中选择性能稳定的HBase版本。本书使用的版本为HBase 2.4.17。HBase支持的Hadoop版本如图2-2所示。
图2-2 HBase支持的Hadoop版本
HBase是分布式、可扩展、列式存储、适用于稀疏数据存储的非关系数据库，由行键、列键和时间戳共同索引的多维有序映射数据库，既可以存储结构化数据，也可以存储半结构化数据。它在Hadoop生态系统的HDFS的基础之上提供海量数据的分布式存储，在Hadoop生态系统的MapReduce的基础上提供分布式并行计算。HBase和Hadoop类似，也可以进行横向扩展，通过横向增加低配的个人计算机来增加集群的节点，实现扩容和提高计算能力。
HBase具有以下显著的特性。
（1）容量巨大
HBase的单表存储量可以达到数十亿行、数百万列。而对于关系数据库来说，当单表存储数据规模达到亿级别时，它的读/写性能会呈指数级下降。对于HBase数据表来说，单表存储数据达百亿行甚至更多的数据都没有性能问题，这是因为它采用了日志结构合并（Log Structured Merge,LSM）树结构来存储数据，会定期将小文件合并成大文件，从而减少对磁盘的访问量。
（2）列式存储
关系数据库是面向行存储的，同一行数据存储在同一块内存中。而 HBase 是面向列存储的，同一列的数据存储在同一块内存中，可以针对某一列数据进行独立检索。行存储和列存储如图2-3所示。
图2-3 行存储与列存储
在进行插入、更新数据时，行式存储相对容易一些。在查询数据时，行存储需要读取所有的数据，而列存储只需读取相应的列，这可以有效降低系统输入/输出（Input/Output, I/O）压力。
（3）稀疏性
在传统的关系数据库中，每一个字段类型通常是预先定义好的，即使对应的值为缺失值，也需要占用内存空间。而 HBase 面向列存储且其字段类型都是字符串，当字段为缺失值时并不占用内存空间，因而解决了数据的稀疏问题，在很大程度上节省了内存空间。HBase通常可以设计成稀疏矩阵形式，这种方式其实更加接近现实中的场景。
（4）扩展性强
HBase基于Hadoop的HDFS，因而继承了HDFS可扩展的特性，支持分布式表，可以进行横向扩展，通过将服务器节点增加到现有的集群中来实现扩容。HBase数据表根据Region的大小进行分区，然后将Region分别存储于不同的服务器节点。当增加节点时，新节点启动 HBase 服务进程，集群会动态进行调整。这里的扩展是热扩展，即在 HBase服务进程不停止的前提下，增加或者减少节点。
（5）高可靠性
HDFS的多副本机制可以让HBase在出现故障时自动恢复，同时HBase内部也提供了预写日志（Write-Ahead Logging,WAL）和副本机制。预写日志用于记录 HBase 服务器处理数据所执行插入、删除等操作内容，确保 HBase 在写数据时不会因集群异常而导致写入数据的丢失。副本机制基于日志操作来同步数据。当集群中的某个节点异常时，协调服务组件（ZooKeeper）通知集群主节点，将故障节点的 HLog 日志信息分发给各个从节点进行数据恢复。
我们从图2-4中可以看出HBase在Hadoop生态系统中的位置。
图2-4 Hadoop生态系统
HBase系统架构如图2-5所示，其中包括客户端、ZooKeeper服务器、HMaster主服务器、HRegionServer()数据节点服务器等。
图2-5 HBase系统架构
（1）客户端
客户端是整个HBase系统的入口，用于操作HBase。一般地，客户端与HMaster进行管理类操作的通信，在获取到HRegionServer节点的信息后，直接与HRegionServer进行数据读/写类操作的通信，获取并缓存Region数据块的位置信息，以加速后续的访问过程。HBase为开发者提供了多种客户端，比如HBase Shell、Java API，以及通过Thrift服务来连接Python等其他语言接口。
（2）ZooKeeper
ZooKeeper是一种分布式应用程序的协调服务，主要用于解决分布式应用中经常出现的数据管理问题，如数据的发布/订阅、分布式协调/通知、集群管理、HMaster 选举、分布式锁等。ZooKeeper在HBase中的协调任务如下。
① HMaster节点选举。在HBase集群中，多个HMaster并存。HBase通过竞争选举机制保证同一时刻只有一个主 HMaster 活跃，一旦这个节点故障，就从备用的 HMaster中选出一个作为顶替，从而保证集群的高可靠性。
② 系统容错。在整个HBase集群启动时，每个HRegionServer会注册到ZooKeeper服务中，并创建一个状态节点。ZooKeeper 通过心跳机制来监控这些已注册的HRegionServer的状态，同时HMaster也会监控他们的状态。当某个HRegionServer故障后，ZooKeeper会因接收不到它的心跳信息而将其状态节点删除，并通知HMaster。此时，HMaster会调度其他的节点，并开启容错机制。
③ Region元数据管理。在HBase集群中，数据库的表信息、列族信息及列族的存储位置信息均属于元数据。Region元数据存储在Meta表中，Meta表位置信息以非临时znode （ZooKeeper 中的节点）的方式注册到 ZooKeeper 中。客户端每次发起请求时，需先查询Meta表，然后获取Region位置信息。当Region发生变化时，可以通过ZooKeeper感知这一变化，从而保证客户端获取到正确的Region元数据。
（3）HMaster
HBase集群的主服务器HMaster负责监控所有的HRegionServer，同时负责表和Region的管理工作，具体如下。
① 管理用户对数据表所执行的增、删、改、查等操作。HMaster提供的接口如表2-1所示。
表2-1 HMaster提供的接口
② 管理HRegionServer的负载均衡，处理HRegionServer的故障转移。
③ 调整Region的分布，分配和移除Region。
HMaster通常运行在HDFS的NameNode节点上，通过ZooKeeper来避免单点故障的出现。
（4）HRegionServer
HRegionServer一般运行在HDFS的DataNode节点上，主要负责响应客户端的读/写数据请求，最终实现在HDFS中读/写数据。每个HRegionServer可存储多个Region。它包含的功能如下。
① 处理分配的Region，以及拆分与合并Region。
② 处理客户端的读/写请求。
③ 刷新缓存，并把缓存写入到HDFS中。
④ 执行数据的压缩算法。
下面介绍一些常见的适合使用HBase的场景。
场景1：数据模式是动态可变的，存储结构化数据和半结构化数据。
场景2：数据库中的列包含很多空值的稀疏数据。
场景3：需要很高的吞吐量，存在写入海量数据的需求。
场景4：需要数据存储具有高可靠性、高可扩展性，整个系统可动态扩展。
场景5：如搜索引擎存储海量网页、监控参数、用户交互数据等应用。