12 HBase
文章目录
- [12 HBase](#12 HBase)
-
- [12.1 HBase存储结构](#12.1 HBase存储结构)
- [12.2 HBase的写流程](#12.2 HBase的写流程)
- [12.3 HBase的读流程](#12.3 HBase的读流程)
- [12.6 HBase的合并](#12.6 HBase的合并)
- [12.7 RowKey设计原则](#12.7 RowKey设计原则)
- [12.8 RowKey如何设计](#12.8 RowKey如何设计)
- [12.9 HBase二级索引原理](#12.9 HBase二级索引原理)
12.1 HBase存储结构
架构角色：
1）Master
实现类为HMaster，负责监控集群中所有的 RegionServer 实例。主要作用如下：
（1）管理元数据表格hbase:meta，接收用户对表格创建修改删除的命令并执行
（2）监控region是否需要进行负载均衡，故障转移和region的拆分。
通过启动多个后台线程监控实现上述功能：
①LoadBalancer负载均衡器
周期性监控region分布在regionServer上面是否均衡，由参数hbase.balancer.period控制周期时间，默认5分钟。
②CatalogJanitor元数据管理器
定期检查和清理HBase：meta中的数据。meta表内容在进阶中介绍。
③MasterProcWAL Master预写日志处理器
把Master需要执行的任务记录到预写日志WAL中，如果Master宕机，让backupMaster读取日志继续干。
2）Region Server
Region Server实现类为HRegionServer，主要作用如下:
（1）负责数据cell的处理，例如写入数据put，查询数据get等
（2）拆分合并Region的实际执行者，有Master监控，有regionServer执行。
3）Zookeeper
HBase通过Zookeeper来做Master的高可用、记录RegionServer的部署信息、并且存储有meta表的位置信息。
HBase对于数据的读写操作时直接访问Zookeeper的，在2.3版本推出Master Registry模式，客户端可以直接访问Master。使用此功能，会加大对Master的压力，减轻对Zookeeper的压力。
4）HDFS
HDFS为HBase提供最终的底层数据存储服务，同时为HBase提供高容错的支持。
12.2 HBase的写流程
写流程：
写流程顺序正如API编写顺序，首先创建HBase的重量级连接
（1）读取本地缓存中的Meta表信息；（第一次启动客户端为空）
（2）向ZK发起读取Meta表所在位置的请求；
（3）ZK正常返回Meta表所在位置；
（4）向Meta表所在位置的RegionServer发起请求读取Meta表信息；
（5）读取到Meta表信息并将其缓存在本地；
（6）向待写入表发起写数据请求；
（7）先写WAL，再写MemStore,并向客户端返回写入数据成功。
12.3 HBase的读流程
创建连接同写流程。
（1）读取本地缓存中的Meta表信息；（第一次启动客户端为空）
（2）向ZK发起读取Meta表所在位置的请求；
（3）ZK正常返回Meta表所在位置；
（4）向Meta表所在位置的RegionServer发起请求读取Meta表信息；
（5）读取到Meta表信息并将其缓存在本地；
（6）MemStore、StoreFile、BlockCache
同时构建MemStore与StoreFile的扫描器，
MemStore：正常读
StoreFile：
根据索引确定待读取文件；
再根据BlockCache确定读取文件；
（7）合并多个位置读取到的数据,给用户返回最大版本的数据，如果最大版本数据为删除标记，则不给不返回任何数据。
12.6 HBase的合并
Compaction分为两种，分别是Minor Compaction和Major Compaction。
12.7 RowKey设计原则
（1）rowkey长度原则
（2）rowkey散列原则
（3）rowkey唯一原则
12.8 RowKey如何设计
1）使用场景:
大量用户信息保存在HBase中。
2）热点问题：
由于用户的id是连续的，批量导入用户数据后，很有可能用户信息都集中在同一个region中。如果用户信息频繁访问，很有可能该region的节点成为热点。
3）期望 ： 通过对Rowkey的设计，使用户数据能够分散到多个region中。
4）步骤：
（1）预分区
通过命令
bash
create 'GMALL:DIM_USER_INFO','INFO',SPLITS=>['20','40','60','80']把用户信息表(GMALL:DIM_USER_INFO) 分为5个region : 00-20), \[20-40), \[40-60), \[60-80), \[80-99
（2）写入时反转ID
把用户ID左补零10位（根据最大用户数），然后反转顺序。
比如：用户id为1457，反转处理后变为7541000000; 根据前两位分到region [60-80),
用户id为1459，反转处理后变为9541000000；根据前两位分到 region 80-99
这样连续的用户ID反转后由于Rowkey开头并不连续，会进入不同的region中。
最终达到的效果可以通过Web UI进行观察：
如上图，用户数据会分散到多个分区中。
注意：在用户查询时，也同样根据需要把ID进行反转后进行查询。
12.9 HBase二级索引原理
1）原理
协处理器：协助处理数据，可以在向原始表中写入数据之后向索引表中写入一条索引数据。
2）种类及用法
（1）全局 读多写少
单独创建表专门用于存储索引，索引表数据量比原始表小，读取更快速。但是写操作会写两张表的数据，跨Region，需要多个连接。
（2）本地 写多读少
将索引数据与原表放在一起（Region），加在一起比原表数据量大，读取相对变慢，但是由于在一个Region，所以写操作两条数据用的是同一个连接。