HBase基本知识介绍及典型案例分析

一、HBase是什么？

分布式、多版本、面向列的开源KV数据库；

支持PB、百万列的数据存储；

强一致性、高扩展、高可用。

HBase表核心概念

RowKey：表中每条记录的主键
Column Family：列族，将表进行横向切割，简称CF；
Column：属于某一个列族，可动态添加列；
Version Number：类型为Long，默认值是系统时间戳，用户也可以自定义；
Value：真实数据。

在这里插入图片描述

一行（Row）数据是可以包含一个或多个 Column Family，但是我们并不推荐一张 HBase 表的 Column Family 超过三个。Column 是属于 Column Family 的，一个 Column Family 包含一个或多个 Column。

HBase表核心概念

Region：一段数据的集合；
RegionServer：用于存放Region的服务。

在物理层面上，所有的数据其实是存放在 Region 里面的，而 Region 又由 RegionServer 管理，其对于的关系如下：
在这里插入图片描述

一个 RegionServer 管理多个 Region；而一个 Region 管理一个或多个 Column Family。

HBase数据模型：逻辑视图

在这里插入图片描述

这张表有两个 Column Family ，分别为 personal 和 office。而 personal 又有三列name、city 以及 phone；office 有两列 tel 以及 address。由于存储在 HBase 里面的表一般有上亿行，所以 HBase 表会对整个数据按照 RowKey 进行字典排序，然后再对这张表进行横向切割。切割出来的数据是存储在 Region 里面，而不同的 Column Family 虽然属于一行，但是其在底层存储是放在不同的 Region 里。所以这张表我用了六种颜色表示，也就是说，这张表的数据会被放在六个 Region 里面的，这就可以把数据尽可能的分散到整个集群。

HBase数据模型：物理视图

一行 HBase 的数据其实是分了好几行存储，一个列对应一行，HBase 的 KV 结构如下：

在这里插入图片描述
RowKey 为 Row1 的数据第一列表示为上图最后一行的形式。以此类推，整个表的存储就可以如下表示：

可以从上面的 kv 表现形式看出，Row11 的 phone 这列其实是没有数据的，在 HBase 的底层存储里面也就没有存储这列了，这点和我们传统的关系型数据库有很大的区别，有了这个特点， HBase 特别适合存储稀疏表。

HBase支持数据多版本特性，通过带有不同的时间戳的多个KeyValue版本来实现；
每次put、delete都会产生一个新的cell，都拥有一个版本；
默认只存数据的三个版本，可以配置；
查询默认返回最新版本的数据，可以通过制定版本号或版本数获取旧数据。

HBase架构

在这里插入图片描述

HBase写数据

在这里插入图片描述

先将数据写到WAL中；
WAL存放在HDFS上；
每次put、Delete操作的数据均追加到WAL末端；
持久化到WAL之后，再写到MemStore中；
两者写完返回ACK到客户端。

HBase MemStore

MemStore 其实是一种内存结构，一个Column Family 对应一个MemStore，MemStore 里面的数据也是对 Rowkey 进行字典排序的，如下：
在这里插入图片描述

HBase Region Flush

既然我们写数都是先写 WAL，再写 MemStore ，而 MemStore 是内存结构，所以 MemStore 总会写满的，将 MemStore 的数据从内存刷写到磁盘的操作成为 flush：
在这里插入图片描述
以下几种行为会导致 flush 操作

全局内存控制；
MemStore使用达到上限；
RegionServer的Hlog数量达到上限；
手动触发；
关闭RegionServer触发。

每次 flush 操作都是将一个 MemStore 的数据写到一个 HFile 里面的，所以上图中 HDFS 上有许多个 HFile 文件。文件多了会对后面的读操作有影响，所以 HBase 会隔一定的时间将 HFile 进行合并。根据合并的范围不同分为 Minor Compaction 和 Major Compaction：

HBase Compaction

在这里插入图片描述

Minor Compaction: 指选取一些小的、相邻的HFile将他们合并成一个更大的Hfile。

Major Compaction：

将一个column family下所有的 Hfiles 合并成更大的；
删除那些被标记为删除的数据、超过TTL（time-to-live）时限的数据，以及超过了版本数量限制的数据。

HBase 读操作相对于写操作更为复杂，其需要读取 BlockCache、MemStore 以及 HFile。

HBase Spilt

在这里插入图片描述

HBase读数据

在这里插入图片描述

HBase Region查找

在这里插入图片描述

客户端按照上面的流程查找需要读写的 RegionServer 。这个过程一般是第一次读写的时候进行的，在第一次读取到元数据之后客户端一般会把这些信息缓存到自己内存中，后面操作直接从内存拿就行。当然，后面元数据信息可能还会变动，这时候客户端会再次按照上面流程获取元数据。

二、RowKey设计

RowKey的作用

HBase 中的 Rowkey 主要有以下的作用：

读写数据时通过Row Key找到对应的Region
MeMStore中的数据按RowKey字典顺序排序
HFile中的数据按RowKey字典顺序排序

在这里插入图片描述
底层的 HFile 最终是按照 Rowkey 进行切分的，所以我们的设计原则是结合业务的特点，并考虑高频查询，尽可能的将数据打散到整个集群。

RowKey的设计原则

综合业务的特点，考虑高频查询，尽可能的将数据打散到整个集群。
在这里插入图片描述

RowKey的设计——Salting

Salting的原理是将固定长度的随机数放在行键的起始处。

在这里插入图片描述

优缺点：由于前缀是随机生成的，如果想要按照字典序找到这些行，则需要更多的工作。从这个角度来看，salting增加了写操作的吞吐量，也增大了读操作的开销。

RowKey的设计——Hashing

Hashing的原理将RowKey进行hash计算，然后取hash得部分字符串和原来的RowKey进行拼接。

在这里插入图片描述

优缺点：可以一定程度的打算整个数据集，但是不利于Scan；由于不同数据的hash值可能一样，实际应用可以使用md5计算，然后截取前几位的字符串，如：

subString(MD5(设备ID),0,x) + 设备ID，其中x一般取5或6

RowKey的设计——Reversing

Reversing的原理是反转一段固定长度或全部的键。

在这里插入图片描述

优缺点：有效地打乱了行键，但是牺牲了行排序的属性。

三、HBase多模式

多种数据格式

在这里插入图片描述

HBase多模式

在这里插入图片描述
HBase 的生态主要有：

Phoenix：主要提供使用 SQL 的方式来查询 HBase 里面的数据。一般能够在毫秒级别返回，比较适合 OLTP 场景。
Spark：我们可以使用 Spark 进行 OLAP 分析；也可以使用 Spark SQL 来满足比较复杂的 SQL 查询场景；使用 Spark Streaming 来进行实时流分析。
Solr：原生的 HBase 只提供了 Rowkey 单主键，如果我们需要对 Rowkey 之外的列进行查找，这时候就会有问题。幸好我们可以使用 Solr 来建立二级索引/全文索引充分满足我们的查询需求。
HGraphDB：HGraphDB是分布式图数据库。依托图关联技术，帮助金融机构有效识别隐藏在网络中的黑色信息，在团伙欺诈、黑中介识别等。
GeoMesa：目前基于NoSQL数据库的时空数据引擎中功能最丰富、社区贡献人数最多的开源系统。
OpenTSDB：基于HBase的分布式的，可伸缩的时间序列数据库。适合做监控系统；譬如收集大规模集群（包括网络设备、操作系统、应用程序）的监控数据并进行存储，查询。