4.1 导读

本章主要讲述开源的非关系型分布式数据库HBase，它可以满足大规模数据实时处理应用的需求。

• HBase能否应用于实时响应查询计算的应用场景？

  HBase的优势在于实时计算，所有实时数据都直接存入HBase中，客户端通过API直接访问HBase，实现实时计算。由于它使用的是nosql，或者说是列式结构，从而提高了查找性能，使其能运用于大数据场景，这是它跟MapReduce的区别。

• 为什么说HBase是键值类型数据库？

  KV将简单的键映射到（可能）更复杂的值，就像一个巨大的哈希表。

• HBase的主要角色有哪些？分别提供什么作用？

  • HMaster

    监控RegionServer
    处理RegionServer故障转移
    处理元数据变更
    处理region的分配或移除
    空闲时对数据进行负载均衡
    通过zookeeper发布自己的位置给客户端

  • RegionServer

    负责存储Hbase的实际数据
    处理分配给它的region
    刷新缓存到HDFS上
    维护HLog
    执行压缩
    负责处理Region分片

• Zookeeper对HBase提供了什么服务支持？

  Zookeeper 作用有三点：
  1、分布式锁
  2、事件监控
  3、存储HBase的Region Server数据，充当微型数据库

4.2 HBase 简介

HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统。

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

  大表（bigtable）结构：BigTable是一个疏松的分布式的持久的多维排序的map，这个map有行健、列键和时间戳索引，每一个值都是连续的byte数组。

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

• 利用Zookeeper作为协同服务。

  Zookeeper 作用有三点：
  1、分布式锁
  2、事件监控
  3、存储HBase的Region Server数据，充当微型数据库

1. HBase与RDB的对比

HBase与传统的关系数据库的区别主要体现在以下几个方面：

• 数据索引：关系数据库通常可以针对不同列构建复杂的多个索引，以提高数据访问性能。HBase只有一个索引——行键 (row key)，通过巧妙的设计，HBase中的所有访问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来。
• 数据维护：在关系数据库中，更新操作会用最新的当前值去替换记录中原来的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新操作时，并不会删除数据旧的版本，而是生成一个新的版本，旧有的版本仍然保留。
• 可伸缩性：关系数据库很难实现横向扩展，纵向扩展的空间也比较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的，能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩。

2.HBase应用场景

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

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

• 对象存储：1B~100M 对象存储（图片、网页、文本、新闻） —— 海量存储
• 时序数据：时间序列数据（传感器、监控数据、股票K线）—— 高并发/海量存储
• 气象数据：卫星轨道、气象数据 —— 高并发/海量存储
• Cube分析：实时报表 —— 高并发/海量存储
• NewSQL：元数据库、索引查询 —— SQL、二级索引、动态列
• Feeds流：朋友圈 —— 高并发请求
• 消息/订单存储：聊天信息、订单/保存存储 —— 强同步 海量数据
• 用户画像：用户特征存储 —— 万列稀疏矩阵
• 兼容结构化/非结构化数据，数据存储容量大，高并发，低时延，低成本的数据库

4.3 HBase数据模型

1. 表结构

• 表：HBase采用表来组织数据，表由行和列组成，列划分为若干个列族。
• 行：每个HBase表都由若干行组成，每个行由行键（row key）来标识。表按key排序，排序方式是针对字节的，所有的表都必须要有主键-key。
• 列族：一个HBase表被分组成许多“列族” ( Column Family )的集合，它是基本的访问控制单元。
• 单元格：行和列的交叉点称之为cell（单元格），cell是版本化的，根据时间戳对应不同版本。单元格中存储的数据没有数据类型，总被视为字节数组byte[]，所以任何类型数据都可以保存进去。
• 时间戳：每个单元格都保存着同一份数据的多个版本，这些版本采用时间戳进行索引。

2. 数据存储概念视图和物理视图

有一个名为webtable的表，包含两个列族: contents和anchor。在这个例子里面，anchor 有两列(anchor:aa.com, anchor:bb.com)，contents仅有1列(contents:html)，这是概念视图。

尽管在概念视图里，表可以被看成是一个稀疏的行的集合。但在物理上，它的是区分列族存储的。新的columns可以不经过声明直接加入一个列族。

3. 行存储和列存储的比较

• 行存储：数据按行存储在底层文件系统中。通常，每一行会被分配固定的空间。

  优点:有利于增加/修改整行记录等操作;有利于整行数据的读取操作。

  缺点:单列查询时,会读取一些不必要的数据。
  

• 列存储：数据以列为单位，存储在底层文件系统中。

  HBase采用列存储，为每个单元格中的值还要加上一个键。

  优点：有利于面向单列数据的读取/统计等操作。

  缺点：整行读取时，可能需要多次I/O操作。

4.4 HBase体系架构

1. 组件介绍

• Client 是HBase客户端，包含一些接口。使用HBase的RPC（远程过程调用）机制与Master、RegionServer进行通信。Client与Master进行管理类通信，与RegionServer进行数据操作类通信。
• ZooKeeper为HBase集群中各进程提供分布式协作服务（三种服务）。各RegionServer将自己的信息注册 到Zookeeper中，主用Master据此感知各个RegionServer的健康状态。
• HMaster即主控节点，在HA模式下，包含主用Master和备用Master。
  • 主用Master：负责HBase中RegionServer的管理，包括表的增删改查；RegionServer 的负载均衡；Region分布调整；Region分裂以及分裂后的Region分配；RegionServer失效后的Region迁移等。
  • 备用Master：当主用Master故障时，备用 Master 通过选举将取代主用Master对外提供服务。 故障恢复后，原主用Master降为备用。
• HRegionServer 即slaver节点，负责提供表数据读写等服务和数据存储，是HBase的数据处理和计算单元。RegionServer 一般与HDFS集群的DataNode部署在一起，实现数据的存储功能。
• HDFS为HBase提供高可靠的文件存储服务，HBase的数据全部存储在HDFS中，转化成 DataNode 中的block。

• HBase的架构包括三个主要的功能组件:
  • 库函数:链接到每个客户端
  • 一个HMaster主服务器
  • 多个HRegionServer服务器
• MemStore：当RegionServer中的MemStore大小达到配置的容量上限时，RegionServer会 将MemStore中的数据“flush”到HDFS中。
• StoreFile：随着数据的插入,一个Store会产生多个StoreFile，当StoreFile的个数达到配置的最大值时，RegionServer会将多个StoreFile合并为一个大的StoreFile。

2. 功能介绍

• 主服务器HMaster负责管理和维护HBase表的分区信息，维护HRegionServer列表，分配Region，负载均衡。
• HRegionServer负责存储和维护分配给自己的Region，处理来自客户端的读写请求。
• 客户端并不是直接从HMaster主服务器上读取数据，而是在获得Region的存储位置信息后，直接从HRegionServer上读取数据。
• 客户端并不依赖HMaster，而是通过Zookeeper来获得Region位置信息，大多数客户端甚至从来不和HMaster通信，这种设计方式使得HMaster负载很小。（也有例外，例如想创建表和表的结构需要与Master通信）

3. 存储架构

表 Table 根据行键 rowkey 横向划分，起始 rowkey 和结束 rowkey 划为一个区域存储为 Region。

一个 Region 下包含若干个 Store，每个 Store 根据列簇存储相应的 Region 数据。

MemStore 是缓存，用于临时写和查找，StoreFile 把相应 Region 数据存储到具体的物理表上，Block 就是实际的数据表，采用 Block 方式存到 HDFS 上。

4. Region

Region 的分裂

HBase表开始只有一个Region，随数据增多不断分裂。Region拆分操作非常快，拆分时的Region读取的仍然是原存储文件，直到分裂结束，把存储文件异步地写到独立的文件后，才会读取新文件。

查找与定位

旧版本HBase采用ZooKeeper文件 - root表 - meta表 三级表结构查找用户 Region。

新版本去掉了 root 表，仅保留元数据表 hbase:meta，其位置信息存储于 ZooKeeper 中，meta 表中记录了用户 Region 位置信息。

读写时先找 Meta Region，再由其中信息找 User Region。

为了加快访问速度，hbase:meta表会被保存在内存中。

假设hbase:meta表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为128MB。两层结构可以保存的Region数目是128MB/1KB =

2

17

2^{17}217个Region。

HRegionServer

HRegionServer是HBase中最核心的模块。负责存储维护分配给自己的Region，响应用户的读写请求，报告自己的心跳信息给ZooKeeper。

4.5 HBase 关键流程

1. 用户读写数据过程

1. 用户写入数据时，先访问 ZooKeeper，找到要写入的 Region，查找相应的 HRegionServer 服务器去执行写。
2. 用户数据首先被写入到Hlog中，得到一个反馈值再写入MemStore中，最终写到磁盘上形成StoreFile。
3. 只有当操作写入Hlog之后，commit()调用才会将其返回给客户端，带代表一个事务的完成。
4. 当用户读取数据时，HRegionServer会首先访问Memstore缓存，如果找不到，再去磁盘上面的StoreFile中寻找。

2. Store 刷新缓存

• 系统会周期性地把MemStore缓存里的内容刷写到磁盘的Storefile文件中，清空缓存，并在Hlog里面写入一个标记。
• 每次刷写都生成一个新的StoreFile文件，因此每个Store包含多个StoreFile文件。数量太多时会影响查找速度，所以当数量达到阀值时会调用Store.compact() 把多个合并成一个（此过程比较耗费资源）。
• 每个HRegionServer都有一个自己的HLog文件，其中的很多个 Region 共用这个 Hlog 文件。每次启动都检查该文件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作，如果发现更新，则先写入MemStore，再刷写到StoreFile，然后开始为用户提供服务。

3. 工作原理

Store 工作原理

Store是HRegionServer的核心，数量过多时可以多个StoreFile合并成一个。单个StoreFile过大时，又触发分裂操作，1个父Region被分裂成两个子Region。这样可以提高用户的查询效率。

Hlog 工作原理

分布式环境必须要考虑系统出错，HBase采用HLog保证系统恢复。

• HBase系统为每个HRegionServer配置了一个HLog文件，它是一种预写式日志(Write Ahead Log)。其中的很多个 Region 共用这个 Hlog 文件。
• 用户更新数据必须首先写入 Hlog 后，才能写入MemStore缓存。并且直到对应的日志已经写入磁盘，该缓存内容才能被刷写到磁盘。

故障处理流程

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

共用日志的优点：提高对表的写操作性能。缺点：恢复时需要分拆日志。

4.6 Hbase 突出特点

1. Compaction（压缩）

随着时间的增长，业务数据不断的往HBase集群中灌入，这时HFile的数目越来越多，那么查询时延也就越来越大。

Compaction的目的，是为了减少同一个Region中同一个ColumnFamily下面的小文件（HFile）数目，从而提升读取的性能。Compaction 过程需要消耗计算资源，中途不能进行读写。

Compaction分为Minor, Major两类:

• Minor：小范围的Compaction。有最少和最大文件数目限制。通常会选择一些连续时间范围的小文件进行合并。Minor Compaction选取文件时，遵循一定的算法。
• Major：涉及该Region该ColumnFamily下面的所有的HFile文件。

2. OpenScanner

这个机制是为了进一步提升读写性能。

OpenScanner的过程中，会创建两种不同的Scanner来读取Hfile、MemStore的数据:

• HFile对应的Scanner为StoreFileScanner
• MemStore对应的Scanner为MemstoreScanner.

在寻找到rowkey所对应的RegionServer和Region之后，需要打开一个查找器Scanner，由其具体执行查找数据，Region中会包含内存数据MemStore，文件数据Hfiles，那么在open scanner的时候就需要分别读取这两块数据，打开对应不同的scanner做查询操作。

3. BloomFilter

为了查找时缩小查找范围，使用BloomFilter用来优化一些随机读取的场景，即Get场景。它可以被用来快速的判断一条用户数据在一个大的数据集合（该数据集合的大部分数据都没法被加载到内存中）中是否存在。

BloomFilter在判断一个数据是否存在时，有一定的误判率（不存在判为存在）。但对于不存在的判断结果是可信的。

HBase的BloomFilter的相关索引数据被保存在HFile中。

4.7 HBase 性能优化

1. 行键（Row Key）

行键是按照字典序存储，因此设计行键时，将经常一起读取的数据存储到一块，将最近可能会被访问的数据放在一块，可以提高性能。

举个例子：最近写入HBase表中的数据是最可能被访问的，可以考虑将时间戳作为行键的一部分，由于是字典序排序，所以可以使用Long.MAX-VALUE-timestamp作为行键，这样能保证新写入的数据在读取时可以被快速命中。

2. 二级索引

默认情况下，HBase 只有一个针对行健的素引。要访问HBase表中的行，只有三种方式:

• 通过单个行健访问
• 通过一个行健的区间来访问
• 全表扫描

为了提高访问速度，HBase 新版本中增加了 coprocessor 特性，可以构建二级索引，例如：

• 多个表索引
• 多个列索引
• 基于部分列值的索引

华为纯 Java 开发的的 Hindex 就能实现以上功能。redis、solor也能实现这些功能。

4.8 HBase 常用 Shell 命令

4.9 课后习题

1. HBase中的数据以什么形式存储? ( D )

   A. Int

   В. Long

   C. String

   D. Byte[]

2. HBase的分布式存储的最基本单元是? ( A )

   A. Region

   B. Column Family

   C. Column

   D. Cell