文章目录

一、HBase简介

1.1 HBase定义
1.2 HBase特点
1.3 HBase数据模型
1.4 HBase基本架构
1.5 HBase完整架构
1.6 HBase Meta表

二、HBase安装
三、HBase进阶原理

3.1 写流程
3.2 读流程
3.3 MemStore Flush
3.4 StoreFile Compaction
3.5 Region Split

一、HBase简介

1.1 HBase定义

HBase是一种分布式、可扩展、支持海量数据存储的NoSQL数据库。利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群。HBase的目标是存储并处理大型的数据，更具体来说是仅需使用普通的硬件配置，就能够处理由成千上万的行和列所组成的大型数据。

1.2 HBase特点

海量存储
HBase适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。这与HBase的极易扩展性息息相关。正式因为HBase良好的扩展性，才为海量数据的存储提供了便利。
列式存储
这里的列式存储其实说的是列族（ColumnFamily）存储，HBase是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定。
极易扩展
HBase的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。通过横向添加RegionSever的机器，进行水平扩展，提升HBase上层的处理能力，提升HBase服务更多Region的能力。
高并发（多核）
由于目前大部分使用HBase的架构，都是采用的廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百ms之间。这里说的高并发，主要是在并发的情况下，HBase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。
稀疏
稀疏主要是针对HBase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间的。

1.3 HBase数据模型

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

①HBase逻辑结构
在这里插入图片描述

列族：Hbase是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定，不同的列族数据存储在不同的位置。通过列族可以将宽表进行拆分。
Region：Region类似于分区，将同一张的数据进行拆分。通过Region可以将高表进行拆分。
Row key：类似于索引，Row key是有序的，根据字典顺序进行排序。
列：纵向数据
store：数据存储在store中，一个store对应HBase表中的一个列族

②HBase物理存储结构
在这里插入图片描述
③数据模型

Name Space
命名空间类似于关系型数据库的database概念，每个命名空间下有多个表。Hbase有两个自带的命名空间，分别是hbase和default，hbase中存放的是HBase内置的表，default表是用户默认使用的命名空间。
Region
类似于关系型数据库的表概念。不同的是，HBase定义表时只需要声明列族即可，不需要声明具体的列。这意味着，往HBase写入数据时，字段可以动态、按需指定。因此，和关系型数据库相比，HBase能够轻松应对字段变更的场景。
Row
HBase表中的每行数据都由一一个RowKey和多个Column (列)组成，数据是按照RowKey的字典顺序存储的，并且查询数据时只能根据RowKey进行检索，所以RowKey的设计十分重要。
Column
HBase中的每个列都由Column Family (列族)和Column Qualifier(列限定符)进行限定，例如info: name， info: age。建表时，只需指明列族，而列限定符无需预先定义。。
Time Stamp
用于标识数据的不同版本(version) ，每条数据写入时，如果不指定时间戳，系统会自动为其加上该字段，其值为写入HBase的时间。
Cell
由{rowkey, column Family: column Qualifier, time Stamp}唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。

1.4 HBase基本架构

不完整版：
在这里插入图片描述
RegionServer的作用

Data（数据级别）：get，put，delete
Region：splitRegion（切）， compactRegion（合）

Master的作用

Table（表级别）：create，delete，alter
RegionServer：分配regions到每个RegionServer，监控每个RegionServer的状态。

1.5 HBase完整架构

在这里插入图片描述
从图中可以看出HBase是由Client、Zookeeper、Master、HRegionServer、HDFS等几个组件组成，下面来介绍一下几个组件的相关功能：

①Client

Client包含了访问HBase的接口，另外Client还维护了对应的cache来加速HBase的访问，比如cache的.META元数据的信息。

②Zookeeper

HBase通过Zookeeper来做master的高可用、RegionServer的监控、元数据的入口以及集群配置的维护等工作。具体工作如下：

通过Zookeeper来保证集群中只有1个master在运行，如果master异常，会通过竞争机制产生新的master提供服务
通过Zookeeper来监控RegionServer的状态，当RegionServer有异常的时候，通过回调的形式通知master、RegionServer上下线的信息
通过Zookeeper存储元数据的统一入口地址

③HMaster（类似NameNode）

master节点的主要职责如下：

为RegionServer分配Region
维护整个集群的负载均衡
维护集群的元数据信息
发现失效的Region，并将失效的Region分配到正常的RegionServer上
当RegionServer失效的时候，协调对应Hlog的拆分

④HregionServer（类似DataNode）

HregionServer直接对接用户的读写请求，是真正的“干活”的节点。它的功能概括如下：

管理master为其分配的Region
处理来自客户端的读写请求
负责和底层HDFS的交互，存储数据到HDFS
负责Region变大以后的拆分
负责Storefile的合并工作

⑤HDFS

HDFS为HBase提供最终的底层数据存储服务，同时为HBase提供高可用（Hlog存储在HDFS）的支持，具体功能概括如下：

提供元数据和表数据的底层分布式存储服务
数据多副本，保证的高可靠和高可用性

⑥Region

HBase表的分片，HBase表会根据RowKey值被切分成不同的region存储在RegionServer中，在一个RegionServer中可以有多个不同的Region。

⑦HFile

这是在磁盘上保存原始数据的实际的物理文件，是实际的存储文件。StoreFile是以HFile的形式存储在HDFS的。

⑧Store

HFile存储在Store中，一个Store对应HBase表中的一个列族。

⑨MemStore

内存存储存当前的数据操作，所以当数据保存在WAL中之后，RegsionServer会在内存中存储键值对。

⑩WAL（Write-Ahead logs）

当对HBase读写数据的时候，数据不是直接写进磁盘，它会在内存中保留一段时间（时间以及数据量阈值可以设定）。但把数据保存在内存中可能有更高的概率引起数据丢失，为了解决这个问题，数据会先写在一个叫做Write-Ahead logfile的文件中，然后再写入内存中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。

1.6 HBase Meta表

HBase有一个叫做Meta的特殊的目录表，用于保存集群中Regions的位置信息（Region列表）。ZooKeeper存储着Meta表的位置。
在这里插入图片描述

二、HBase安装

前提：Hadoop集群和ZooKeeper集群的正常启动。

①HBase的解压

[root@hadoop100 software]# tar -zxvf hbase-1.3.1-bin.tar.gz -C /opt/module

②修改hbase-env.sh

export JAVA_HOME=/opt/module/jdk1.8.0_144
export HBASE_MANAGES_ZK=false

③修改hbase-site.xml

	<property>     
		<name>hbase.rootdir</name>     
		<value>hdfs://hadoop100:9000/hbase</value>   
	</property>

	<property>   
		<name>hbase.cluster.distributed</name>
		<value>true</value>
	</property>

   <!-- 0.98后的新变动，之前版本没有.port,默认端口为60000 -->
	<property>
		<name>hbase.master.port</name>
		<value>16000</value>
	</property>

	<property>   
		<name>hbase.zookeeper.quorum</name>
	     <value>hadoop100:2181,hadoop101:2181,hadoop102:2181</value>
	</property>

	<property>   
		<name>hbase.zookeeper.property.dataDir</name>
	     <value>/opt/module/zookeeper-3.4.10/zkData</value>
	</property>

④修改regionservers

hadoop100
hadoop101
hadoop102

⑤软连接hadoop配置文件到hbase

[root@hadoop100 module]# ln -s /opt/module/hadoop-2.7.2/etc/hadoop/core-site.xml 
/opt/module/hbase-1.3.1/conf/core-site.xml

[root@hadoop100 module]# ln -s /opt/module/hadoop-2.7.2/etc/hadoop/hdfs-site.xml 
/opt/module/hbase-1.3.1/conf/hdfs-site.xml

⑥分发HBase

[root@hadoop100 module]# xsync hbase-1.3.1

⑦HBase服务的启动

启动方式1：

[root@hadoop100 module]# bin/hbase-daemon.sh start master
[root@hadoop100 module]# bin/hbase-daemon.sh start regionserver

启动方式2：

[root@hadoop100 hbase-1.3.1]$ bin/start-hbase.sh

停止：

[root@hadoop100 hbase-1.3.1]$ bin/stop-hbase.sh

提示：如果集群之间的节点时间不同步，会导致regionserver无法启动，抛出ClockOutOfSyncException异常。

解决①(推荐)：集群内时间同步：参考https://hucheng.blog.csdn.net/article/details/106266688

解决②：hbase-site.xml中属性：hbase.master.maxclockskew设置更大的值

<property>
	<name>hbase.master.maxclockskew</name>
	<value>180000</value>
	<description>Time difference of regionserver from master</description>
</property>

启动成功后，访问http://hadoop102:16010进入HBase管理页面：
在这里插入图片描述

三、HBase进阶原理

3.1 写流程

在这里插入图片描述

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

3.2 读流程

在这里插入图片描述

Client先访问ZooKeeper，获取hbase:meta表位于哪个RegionServer；
访问对应的RegionServer，获取hbase:meta表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个Region Server中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache，方便下次访问；
查询数据，如果Block Cache没有对应数据，同时读取内存（MemStore）和磁盘（StoreFile）中的数据（并将磁盘的数据缓存到Block Cache，LRU算法），比较时间戳返回对应的数据。
如果Block Cache有对应数据，直接比较和MemStore中数据的最大时间戳，返回该数据。

3.3 MemStore Flush

在这里插入图片描述
MemStore数据达到阈值，将数据刷到硬盘。将内存中的数据删除，同时删除HLog中的历史数据。

MemStore刷写时机：

当某个MemStore的大小达到了hbase.hregion.memstore.flush.size (默认值128M），其所在Region的所有MemStore都会刷写。
RegionServer中的MemStore大小超过hbase.regionserver.global.memstore.size（默认大小为堆大小的40%）
到达自动刷写的时间也会触发MemStore Flush，自动刷新的时间间隔由该属性进行配置hbase.regionserver.optionalcacheflushinterval (默认1小时)。

3.4 StoreFile Compaction

在这里插入图片描述
由于MemStore每次刷写都会生成一个新的HFile，且同一个字段的不同版本(timestamp)和不同类型(Put/Delete)有可能会分布在不同的HFile中，因此查询时需要遍历所有的HFile。为了减少HFile的个数，以及清理掉过期和删除的数据，会进行StoreFile Compaction。

Compaction分为两种，分别是Minor Compaction和Major Compaction。Minor Compaction会将临近的若干个较小的HFile合并成一个较大的HFile，但不会清理过期和删除的数据。Major Compaction会将一个Store下的所有的HFile合并成一个大HFile，并且会清理掉过期和删除的数据。

StoreFile Compaction触发时机：当数据块达到 4 块，Hmaster触发合并操作，Region将数据块加载到本地，进行合并；当合并的数据超过 256M，进行拆分，将拆分后的Region分配给不同的HRegionServer管理（一个表中的Region就会被不同的HRegionServer管理，分布式存储，高可用容灾）；当 HRegionServer宕机后，将 HRegionServer上的HLog拆分，然后分配给不同的HRegionServer加载，修改.META.；

3.5 Region Split

默认情况下，每个Table起初只有一个Region，随着数据的不断写入，Region会自动进行拆分。刚拆分时，两个子Region都位于当前的Region Server，但处于负载均衡的考虑，HMaster有可能会将某个Region转移给其他的RegionServer。
在这里插入图片描述
Region Split时机：

当1个Region中的某个Store下所有StoreFile的总大小超过hbase.hregion.max.filesize，该Region就会进行拆分(0.94 版本之前)。
当1个Region中的某个Store下所有StoreFile的总大小超过Min(R^2 * "hbase.hregion.memstore.flush.size",hbase.hregion.max.filesize")，该Region就会进行拆分，其中R为当前Region Server中属于该Table的个数(0.94 版本之后)。

HBase(一)：概述