1.13 HBase

1.13 HBase
1.13.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提供高容错的支持。
1.13.2 HBase的写流程

写流程：
写流程顺序正如API编写顺序，首先创建HBase的重量级连接
（1）读取本地缓存中的Meta表信息；（第一次启动客户端为空）
（2）向ZK发起读取Meta表所在位置的请求；
（3）ZK正常返回Meta表所在位置；
（4）向Meta表所在位置的RegionServer发起请求读取Meta表信息；
（5）读取到Meta表信息并将其缓存在本地；
（6）向待写入表发起写数据请求；
（7）先写WAL，再写MemStore,并向客户端返回写入数据成功。
1.13.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）合并多个位置读取到的数据,给用户返回最大版本的数据，如果最大版本数据为删除标记，则不给不返回任何数据。
1.13.4 HBase的刷写策略
（1）Mem store：flush.size 128M
（2）Region：128M * 4
（3）RegionServer：JVM堆内存 * 0.95 * 0.4 
（4）定期刷写：默认最后修改时间距离1小时
（5）手动刷写：手动执行Flush命令
1.13.5 Region的切分
（1）0.94之前：固定按10G切。
（2）0.94-2.0：动态变化min（10G，2*128M*R^3）, R一个RS中同一张表region的数量。
（3）2.0之后：第一次按照256M切，后面都按照10G切。
1.13.6 HBase的合并
Compaction分为两种，分别是Minor Compaction和Major Compaction。

1.13.7 RowKey设计原则
（1）rowkey长度原则
（2）rowkey散列原则
（3）rowkey唯一原则
1.13.8 RowKey如何设计
1）使用场景:
大量用户信息保存在HBase中。
2）热点问题：
由于用户的id是连续的，批量导入用户数据后，很有可能用户信息都集中在同一个region中。如果用户信息频繁访问，很有可能该region的节点成为热点。
3）期望： 通过对Rowkey的设计，使用户数据能够分散到多个region中。
4）步骤：
（1）预分区
通过命令
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进行反转后进行查询。
1.13.9 HBase二级索引原理
1）原理
    协处理器：协助处理数据，可以在向原始表中写入数据之后向索引表中写入一条索引数据。
2）种类及用法
    （1）全局   读多写少
    单独创建表专门用于存储索引，索引表数据量比原始表小，读取更快速。但是写操作会写两张表的数据，跨Region，需要多个连接。
    （2）本地   写多读少
将索引数据与原表放在一起（Region），加在一起比原表数据量大，读取相对变慢，但是由于在一个Region，所以写操作两条数据用的是同一个连接。