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系统架构

• ClientHBase的客户端，可以向Hbase服务器发送请求既可以是Shell，也可以是API操作包括DDL,DML,DQL;HBase不支持多表关联查询客户端必要的时候会对数据进行一些缓存
• HMasterHBase主节点，负责接收客户端请求（仅限于DDL）HMaster也可以实现高可用(active–standby)，主备的切换由Zookeeper负责监督维护但是HMasteri没有联邦机制，业务承载能力还是有限的一个数据库的表的结构很少会发生变化，绝大部分是CRUD操作，于是HBase的Master只负责DDL,DMLDQL由其他节点承担负责管理HRegionServer的健康状况，上下线的监督----创建表的时候分配Region
• HRegionServerHBase的具体工作节点，一般一台主机就是一个Regionserver一个RegionServer包含很多的Region,HMaster负责分配Region负责接收客户端的DML和DQL请求，建立连接
• HRegionHBase表数据具体存储位置一个Region只隶属于一张表，但是一张表可以含有多个Region最开始声明表的时候就会为这张表默认创建一个Region,随着时间推移Region越来越大，将Region一分为二
• Store一个表中一个列簇对应一个Store一个Store分为一个MemStore和N个StoreFileMemstore:基于内存存放数据，每个Store大概分配128M内存空间StoreFile:是文件的硬盘存储，直接存储到HDFS,存到HDFS后称为HFile
• HLogHBase的日志机制（WAL）日志也会存到HDFS，在任何操作之前先存储日志到HDFSMemStore丢失数据或者RegionServer异常都能够通过日志进行恢复一个RegionServer对应一个HLog
• ZookeeperHBase协调服务主备的选举与切换记录当前集群的状态信息，当主备切换的时候，集群状态可以被新主节点直接读取到记录当前集群的数据存放信息存储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读取数据流程

1. 寻址：RegionServer:node02/16020
2. 开始和RegionServer建立连接BlockCache,这是每个RegionServer内部共享的一块区域
3. 构建RegionScanner优先从MemStore读取数据如果查找失败，就去StoreFile中去查找但是要注意，StoreFile有很多个，内部有序，外部无序
4. 构建StoreScannerMemStoreScannerStoreFileScanner

HBase写入数据流程

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

数据刷写

刷写时机

• MemStore 内存阈值128M ；内存占用达512M(128M*4)，阻塞客户端写入
• RegionServer总内存的阈值总内存 * 40% * 95%，整个RegionServer开始刷写
• Wal 日志阈值大小插入数据——删除数据
• 自定义刷写时间间隔
• 命令刷写（手动刷写）

刷写策略

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

刷写流程

• PrepareFlush如果MemStore要进行刷写，对内存中的数据进行拍摄快照，拍摄时间会非常短拍摄期间内存中的数据会被锁定，保证快照期间数据的安全
• FlushCache将快照的数据写成一个临时文件到硬盘将临时文件更名称正式文件存储到对应列簇中

数据合并

合并的方式

• minor（小型）选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile仅仅是合并不会处理被删除的或者失效的数据，但是会处理超过TTL的数据一次Minor Compaction的结果是让小的storefile变的更少并且产生更大的StoreFile
• major（大型）将所有的StoreFile合并成一个StoreFile清理三类无意义数据:被删除的数据、TTL过期数据、版本号超过设定版本号的数据。但是对整个集群影响较大，—般手动合并

合并时机

• MemStoreFlushStore的StoreFile文件数进行判断,判断是否达到合并的阈值(文件数量为10个)
• 周期性检测默认定义一个合并的周期1000os如果达到阈值也会检查文件的数目如果文件数目超过3个——>小合并如果文件不超过3个——>检查最早一次合并的时间——>如果超过7天会进行大合并
• 手动触发低峰期手动触发执行完alter操作之后希望立刻生效，执行手动触发major compactionHBase管理员发现硬盘容量不够的情况下手动触发major compaction删除大量过期数据

合并策略

• 选择线程2 * maxFlilesToCompact * hbase.hregion.memstore.flush.size 2.5G超过LongCompact小于ShortCompact
• Minor合并RatioBasedCompactionPolicy比较大一点的文件不会参与到合并ExploringCompactionPolicy

数据切分

切分方式

最开始一个表只有一个Region

对于这个表的查询都会被定位到这—个RegionServer

当Region达到阈值的时候就会进行切分

单点压力读写性能合并困难

切分时机

每次数据合并之后，发起一个requestSplit，然后开始检查文件的大小是否达到阈值

• ConstantSizeRegionSplitPolicy10G
• lncreasingToUpperBoundRegionSplitPolicy256M2048M —。。。。 —10G

切分策略

• 寻找切分点先找最大的Store,然后再找最大的StoreFile,再找到中心位置的RowKey
• 切分流程