大数据Hadoop生态圈组件之HBase

Posted 2022-01-11 Mr_yeson

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了大数据Hadoop生态圈组件之HBase相关的知识，希望对你有一定的参考价值。

HBase——一个以列式存储的NoSql非关系型数据库

介绍

简介

Hadoop Database,是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式数据库；

Hadoop HDFS作为其文件存储系统，zookeeper作为其分布式协同服务主要用来存储非结构化和半结构化的松散数据

优点

容量大
面向列
多版本
稀疏性
拓展性
高可靠性
高性能

底层的LSM数据结构和RowKey有序排列等架构上的独特设计，使得Hbase写入性能非常高。

总结：数据量大，响应速度快

HBase数据结构

NameSpace

命名空间（相当于数据库）：为了保护表，创建的一个更高层级的单位；作为表的逻辑分组
Table

表（即为表）：存储相同数据的一个逻辑单元

表有多个行数据组成，行有很多列组成

Hbase是一个半结构的数据库，所以每一行的列都有可能不同
RowKey

主键（一行数据的主键）： Hbase按照列进行存储，所以我们查询数据的时候会看到很多RowKey相同的列RowKey可以看作为主键: 最多可以有64K字节组成，一般能10-40个字节即可
将来设计RowKey是HBase使用的重中之重

Rowkey存储的时候默认以字典序排序
Column Family

列簇（多个列的集合）：方便队列进行查找和管理

一个表的列簇需要在使用之前申明（创建表，后期维护表）

列隶属于列簇，列簇隶属于表

一个表中的列簇是固定的，但列簇中的列是不固定的
Column Qualifier

列：有可能有的数据行一个列簇中有3个列，有的数据行相同列簇有8个列

使用的时候必须是列簇：列
TimeStamp

数据版本：默认是时间戳，解决HDFS不能随时修改数据的弊端

默认数据版本就是时间戳

查询数据时默认显示最新数据
Cell

数据：row,column family,column qualifier,version
所有的数据都是字符串

HBase系统架构

Client

HBase的客户端，可以向Hbase服务器发送请求

既可以是Shell，也可以是API

操作包括DDL,DML,DQL;HBase不支持多表关联查询

客户端必要的时候会对数据进行一些缓存
HMaster

HBase主节点，负责接收客户端请求（仅限于DDL）

HMaster也可以实现高可用(active–standby)，主备的切换由Zookeeper负责监督维护

但是HMasteri没有联邦机制，业务承载能力还是有限的

一个数据库的表的结构很少会发生变化，绝大部分是CRUD操作，于是HBase的Master只负责DDL,DMLDQL由其他节点承担

负责管理HRegionServer的健康状况，上下线的监督----创建表的时候分配Region
HRegionServer

HBase的具体工作节点，一般一台主机就是一个Regionserver

一个RegionServer包含很多的Region,HMaster负责分配Region

负责接收客户端的DML和DQL请求，建立连接
HRegion

HBase表数据具体存储位置

一个Region只隶属于一张表，但是一张表可以含有多个Region

最开始声明表的时候就会为这张表默认创建一个Region,随着时间推移Region越来越大，将Region一分为二
Store

一个表中一个列簇对应一个Store

一个Store分为一个MemStore和N个StoreFile

Memstore:基于内存存放数据，每个Store大概分配128M内存空间

StoreFile:是文件的硬盘存储，直接存储到HDFS,存到HDFS后称为HFile
HLog

HBase的日志机制（WAL）

日志也会存到HDFS，在任何操作之前先存储日志到HDFS

MemStore丢失数据或者RegionServer异常都能够通过日志进行恢复

一个RegionServer对应一个HLog
Zookeeper

HBase协调服务

主备的选举与切换

记录当前集群的状态信息，当主备切换的时候，集群状态可以被新主节点直接读取到

记录当前集群的数据存放信息

存储HBase的元数据信息

HBase读写流程

HBase读写公共流程

1.HBase读取数据/写入数据

2.公共流程：

HBase0.96之前：首先系统维护了两张表 -ROOT- .meta.

.meta. 表中存储了表对应Region 对应的RegionServer RowKey的区间，但是 .meta.表也是一张普通的HBade表，也需要存放到RegionServer,

于是专门用-ROOT-表来记录 .meta.的存放位置，认为ROOT表只需要一个Region即可，-ROOT-的Region信息就被记录到zookeeper
HBase0.96之后：系统只维护.meta. ， Meta的位置信息由Zookeeper守护

HBase读取数据流程

寻址：RegionServer:node02/16020
开始和RegionServer建立连接

BlockCache,这是每个RegionServer内部共享的一块区域
构建RegionScanner

优先从MemStore读取数据

如果查找失败，就去StoreFile中去查找

但是要注意，StoreFile有很多个，内部有序，外部无序
构建StoreScanner

MemStoreScanner

StoreFileScanner

HBase写入数据流程

寻址：发现RowKey对应的RegionServer : node03/16020
RegionServer:首先将操作写入到日志
日志HLog:日志会存放到HDFS
将数据写入到MemStore (new)
监听器监听MemStore状态，判断阈值（128M）
数据刷写 MemStore(old)
StoreFile
数据合并
数据切分

数据刷写

刷写时机

MemStore 内存阈值128M ；内存占用达512M(128M*4)，阻塞客户端写入
RegionServer总内存的阈值

总内存 * 40% * 95%，整个RegionServer开始刷写
Wal 日志阈值大小

插入数据——删除数据
自定义刷写时间间隔
命令刷写（手动刷写）

刷写策略

HBase1.1之前

MemStore刷写是Region级别的，列簇不要超过三个
HBase2.2之后
1. Region中所有的MemStore都进行刷写
2. 设置一个阈值
3. MemStore分两类

刷写流程

PrepareFlush

如果MemStore要进行刷写，对内存中的数据进行拍摄快照，拍摄时间会非常短

拍摄期间内存中的数据会被锁定，保证快照期间数据的安全
FlushCache

将快照的数据写成一个临时文件到硬盘

将临时文件更名称正式文件存储到对应列簇中

数据合并

合并的方式

minor（小型）

选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile

仅仅是合并不会处理被删除的或者失效的数据，但是会处理超过TTL的数据

一次Minor Compaction的结果是让小的storefile变的更少并且产生更大的StoreFile
major（大型）

将所有的StoreFile合并成一个StoreFile

清理三类无意义数据:被删除的数据、TTL过期数据、版本号超过设定版本号的数据。

但是对整个集群影响较大，—般手动合并

合并时机

MemStoreFlush

Store的StoreFile文件数进行判断,判断是否达到合并的阈值(文件数量为10个)
周期性检测

默认定义一个合并的周期1000os如果达到阈值也会检查文件的数目

如果文件数目超过3个——>小合并

如果文件不超过3个——>检查最早一次合并的时间——>如果超过7天会进行大合并
手动触发

低峰期手动触发

执行完alter操作之后希望立刻生效，执行手动触发major compaction

HBase管理员发现硬盘容量不够的情况下手动触发major compaction删除大量过期数据

合并策略

选择线程

2 * maxFlilesToCompact * hbase.hregion.memstore.flush.size 2.5G

超过LongCompact

小于ShortCompact
Minor合并

RatioBasedCompactionPolicy

比较大一点的文件不会参与到合并

ExploringCompactionPolicy