HBase--分布式非关系型数据库HBase入门精讲（侧重原理）

一、HBase介绍

HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。

1. HBase 数据模型

1）HBase可以有多个Name Space（命名空间），类似于关系型数据库的 DatabBase 概念，每个命名空间下有多个表。HBase有两个自带的命名空间，分别是 hbase 和 default，hbase 中存放的是 HBase 内置的表，default 表是用户默认使用的命名空间
2）逻辑上，HBase 表的数据模型同关系型数据库很类似，数据存储在一张表中，有行有列
3）HBase的列是以Column Family（列族）区分的，并以列族为物理存储的依据，每个列族里有一个或多个列（Column Qualifier），列可以动态指定增加
4）HBase每行都有一个Row Key(RK),并且RK唯一,类似于java 的Map中的key，当key已存在时，会覆盖之前的数据，RK也是物理存储的依据
5）当数据量很大时，横向上，连续的（字典排序）若干行会被分隔成若干Region（切片）；而纵向上会被分成若干列族。这样整个表会被切分成若干个Store，每个Store就是HBase物理存储的一个单元

2.HBase的物理存储结构

1）HBase以每个Store为单元进行存储
2）每个单元在存储时会被转化为一个类似于关系型数据库的二维表，这个"二维表"每一行的核心为原Region中的一个Cell对应的值，其他都为描述这个value的属性值
3）“二维表”中除了RK、列族名、列名和value之外，还会有一个TimeStamp（时间戳）与一个Type(操作类型）
4）一条修改指令下达之后，HBase中的数据不会马上按指令进行修改，而是增加一条数据，该数据中标记时间戳与操作类型，查询时会根据时间戳查询最新的一条数据，获取响应的值。例如t3手机号为131***，t4修改为177***，这两条数据在一定时间内会同时存在，查询时会取t4时间的数据。
5) RowKey/列族名/列名/时间戳 共同确定一个Cell，cell中的数据以字节码形式存储

3.HBase的基本架构

1）HBase集群本身分为Master与RegionSever
1.1）Master负责表结构相关的操作，create/delete/alter等table级ddl（数据定义）操作，并负责管理RegionSever
1.2）RegionServer负责数据的具体操作，get/put/delete等data级dml（数据操纵）操作，并负责region的切分与合并
2）Hadoop集群中，HBase的运行依赖于Zookeeper与HDFS
2.1）HBase 通过 Zookeeper 来做 Master 的高可用、RegionServer 的监控、元数据的入口以及集群配置的维护等工作
2.2）HDFS负责具体的数据存储

4.HBase的完整架构

1）HBASE依赖于两大组件–Zookeeper与HDFS
2.1）如果是dml操作，name客户端请求过来时首先访问zk，获取系统命名空间hbase下的meta表所在的regionsever

• 查看zk上的/hbase/meta-region-server

[zk: localhost:2181(CONNECTED) 3] get /hbase/meta-region-server
�regionserver:16020At�r�F�OPBUF

        hadoop103�}�����/

• 查看hbase命名空间下meta表的信息

hbase(main):001:0> scan 'hbase:meta'
ROW                            COLUMN+CELL
…省略…
 stu,,1649124000807.41f1089de1 column=info:server, timestamp=1649124001468, value=hadoop103:16020
 d69147feb992583365b0c7.
…省略…
2 row(s) in 0.3060 seconds

2.2）这一步如果是ddl操作，会由HMaster请求ZK后直接调用相关的regionsever执行
3）获取到regionsever之后，regionserver会进行具体的执行与存储
4）该请求中的操作会首先被写到一个HLog中（也就是wal，类似于hdfs的edits文件），然后再被加载到内存中
5）一个regionserver可维护多个HRegion,每个HRegion根据列族分为多个Store，Store与Store的存储时相互隔离的
6）内存中的数据在逻辑上被分为若干Mem Store，当执行flush操作时会被持久化，形成一个一个的StoreFile，Store File文件过多时会有compact的合并过程。StoreFile以HFile规定的文件格式存储。
7）flush的过程中，regionsever会调用hdfs的客户端，将StoreFile保存到HDFS（dataNode的磁盘）中。

二、Hbase的工作流程

1.HBase写数据流程

1）client首先访问zk，获取hbase系统命名空间下的meta表所在的regionserver（图中的hadoop102）
2）然后访问meta表所在的regionserver（hadoop102），获取当前请求关联的region所在的regionserver（图中的hadoop103）
3）table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache
4）向region所在的regionserver（图中的hadoop103）发送put请求，进行数据的写入
5）写数据时先写到HLog（wal，预写入日志），再加载到内存中（Mem Store）
6）flush时内存中的数据会持久化为StoreFile

2.Flush流程

1）在一个RegionSever里可以有多个Region，一个Region可以有多个Store，每个Store有自己的内存区，即MemStore
2）在达到一定条件时执行flush，每个MemStore会持久化到HDFS形成一个StoreFile文件
3）不同Store的StoreFile隔离存储在不同的HDFS目录中

• 查看storefile文件：

[atguigu@hadoop104 bin]$ hdfs dfs -ls /HBase/data/default/stu/41f1089de1d69147feb992583365b0c7/office_info/
Found 1 items
-rw-r--r--   3 atguigu supergroup       5263 2022-04-05 11:23 /HBase/data/default/stu/41f1089de1d69147feb992583365b0c7/office_info/51587257d4e04740b08fea5e7f11d5c4

• flush的触发设置：

1. regionserver级的触发

    <property>  
        <name>hbase.regionserver.global.memstore.size</name>  
        <value></value>  
        <description>regionServer的全局memstore的大小，超过该大小会触发flush到磁盘的操作,默认是堆大小的40%,而且regionserver级别的flush会阻塞客户端读写</description>  
    </property> 
    <property>  
        <name>hbase.regionserver.global.memstore.size.lower.limit</name>  
        <value></value>  
        <description>可以理解为一个安全的设置，有时候集群的“写负载”非常高，写入量一直超过flush的量，这时，我们就希望memstore不要超过一定的安全设置。在这种情况下，写操作就要被阻塞一直到memstore恢复到一个“可管理”的大小, 这个大小就是默认值是堆大小 * 0.4 * 0.95，也就是当regionserver级别的flush操作发送后,会阻塞客户端写,一直阻塞到整个regionserver级别的memstore的大小为 堆大小 * 0.4 *0.95为止</description>  
    </property> 

    <property>  
        <name>hbase.regionserver.optionalcacheflushinterval</name>  
        <value>3600000</value>  
        <description>内存中的文件在自动刷新之前的最后一条数据能够存活的最长时间，默认是1h </description>  
    </property>  

2. region级的触发

    <property>  
        <name>hbase.hregion.memstore.flush.size</name>  
        <value>134217728</value>  
        <description>单个region里memstore的缓存大小，超过那么整个HRegion就会flush,默认128M </description>  
    </property>  

3.HBase读数据流程

1）client首先访问zk，获取hbase系统命名空间下的meta表所在的regionserver（图中的hadoop102）
2）然后访问meta表所在的regionserver（hadoop102），获取当前请求关联的region所在的regionserver（图中的hadoop103）
3）table 的 region 信息以及 meta 表的位置信息缓存在客户端的 meta cache
4）读流程比写流程多了一个Block Cache，用于storefile中的数据缓存
5）分别在 Block Cache（读缓存），MemStore 和 Store File（HFile）中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete）。
6）将从Store File文件中查询到的数据块（Block，HFile 数据存储单元，默认大小为 64KB）缓存到Block Cache
7）将合并后的最终结果按时间戳最大返回给客户端
8）由于读流程会访问磁盘空间，所以比写流程慢

4.HBase的合并流程–Compact

两种compact的区别

• compact（MinorCompaction）：简单合并，合并小文件，保留数据的版本。将临近的若干个较小的 HFile 合并成一个较大的 HFile，但不会清理过期和删除的数据
• major_compact：合并所有文件，并只保留新版本。将一个 Store 下的所有的 HFile 合并成一个大 HFile，并且会清理掉过期和删除的数据。

有关compact的配置

    <property>  
        <name>hbase.hregion.majorcompaction</name>  
        <value>604800000</value>  
        <description>一个region进行 major compaction合并的周期,在这个点的时候， 这个region下的所有hfile会进行合并,默认是7天,major compaction非常耗资源,建议生产关闭(设置为0)，在应用空闲时间手动触发 </description>  
    </property>