HBase架构与设计

四、HBase架构图1.Client2.Zookeeper3.HMaster4.HRegionServer5.HRegion6.Store7.StoreFile8.HLog

五、元数据存储1.元数据表2.数据结构

六、写流程1.获取Meta元数据2.获取RegionServer3.发送写入请求

七、读流程1.获取Meta元数据2.获取RegionServer3.发送读请求

刷盘2.1

HBase是一个基于java的NoSQL分布式列存储数据库主要用于存储非结构化和半结构化的松散数据。

将Hadoop中的HDFS作为底层文件存储系统来提供容错和可靠性以及存储系统的拓展性。

HBase的设计思想来自Google的Bigtable论文是分布式数据库的实现。

HDFS是一个高可靠、高延迟的分布式文件系统但是不支持对数据的随机访问和更新因此不适合实时计算系统。

HBase是一个可以提供实时计算的大数据分布式数据库支持对数据的随机访问和更新。

二、HBase概述

HBase的底层存储引擎是基于LSM-Tree数据结构设计的存储是基于HDFS。

而针对数据的更新和删除不是修改原有记录而是新增一条记录这样可以充分发挥顺序写的性能但是查询的时候就需要查询磁盘中的文件和内存中的操作读取所有数据版本。

因此HBase写性能比读性能提高了两个数量级。

1.设计特点

强一致性读写HBase时强一致性读写适合高速计数聚合之类的任务。

自动分片HBase表会按照水平方向拆分成Region分布在集群上Region会随着数据增长自动拆分和重新均衡。

故障转移RegionServer如果发生故障会自动恢复集成HDFSHBase内部集成HDFS作为其持久化存储组件支持MapReduceHBase支持MapReduce进行大规模并行处理支持写入和读取。

查询优化HBase通过块缓存和布隆过滤器来优化大容量查询

2.适用场景

传递RDRMS当数据量增大时需要读写分离策略来解决服务器压力。

如果数据量继续增加就需要分库分表这就限制了一些关联查询并引入中间层。

每次变动都需要很多准备工作和业务代码修改验证。

而且即使分库分表也无法解决一些数据倾斜和热点问题。

HBase支持自动水平拓展内部集成HDFS解决数据可靠性还支持利用MapReduce进行海量数据分析。

2.2

HBase作为列式存储适合稀疏数据针对为null的列不会进行存储这样可以节约存储空间并提高读性能。

2.3

HBase的更新和删除操作不会修改原有记录而是通过新增记录实现。

通过RowKey和ColumnKey定位到多个TimeStamp相关的Value值因此可以存储变动历史记录。

可以通过设置版本数量来确定HBase保留几次变动记录。

2.4

HBase无固定模式不需要停机进行维护支持半结构和非结构化的数据。

三、数据模型

作为一个面向列的分布式数据库存储的数据是稀疏、多维、有序的。

HBase表中的一条数据是由全局唯一的键RowKey和任意数量的列Column一列或者多列组成一个列族Column

其中列族名和数量需要在建表确定但一个列族下面可以增加任意个列限定名。

一个列限定名代表了实际中的一列HBase将同一个列族下面的所有列存储在一起所以HBase是一种面向列族式的数据库。

1.表逻辑结构

以下是一个HBase表的实例。

其中有一个唯一主键包含PersonalInfo列族、其中包括三个列name、age、phone包含OfficeInfo列族、其中包括列tel和city。

并且根据时间戳TimeStamp会存储多版本数据。

2.RowKey

RowKey与关系型数据库中的主键类似用来唯一标识某行数据。

整个表是按照RowKey进行排序。

HBase按照RowKey划分为多个Region存储在不同的Region

3.Column

Family是列族一个列族可以包含多列。

同一个列族中列数据都存储在Region的一个Store中。

4.TimeStamp

HBase表根据主键水平拆分成多个region每个region根据列族拆分为Store每个Store包含一个内存MemStore和零个或者多个StoreFileStoreFile以HFile文件形式存储在HDFS上。

四、HBase架构图

HBase采用Master/Slave架构搭建集群属于Hadoop生态系统的一部分。

由HMaster节点、HRegionServer节点、Zookeeper集群组成而数据会存储在HDFS中。

整体架构如下图

1.Client

用户访问HBase的客户端主要是包含HBase的接口会缓存元数据来加快对HBase的访问。

2.Zookeeper

Zookeeper主要协调和管理HMaster和HRegionServer。

HMaster和HRegionServer启动时会向Zookeeper进行注册。

作用如下

保证任何时候集群中只有一个HMaster。

存储所有HRegion的寻址入口。

实时监控HRegionServer的上线和下线信息并通知给HMaster存储HBase的Schema和Table元数据

3.HMaster

负责管理RegionServer并实现负载均衡管理和分配Region管理namespace和table元数据。

4.HRegionServer

用来维护HMaster分配的region处理这些region的读写请求并且负责将运行过程中过的region进行切分。

5.HRegion

Region是HBase中分布式存储和负责均衡的最小单位。

HBase表按照行方向被拆分为多个Region。

不同的Region可以分布在不同的HRegionServer上同一个Region只能在同一个HRegionServer上。

当Region的某个列族达到一定阀值会被拆分成两个新的Region。

6.Store

每个Region按照ColumnFamily拆分成Store一个Region由一个或者多个Store组成。

每个ColumnFamliy会建一个Store一个Store由一个memStore和多个StoreFile组成。

7.StoreFile

memStore中的数据写到文件之后就是StoreFile。

StoreFIle底层就是HFile的格式保存在存储系统中。

8.HLog

HBase中有一个系统表hbase:meta来存储HBase元数据。

该表保存了所有的Region信息hbase:meta也是一个HBase表被HRegionServer管理hbase:meta表的位置信息保存在Zookeeper中。

2.数据结构

元数据表有一个RowKey和一个ColumnFamily组成其中RowKey包括表名、起始Key、region编号。

只包含一个info列族包含三列

info:regioninforegionId,tableName,startKey,endKey,offline,split,replicaIdinfo:serverHRegionServer对应的server:portinfo:serverstartcodeHRegionServer的启动时间戳。

六、写流程

HBase的写入过程由于相当于添加新记录因此写数据比读数据快整体流程如下

1.获取Meta元数据

首先需要知道表的元数据也就是要知道表的region列表这个信息时维护在meta表中。

1.1

client访问zookeeper获取Meta表所在的RegionServer信息

1.2

从zookeeper节点返回meta的RegionServer1信息

2.获取RegionServer

从Meta表中查询表的Region信息以及负责Region维护的RegionServer信息。

2.3

根据表名和RowKey向meta所在的RegionServer1发送查询请求

2.4

RegionServer1找到对应的meta的记录返回对应Region信息其中包括RegionServer2信息。

Client会缓存此Region信息。

3.发送写入请求

RegionServer2将数据先写入到HLog为了数据的持久化和恢复

3.7

HBase读取数据需要返回所有版本数据所以可能需要查询所有HFile文件读性能比写慢了两个数量级。

读取流程获取Meta元数据和RegionServer的过程和写过程一致。

1.获取Meta元数据

如果StoreFile查到到数据需要将数据写入到BlockCache再返回给Client。

八、持久化

上边的写请求过程可知数据会先写入到HLog然后再写入到内存MemStore。

HLog保存的是RegionServer上所有的日志操作是记录操作的一种日志。

当MemStore数据还没有持久化时可以通过HLog进行故障恢复保证数据正确性和持久化。

MemStore是在内存中维持列族数据按照RowKey顺序排列然后顺序写入到磁盘中。

主要是为了将来检索优化将数据写入到HDFS之前在内存中将数据完成排序。

2.MemStore

MemStore维持当前在内存中的同一个列族数据按照RowKey有序当MemStore达到一定时机时会将MemStore中数据以HFile形式持久化到文件系统中。

Flush触发条件如下

2.1

当Region中任意一个MemStore的大小达到了上限hbase.hregion.memstore.flush.size默认128MB会触发Memstore刷新

propertynamehbase.hregion.memstore.flush.size/namevalue134217728/value

/property2.2

当Region中所有Memstore的大小总和达到了上限hbase.hregion.memstore.block.multiplier

hbase.hregion.memstore.flush.size默认

128M

propertynamehbase.hregion.memstore.flush.size/namevalue134217728/value

/property

propertynamehbase.hregion.memstore.block.multiplier/namevalue4/value

/property

Server中所有Memstore的大小总和超过低水位阈值hbase.regionserver.global.memstore.size.lower.limit*hbase.regionserver.global.memstore.size前者默认值0.95RegionServer开始强制flush

propertynamehbase.regionserver.global.memstore.size.lower.limit/namevalue0.95/value

/property

propertynamehbase.regionserver.global.memstore.size/namevalue0.4/value

/property先Flush

Memstore最大的Region再执行次大的依次执行如写入速度大于flush写出的速度导致总MemStore大小超过高水位阈值此时RegionServer会阻塞更新并强制执行flush直到总MemStore大小低于低水位阈值

2.4

Server中HLog数量达到上限可通过参数hbase.regionserver.maxlogs配置时系统会选取最早的一个

2.5

默认周期为1小时确保Memstore不会长时间没有持久化。

为避免所有的MemStore在同一时间都进行flush导致的问题定期的flush操作有20000左右的随机延时。

2.6

memstore每次刷新都会生成一个新的HFile文件由于触发机制导致可能生成的大部分新HFile文件都是小文件。

这样会导致查询过程中需要遍历非常多的小文件导致维护困难、影响查询性能和效率。

为了查询优化和清理过期数据所以会对HFile进行合并。

Compaction分为两类Minor

Compaction和Major

合并原理是指从一个Store中的部分HFile文件整合成一个新的HFile文件其中会从待合并数据从文件读出然后按照由小到达排序后写入新文件。

3.2

选取部分小的相邻的HFile将他们合并成一个更大的HFile。

3.3

将一个Store中所有的HFile合并成一个HFile。

同时会清理掉过期、删除、多版本数据。

HBase是基于分布式文件系统HDFS构建的一个大数据、NoSQL、可拓展分布式数据库。

采用Master/Slave架构、用Zookeeper进行元数据保存和协调工作。

采用LSM-TREE作为存储引擎由于HDFS不支持修改和更新所以HBase中将修改和更新作为新记录存储到HDFS中。

HBase用牺牲读性能来提升大数据写入能力。

参考链接