HBase应用场景、原理与基本架构

喜欢ヅ旅行 2021-09-14 02:32 663阅读 0赞

# 一、为什么使用HBase？ #

传统的RDBMS关系型数据库（例如SQL）存储一定量数据时进行数据检索没有问题，可当数据量上升到非常巨大规模的数据（TB或PB）级别时，传统的RDBMS已无法支撑，这时候就需要一种新型的数据库系统更好更快的处理这些数据。我们可以选择HBase。

# 二、HBase概述 #

HBase（Hadoop Database）是一个开源的、面向列（Column-Oriented）、适合存储海量非结构化数据或半结构化数据的、具备高可靠性、高性能、可灵活扩展伸缩的、支持实时数据读写的分布式存储系统。

它是Apache Hadoop生态系统中的重要一员，主要用于海量结构化数据存储。从逻辑上讲，HBase将数据按照表、行和列进行存储。

> > > > > ![Center][]

## 2.1 HBase与HDFS比较  ##

HBase与HDFS两者都具有良好的容错性和扩展性，都可以扩展到成百上千个节点。但是，HDFS适合批处理的场景，它不支持数据随机查找，不支持增量数据处理，不支持数据更新。

> > > ![Center 1][]

## 2.2 HBase表的特点 ##

1）大：一个表可以有数十亿行，上百万列；

2）无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；

3）面向列：面向列（族）的存储和权限控制，列（族）独立检索；

4）稀疏：对于空（null）的列，并不占用存储空间，表可以设计的非常稀疏；

5）数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；

6）数据类型单一：HBase中的数据都是字符串，没有类型。

## 2.3 行存储与列存储的比较 ##

行存储：数据是按行存储的的；没有索引的查询使用大量I/O；建立索引和物化视图需要花费大量的时间和资源；面向查询的需求，数据库必须被大量膨胀才能满足性能要求。

列存储：数据是按每一列单独存放；数据即是索引；大量降低系统I/O；每一列由一个线索来处理（查询的并发处理）；数据类型一致，数据特征相似（高效压缩）。

![Center 2][]

# 三、HBase数据模型 #

HBase是基于Google BigTable模型开发的，典型的key/value系统。

> > > > ![Center 3][]

## 3.1 HBase的基本概念 ##

> > > ![Center 4][]

Row Key（行键）：表中每条记录的“主键”，方便快速查找；

Column Family（列族）：拥有一个名称，包含一个或多个相关列；

Column：属于某一个Column Family，包含在某一个列中；

Version Number（版本）：HBase能够为一个单元格元组（行、列族和列）保存多个值，每个单元格被称为一个记录的版本。默认值为系统的时间戳，类型为Long。默认情况下，HBase保留3个版本的记录。当然，我们也可以改变保留版本的数量，我们也可以通过制定来获取某个特定的版本。

时间戳：对于每个插入的数据，当前的时间戳与值是相关的，它表示了数值插入到表中的时间。

单元格：最小或基本的存储单位，在内部是一个列的实际值存储。所以插单元格数据时必须包含RowKey + ColumnFamily（列族名）+ ColumnName（列名）+ timeStamp：value。

HBase schema可以有多个Table，每一个表可以有多个Column Family组成，HBase可以有Dynamic Column（列名称是编码在cell中的，不同cell可以有不同的列），version number可由用户提供，无需以递增的顺序插入，每一行的Row Key必须是唯一的，Table可能是非常稀松的，很多的cell可以是空的。

## 3.2 HBase支持的操作 ##

1）所有的操作均是基于Row Key的；

2）支持CRUD（Create、Read、Update、Delete）和Scan；

3）单行操作：Put、Get、Scan；

4）多行操作：Scan、MultiPut；

5）没有内置的join操作，可以使用MapReduce解决。

# 四、HBase物理模型 #

每一个Column Family存储在HDFS上的一个单独文件中；Key和Version Number在每个Column Family中均有一份，空值不会保存。

> > > ![Center 5][]

## 4.1 物理存储 ##

1）Table中的所有行都按照Row Key的字典序排列；

2）Table在行的方向上分割为多个Region；

> > > > ![Center 6][]

3）Region按大小分割的，每个表开始只有一个Region，随着数据增多，Region不断增大，当增大到一个阀值的时候，Region就会等分为两个新的Region，之后就会有越来越多的Region；

> > > > > ![Center 7][]

4）Region是HBase中分布式存储和负载均衡的最小单元。不同的Region分布到不同的RegionServer上；

> > > > ![Center 8][]

5）Region虽然是分布式存储的最小单元，但并不是存储的最小单元。Region由一个或多个Store组成，每个store保存一个Column Family，每一个Store又有一个memStore和0至多个StoreFile组成，memStore存储在内存中，StoreFile存储在HDFS上。

> > > > ![Center 9][]

# 五、HBase架构 #

> > > > ![Center 10][]

## 5.1 HBase基本组件 ##

1）Client

包含访问HBase的接口，并维护cache来加快对HBase的访问。

2）Zookeeper

保证任何时候，集群中只有一个master；存储所有Region的寻址入口；实时监控Region Server的上线和下线信息，并实时的通知给Master；存储HBase的schema和table的元数据。

3）Master

为Region Server分配Region；负责Region Server的负载均衡；发现失效的Region Server并重新分配其上的Region；管理用户对table的增删改查操作。

4）Region Server

Region Server维护Region，处理对这些Region的IO请求；Region Server负责切分在运行过程中变得过大的Region。

> > > ![Center 11][]

> > > ![Center 12][]

## 5.2 Zookeeper作用 ##

HBase依赖zookeeper，默认情况下，HBase管理zookeeper实例；Master与RegionServer启动时会向zookeeper注册；zookeeper的引入是的Master不再是单点故障。

## 5.3 Write-Ahead-Log ##

> > ![Center 13][]

## 5.4 HBase容错性 ##

1）Master容错：zookeeper重新选择一个新的Master

无Master过程中，数据读取仍照常进行，Region切分、负载均衡等无法进行。

2）RegionServer容错：定时向zookeeper汇报心跳，如果一旦一定时间内未出现心跳

Master将该RegionServer上的Region重新分配到其他RegionServer上；失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer。

3）zookeeper容错：zookeeper是一个可靠的服务

一般配置3或5个zookeeper实例。

## 5.5关系数据库与HBase比较 ##

> > > ![Center 14][]

## 5.6 HBase与Hadoop比较 ##

> > > > ![Center 15][]

[Center]: /images/20210726/f30df71188904a6db601ceeae59231e7.png
[Center 1]: /images/20210726/b25153516009414e889339dc79e4f281.png
[Center 2]: /images/20210726/7b722bd461654348ba83026c55ddef1d.png
[Center 3]: /images/20210726/7edb91ab24194c1aa3790dfb4c860ac4.png
[Center 4]: /images/20210726/87a5b10439a64526b9f0d51ca2060cb1.png
[Center 5]: /images/20210726/e8afe4d79a964087a98e8246ca5264a9.png
[Center 6]: /images/20210726/6d13d0bd10d44807a5284b2b5dc7f417.png
[Center 7]: /images/20210726/cf6f9c684a2b405285cb2f2931c62cae.png
[Center 8]: /images/20210726/d6b02f03dc6b4b1ea7294e29f2c58618.png
[Center 9]: /images/20210726/88165edcbccc4a50b661b75a6e8fbaf7.png
[Center 10]: /images/20210726/51b6b8d61ed84296a7cfc3bfafc095ef.png
[Center 11]: /images/20210726/5d3ace02cccb40a0a4a736038eba283c.png
[Center 12]: /images/20210726/f5b03a478d37439d9ecbe56bda6f9b09.png
[Center 13]: /images/20210726/b5fb57d7c0d6428a8e28b381857a8a87.png
[Center 14]: /images/20210726/d47721a2691e40b794d72dd7816d28d3.png
[Center 15]: /images/20210726/02fdff168a8041af9aa3df5c2783971a.png