HBase基础知识

 1、HBase特点

1）海量存储

Hbase适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。这与Hbase的极易扩展性息息相关。正式因为Hbase良好的扩展性，才为海量数据的存储提供了便利。

2）列式存储

这里的列式存储其实说的是列族存储，Hbase是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定。

3）极易扩展

Hbase的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。
通过横向添加RegionSever的机器，进行水平扩展，提升Hbase上层的处理能力，提升Hbsae服务更多Region的能力。

备注：RegionServer的作用是管理region、承接业务的访问，这个后面会详细的介绍通过横向添加Datanode的机器，进行存储层扩容，提升Hbase的数据存储能力和提升后端存储的读写能力。

4）高并发

由于目前大部分使用Hbase的架构，都是采用的廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百ms之间。这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。

5）稀疏

稀疏主要是针对Hbase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间的。

2、HBase数据模型

逻辑上，HBase 的数据模型同关系型数据库很类似，数据存储在一张表中，有行有列。但从 HBase 的底层物理存储结构（K-V）来看，HBase 更像是一个多维度的map( multi-dimensional map)。

1）hbase逻辑结构

2）hbase物理结构

3、HBase架构

 架构角色：
1）Region Server
Region Server 为 Region 的管理者，其实现类为 HRegionServer，主要作用如下:
对于数据的操作：get, put, delete；
对于 Region 的操作：splitRegion、compactRegion。
2）Master
Master 是所有 Region Server 的管理者，其实现类为 HMaster，主要作用如下：
对于表的操作：create, delete, alter
对于RegionServer的操作：分配regions到每个RegionServer，监控每个RegionServer
的状态，负载均衡和故障转移。
3）Zookeeper
HBase 通过 Zookeeper 来做 Master 的高可用、RegionServer 的监控、元数据的入口以及
集群配置的维护等工作。
4）HDFS
HDFS 为 HBase 提供最终的底层数据存储服务，同时为 HBase 提供高可用的支持

5）StoreFile
保存实际数据的物理文件，StoreFile 以 HFile 的形式存储在 HDFS 上。每个 Store 会有
一个或多个 StoreFile（HFile），数据在每个 StoreFile 中都是有序的。
6）MemStore
写缓存，由于 HFile 中的数据要求是有序的，所以数据是先存储在 MemStore 中，排好序后，等到达刷写时机才会刷写到 HFile，每次刷写都会形成一个新的 HFile。
7）WAL
由于数据要经 MemStore 排序后才能刷写到 HFile，但把数据保存在内存中会有很高的概率导致数据丢失，为了解决这个问题，数据会先写在一个叫做 Write-Ahead logfile 的文件中，然后再写入 MemStore 中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。

4、HBase读流程：

 

1）Client先访问zookeeper，从meta表读取region的位置，然后读取meta表中的数据。meta中又存储了用户表的region信息；

2）根据namespace、表名和rowkey在meta表中找到对应的region信息；

3）找到这个region对应的regionserver；

4）查找对应的region；

5）先从MemStore找数据，如果没有，再到BlockCache里面读；

6）BlockCache还没有，再到StoreFile上读(为了读取的效率)；

7）如果是从StoreFile里面读取的数据，不是直接返回给客户端，而是先写入BlockCache，再返回给客户端。

5、HBase写流程：

 

1）Client 先访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server。
2）访问对应的 Region Server，获取 hbase:meta 表，根据读请求的 namespace:table/rowkey，查询出目标数据位于哪个 Region Server 中的哪个 Region 中。并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache，方便下次访问。
3）与目标 Region Server 进行通讯；
4）将数据顺序写入（追加）到 WAL；
5）将数据写入对应的 MemStore，数据会在 MemStore 进行排序；
6）向客户端发送 ack；
7）等达到 MemStore 的刷写时机后，将数据刷写到 HFile。

5、HBase Shell基本操作

5.1 基本操作

1．查看帮助命令

hbase(main):001:0> help

2．查看当前数据库中有哪些表

hbase(main):002:0> list

 5.2 表的操作

1．创建表

hbase(main):002:0> create 'student','info'

2．插入数据到表

hbase(main):003:0> put 'student','1001','info:sex','male'

hbase(main):004:0> put 'student','1001','info:age','18'

hbase(main):005:0> put 'student','1002','info:name','Janna'

hbase(main):006:0> put 'student','1002','info:sex','female'

hbase(main):007:0> put 'student','1002','info:age','20'

3．扫描查看表数据

hbase(main):008:0> scan 'student'

hbase(main):009:0> scan 'student',{STARTROW => '1001', STOPROW  => '1001'}

hbase(main):010:0> scan 'student',{STARTROW => '1001'}

4．查看表结构

hbase(main):011:0> describe ‘student’

5．更新指定字段的数据

hbase(main):012:0> put 'student','1001','info:name','Nick'

hbase(main):013:0> put 'student','1001','info:age','100'

6．查看“指定行”或“指定列族:列”的数据

hbase(main):014:0> get 'student','1001'

hbase(main):015:0> get 'student','1001','info:name'

7．统计表数据行数

hbase(main):021:0> count 'student'

8．删除数据

删除某rowkey的全部数据：

hbase(main):016:0> deleteall 'student','1001'

删除某rowkey的某一列数据：

hbase(main):017:0> delete 'student','1002','info:sex'

9．清空表数据

hbase(main):018:0> truncate 'student'

提示：清空表的操作顺序为先disable，然后再truncate。

10．删除表

首先需要先让该表为disable状态：

hbase(main):019:0> disable 'student'

然后才能drop这个表：

hbase(main):020:0> drop 'student'

提示：如果直接drop表，会报错：ERROR: Table student is enabled. Disable it first.

11．变更表信息

将info列族中的数据存放3个版本：

hbase(main):022:0> alter 'student',{NAME=>'info',VERSIONS=>3}

hbase(main):022:0> get 'student','1001',{COLUMN=>'info:name',VERSIONS=>3}

6、RegionServer的核心模块

RegionServer是HBase系统中最核心的组件，主要负责用户数据的读取、写入等基础操作。这个组件实际上是一个综合体系，包含多个核心模块：HLog、MemStore、HFile、BlockCache。其内部结构如下图所示：

 

一个RegionServer由一个或者多个HLog、一个BlockCache以及多个Region组成。

HLog用来保证数据写入的可靠性；BlockCache可以将数据块缓存在内存中提升数据读取性能；Region是HBase中数据表的一个数据分片，一个RegionServer通常会负责多个Region的数据读写。

一个Region由多个Store组成，每个Store存放对应列族的数据，每个Store包含一个MemStore和多个HFile，用户数据写入时会将对应列族数据写入相应的MemStore，一旦写入数据的内存大小超过设定阀值，系统就会将MemStore中的数据落盘形成HFile文件。HFile存放在HDFS上，是一种定制化格式的数据存储文件，方便用户进行数据读取。

6.1 HLog

1、Hlog简介

默认情况下，所有写入、更新、删除操作都会把数据先写入HLog，再写入MemStore。大多数情况下，HLog并不会被读取。但是在HBase的RegionServer故障，MemStore中数据尚未flush到磁盘，这时就需要回放HLog进行数据恢复。此外，HBase主从集群数据复制也是通过将HLog日志发送给从集群，然后从集群再执行回放来完成。

2、HLog文件结构

 

3、HLog文件存储

HBase中所有数据（包括HLog以及用户实际数据）都存储在HDFS的指定目录。其中，/hbase/WALs存储当前还未过期的日志；/hbase/oldWALs存储已经过期的日志。/hbase/WALs目录下通常会有多个子目录，每个子目录代表一个对应的RegionServer。

4、Hlog生命周期

 

1）HLog构建：HBase的任何写入（更新、删除）操作都会先将记录追加写入到HLog文件中。

2）HLog滚动：HBase后台启动一个线程，每隔一段时间（由参数'hbase.regionserver. logroll.period'决定，默认1小时）进行日志滚动。日志滚动会新建一个新的日志文件，接收新的日志数据。日志滚动机制主要是为了方便过期日志数据能够以文件的形式直接删除。

3）HLog失效：写入数据一旦从MemStore中落盘，对应的日志数据就会失效。为了方便处理，HBase中日志失效删除总是以文件为单位执行。查看某个HLog文件是否失效只需确认该HLog文件中所有日志记录对应的数据是否已经完成落盘，如果日志中所有日志记录已经落盘，则可以认为该日志文件失效。一旦日志文件失效，就会从WALs文件夹移动到oldWALs文件夹。注意此时HLog并没有被系统删除。

4）HLog删除：Master后台会启动一个线程，每隔一段时间（参数'hbase.master.cleaner. interval'，默认1分钟）检查一次文件夹oldWALs下的所有失效日志文件，确认是否可以删除，确认可以删除之后执行删除操作。确认条件主要有两个：

             •该HLog文件是否还在参与主从复制。对于使用HLog进行主从复制的业务，需要继续确认是否该HLog还在应用于主从复制。

             •该HLog文件是否已经在OldWALs目录中存在10分钟。为了更加灵活地管理HLog生命周期，系统提供了参数设置日志文件的TTL（参数'hbase.master.logcleaner.ttl'，默认10分钟），默认情况下oldWALs里面的HLog文件最多可以再保存10分钟。

6.2 MemStore

MemStore 是 HBase 非常重要的组成部分，MemStore 作为 HBase 的写缓存，保存着数据的最近一次更新，同时是HBase能够实现高性能随机读写的重要组成。

MemStore的主要作用：

1. 更新数据存储在 MemStore 中，使用 LSM（Log-Structured Merge Tree）数据结构存储，在内存内进行排序整合。即保证写入数据有序（HFile中数据都按照RowKey进行排序），同时可以极大地提升HBase的写入性能。

2. 作为内存缓存，读取数据时会优先检查 MemStore，根据局部性原理，新写入的数据被访问的概率更大。

3. 在持久化写入前可以做某些优化，例如：保留数据的版本设置为1，持久化只需写入最新版本。

如果一个 HRegion 中 MemStore 过多（Column family 设置过多），每次 flush 的开销必然会很大，并且生成大量的 HFile 影响后续的各项操作，因此建议在进行表设计的时候尽量减少 Column family 的个数。

 

6.3、HFile

MemStore中数据落盘之后会形成一个文件写入HDFS，这个文件称为HFile。HFile参考BigTable的SSTable和Hadoop的TFile实现。从HBase诞生到现在，HFile经历了3个版本，其中V2在0.92引入，V3在0.98引入。HFile V1版本在实际使用过程中发现占用内存过多，HFile V2版本针对此问题进行了优化，HFile V3版本和V2版本基本相同，只是在cell层面添加了对Tag数组的支持。

6.4、BlockCache

为了提升读取性能，HBase实现了一种读缓存结构--BlockCache。客户端读取某个Block,首先会检查该Block是否存在于Block Cache，如果存在就直接加载出来，如果不存在则去Hfile文件中加载，加载出来之后放到BlockCache中。后续同一请求或者邻近数据查找请求可以直接去内存中获取，以避免昂贵的IO操作。

BlockCache主要用来缓存Block.需要关注的是，Block是Hbase中最小的数据读取单元。

BlockCache本质使用的是一个ConcurrentHashMap来管理BlockKey到Block的映射关系。

BlockCache是regionServer级别的。一个RegionServer只有一个BlockCache.在Region启动的时候完成BlockCache的初始化工作。到现在为止，针对BlockCache有3种实现方案。

1.         LRUBlockCache是最早的实现方案，也是默认的实现方案。
2.         SlabCache 在hbase0.98版本之后，已经不建议使用该方案。
3.         BucketCache  基于SlabCache设计的一种高效缓存方案。

7、 Compaction

7.1 compaction基本工作原理

compact是从一个Region的一个Store中选择部分HFile文件进行合并。合并原理是先从这些待合并的数据文件中依次读出keyvalue，再由小到大排序后写入一个新的文件中。之后这个新生成的文件就会取代之前已合并的所有文件对外提供服务。

HBase根据合并规模将Compact分为两类，Minor Compaction和Major Compaction。

• Minor Compaction是指选取部分小的、相邻的HFile，将它们合并成一个更大的HFile。
• Major Compaction是指将一个Store中所有的HFile合并成一个HFile，这个过程会清理三类无意义的数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。

一般情况下，Major Compaction持续时间比较长，整个过程消耗大量系统资源，因此线上数据量较大的业务通常推荐关闭自动触发Major Compaction功能，改为在业务低峰期手动触发（或设置策略自动在低峰期触发）。

Compaction的意义：

• 合并小文件，减少文件数，稳定随机读延迟
• 提高数据的本地化率
• 清除无效数据，减少数据存储量

7.2 Minor Compaction 和 Major Compcation

1. Minor Compaction：根据配置策略，自动检查小文件，合并到大文件，从而减少碎片文件，然而并不会立马删除掉旧 HFile 文件。
   是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell。一次Minor Compaction的结果是更少并且更大的StoreFile。Minor Compaction会影响HBase的性能，所以合并文件的数目是有限制的，默认10个。
2. 

 

      2. Major Compaction：与上边不同，每个 CF 中，不管有多少个 HFiles 文件，最终都是将 HFiles 合并到一个大的 HFile 中，并且把所有的旧 HFile 文件删除，即CF 与 HFile 最终变成一一对应的关系。
是指将所有的StoreFile合并成一个StoreFile，这个过程还会清理三类无意义数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。另外，一般情况下，Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发Major Compaction功能，改为手动在业务低峰期触发。

 

7.3 compaction基本流程

HBase中Compaction只有在特定的触发条件才会执行，比如部分flush操作完成之后、周期性的Compaction检查操作等。一旦触发，HBase会按照特定流程执行Compaction，如图所示。

 

(1) Compaction触发时机: 

 HBase中触发Compaction的时机有很多种，最常见的时机有三种：MemStore Flush、后台线程周期性检查以及手动触发。

(2) 选择合适HFile合并: 

 HBase接下来会再判断是否满足major compaction条件，如果满足，就会选择全部文件进行合并。判断条件有下面三条，只要满足其中一条就会执行major compaction：

1.  用户强制执行major compaction
2. 长时间没有进行compact（CompactionChecker的判断条件2）且候选文件数小于hbase.hstore.compaction.max（默认10）
3. Store中含有Reference文件，Reference文件是split region产生的临时文件，只是简单的引用文件，一般必须在compact过程中删除

如果不满足major compaction条件，就必然为minor compaction，HBase主要有两种minor策略：RatioBasedCompactionPolicy和ExploringCompactionPolicy，下面分别进行介绍：

• RatioBasedCompactionPolicy
  从老到新逐一扫描所有候选文件，满足其中条件之一便停止扫描：
  • 当前文件大小 < 比它更新的所有文件大小总和 * ratio，其中ratio是一个可变的比例，在高峰期时ratio为1.2，非高峰期为5，也就是非高峰期允许compact更大的文件。那什么时候是高峰期，什么时候是非高峰期呢？用户可以配置参数hbase.offpeak.start.hour和hbase.offpeak.end.hour来设置高峰期
  • 当前所剩候选文件数 <= hbase.store.compaction.min（默认为3）

停止扫描后，待合并文件就选择出来了，即为当前扫描文件+比它更新的所有文件

• ExploringCompactionPolicy 该策略思路基本和RatioBasedCompactionPolicy相同，不同的是，Ratio策略在找到一个合适的文件集合之后就停止扫描了，而Exploring策略会记录下所有合适的文件集合，并在这些文件集合中寻找最优解。最优解可以理解为：待合并文件数最多或者待合并文件数相同的情况下文件大小较小，这样有利于减少compaction带来的IO消耗。

(3) 挑选合适的线程池：

HBase实现中有一个专门的类CompactSplitThead负责接收Compaction请求和split请求。

(4) 执行HFile文件合并:

合并流程主要分为如下几步：

1. 分别读出待合并hfile文件的KV，并顺序写到位于./tmp目录下的临时文件中
2. 将临时文件移动到对应region的数据目录
3. 将compaction的输入文件路径和输出文件路径封装为KV写入WAL日志，并打上compaction标记，最后强制执行sync
4. 将对应region数据目录下的compaction输入文件全部删除