大数据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之后
- Region中所有的MemStore都进行刷写
- 设置一个阈值
- 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
数据切分
切分方式
最开始一个表只有一个Region
对于这个表的查询都会被定位到这—个RegionServer
当Region达到阈值的时候就会进行切分
单点压力读写性能合并困难
切分时机
每次数据合并之后，发起一个requestSplit，然后开始检查文件的大小是否达到阈值
-
ConstantSizeRegionSplitPolicy
10G
-
lncreasingToUpperBoundRegionSplitPolicy
256M
2048M —。。。。 —10G
切分策略
-
寻找切分点
先找最大的Store,然后再找最大的StoreFile,再找到中心位置的RowKey
-
切分流程