Hbase -1- 概述

一、Hbase介绍

1. Hbase介绍

Hbase 是一个高可用、高性能的分布式、版本化、面向列的分布式数据库。主要用于存储半结构化和非结构化的松散数据。其表模式为：键值对。构建在hdfs和zookeeper集群之上。

2. Hbase特点

多版本：表中的每一列的数据存储有多个版本。

高可靠性：基于HDFS底层存储，依赖HDFS本身的副本机制，保证数据的安全。同时其主从架构保证集群的高可用。

数据自动分配，通过区域分散在集群中，支持跨集群数据复制

能够处理结构化和非结构化数据

3. 适用场景

基于hdfs的应用场景可知，hbase适用于数据体量大的半结构化或非结构化数据的场景，同时由于其支持多版本，因此对于需要存储历史变动记录数据的场景非常适合。

二、数据模型

1. 数据结构类型

数据类型	说明
结构化数据	具有属性划分，结构固定以及类型等信息的数据，如关系型数据库中的数据。
半结构化数据	具有一定结构，同时又具有一定灵活性的文本数据。如xml, json等
非结构化数据	没有固定结构的数据，如文本文件、图片、视屏等

2. 数据库存储方式

这里只列出三种，其他还包括 文档存储、图形数据库，有兴趣可以继续深入了解。

存储方式	说明	特点	场景
行存	数据按行存储在底层文件系统中，通常每一行数据会被分配固定的空间	随机的增删改成操作，频繁的插入或更新操作，性能依赖索引和视图。	适用于小批量的数据处理，常用在OLTP，不适合分布式、高并发以及海量数据处理。代表MYSQL
列存	把一列中的数据值串在一起存储在底层文件系统中。	只访问涉及到的列，降低IO，所以查询快；同一类型数据，所以压缩比高。但是插入更新慢，不适合数据频繁变化。	适用于海量数据下的数据分析，常用在OLAP。不适合数据频繁更新，以及含有删除更新等操作的实时操作等场景。代表GP
KV存储	NoSQL存储的一种方式。数据按键值对形式进行组织、索引以及存储。K唯一标识，用于快速检索一条记录，V用来存储实际数据。会产生一定的结构化空间开销如类型、时间戳。	高度可分区，可水平扩展。	适合不涉及过多数据关系或业务关系的业务数据。代表Hbase

3. 模型概念

转换显示格式：

RowKey	TimeStamp	info			data
		name	gender	age	hobby
rk001	2023-03-21xxx	zhangsan	female	30	manyplay
rk002	2023-03-21xxx	lishi	bbbb	22	aaa
...	...	...	...	...	...

RowKey：行的主键，唯一标识一行数据，用于快速检索数据。

CF：（Column Family） 列簇，同一个列簇的所有成员具有相同的前缀，通常同一类型的列存放在一个列簇下， 如 info, data。

Qualifier：列，也叫列的标识，每个列簇包含多个列，每个列的字段名就是列的标识，如name, age。访问格式：列簇:列, 如：info:name 。

Cell：单元格，在hbase中定位一个具体数据值需要通过 RowKey + CF + Qualifier + TimesTamp 四个元素， 如： 'rk001','info:name'

TimeStamp：时间戳，插入单元格的时间错，默认作为单元格的版本号，默认倒排，取最新。

4. 数据模型

Hbase将数据存放在带有标签的表中，表有行和列组成，行和列交叉为一个单元格，每个单元格有版本号，版本号为数据插入该单元格的时间戳。单元格的内容没有数据类型，所有数据均视为未解释的字节数组。

表中每一行有一个行键，根据行键的字节序排序，对表的访问通过行键。

表中的列又划分为多个列簇，同一个列簇的成员有相同的前缀，具体的列有列标识。列簇和列标识组合起来标识某一列。

创建表时，列簇必须作为模式定义的一部分预先给出，但列簇是可以动态扩展的，后续可按需加入。

三、Hbase架构

1. 系统架构

注：图片来源于网络

从图上可以看到包含：

HMaster：

创建新表时分配Region，保证集群负载均衡.

监控管理所有RegionServer, 包括负责RS的故障转移、RS的负载均衡。

管理元数据（元数据主要是数据的地址信息，hbase:meta）。

后台线程包括：

LoadBalancer 控制Region，平衡集群负载。

CatalogJanitor 周期性检查hbase:meta表

HRegionServer：数据服务进程，负载处理用户数据读写请求，所有的Region的flush、compaction、open、close、load等操作的执行都交由RS管理，所有用户数据的读写请求都和RS管理的Region交互。同时会定期的将在线状态的Region信息、内存使用状态等信息汇报给HMaster,管理归档日志等。

HLog: WAL, 主要用于实现数据的高可靠性（数据在随机写入时先写入HLog, 再写入缓存，达到缓存溢出阈值后刷新落盘）。另外也用于实现HBase集群间的主从复制（从节点通过回放主节点的HLog日志实现）。

HRegion：Hbase分布式存储的基本单元，可以理解为表的一个分片，将一个数据表按Key值范围横向划分为多个子表，实现分布式存储和负载均衡。这些子表就是Region, 每个Region 关联一个key值范围。当Region的某个列簇达到阈值（默认256M）会分层两个新的Region。

Store：每一个Region会有一个或多个Store组成（一个列簇一个Store）。Store包含一个MemStore和多个或0个 SotreFile。

MemStore：写缓存，数据在持久化前会被存储到内存中。

StoreFile：内存的数据刷新到文件后就是StoreFile，其底层是以Hfile格式保存。

Hfile：Hbase中KV数据的存储格式，是hadoop的二进制格式文件。Hfile文件是不定长的，包含Trailer 和 FileInfo, Trailer中指针指向其他数据块的起点，FileInfo记录文件的基本信息。

2. 工作原理

1. Region的定位

前面提到HBase 集群建立在HDFS和ZK之上，存储依赖HDFS集群，元数据管理和故障切换依赖ZK集群。

元数据管理就包括Region的定位。通过zkCli.sh 可以查看到HBase注册到zk的信息，其中meta-region-server包含存放hbase:meta表的RegionServer信息（一个集群中hbase:meta只有一份），而catalog table存放在hbase:meta表中。

定位流程：

a. 客户端通过查找zk的meta-region-server获取hbase:meta存放在哪台RegionServer机器上。

b. 客户端连接该RegionServer机器，获取要存取的RowKey属于哪个Region的范围以及这个Region属于哪台RegionServer机器。

c. 获取这些信息后，客户端可以直接连接具体的RegionServer机器进行操作。

d. 客户端把meta信息缓存，下次操作优先使用本地meta信息，减少上述的查询操作。

2. Hbase启动

HMaster启动 待补充

HRegion 启动 待补充

3. 读数据

a. Region定位略。

b. 客户端向该RS发送请求。

c. 从 MemStore -> BlockCache -> StoreFile 顺序查找数据。将查询的数据进行合并，然后把数据写入到BlockCache进行缓存，最后再返回给客户端。

4. 写数据

a. Region定位略。

b. 客户端向该RS发送请求。

c. 客户端的put操作会将数据优先写入HLog（WAL）,再将数据写入到MemStore中，数据会在内存中排序。

d. 数据写入到内存后，客户端会收到ACK（保证I/O的高性能读写）。

e. 当内存中的数据达到阈值后，数据会被刷新到HFile（磁盘）。

5. MemStore Flush操作

Flush 过程

a. 系统会周期性的把MemStore的数据刷新到磁盘的StoreFile中，清空缓存，并在HLog中写入标记。

b. 每次刷新会生成一个新的StoreFile文件。

c. 每个Region都会有一个HLog, 每次启动都会检查该文件，确认最后一次执行刷新操作后是否有新的写入操作，如果有新的操作，则先写入MemStore，再刷新到StoreFile， 然后删除旧的HLog, 开始为用户提供服务。

Flush 触发条件(官网-默认配置)

MemStore 限制：当Region 中任意一个MemStore大小达到上限hbase.hregion.memstore.flush.size默认128M，会触发Flush。

Region限制：当Region中多有的MemStore的总和达到上限hbase.hregion.memstore.block.multiplier(默认4) * hbase.hregion.memstore.flush.size（默认128M），会触发Flush。

RegionServer限制：当RegionServer中MemStore的大小总和超过系统高水位的阈值（hbase.regionserver.global.memstore.size），RS会强制Flush，从最大的Region开始。如果仍高，则RS会阻塞更新并强制Flush。

6. Store工作原理

前面提到一个Region 包含一个和多个Store, 一个Store就代表一个列簇，每个Store又包含了一个MemStore 和N多个StoreFile。当用户写入数据时，会被分配到相应的Region所在的RS去执行。数据会先写入MemStore，再Flush到StoreFile，随后清空MemStore，这样就会存在多个StoreFile， 当需要访问Store的某个值时就需要查找所有的StoreFile，非常耗时。所有Hbase就存在一个分裂和合并的问题。

合并：

随着StoreFile文件的数量增加并达到阈值，会触发文件合并，合并包括 minor 、major两张方式。

minor 小范围合并，默认3-10个文件合并，不删除其他版本数据。过程快，IO相对低。

major 将Region下所有的StoreFile文件合并，最终合并成一个文件，并删除其他版本数据。

分裂：

当单个StoreFile大小超过阈值后，会把当前的Region分割成两个，并由HMaster分配给相应的RegionServer上，旧的Region会下线。HBase只是增加数据，所有的更新删除都在合并阶段做。

7. HLog工作原理

HLog记录数据的所有变更操作，每个RegionServer维护一个HLog，所以HLog包含多个Region对象的日志记录。共用日志可以提高对表的写操作性能，但恢复是需要分拆日志。

a. ZK实时监控着RegionServer的状态。如果某个RegionServer故障，ZK会通知Master，Master首先会处理故障RegionServer遗留的HLog， 根据每条日志记录所属的Region对象对HLog进行拆分，分别放到相应的Region对上的目录下，然后将失效的Region重新分配到可用的RegionServer上，并把与该Region对象相关的HLog日志记录发送给相应的RegionServer。

b. RegionServer接收到相应的HLog后，会重新做一次日志记录的各种操作，把日志记录的数据写入到MemStore中，然后刷新到StoreFile，完成数据恢复。

四、参考

https://www.w3cschool.cn/hbase_doc/hbase_doc-vxnl2k1n.html

https://bbs.huaweicloud.com/blogs/301024?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=other&utm_content=content