海量列式非关系数据库HBase 原理深入

HBase读数据流程：

前置关键词描述：

Block Cache ：读缓存，缓存上一次读的数据，整个ReginServer只有一个
MemStore ：写缓存，缓存上一次写的数据，每个Store有一个
WAL： 预写入日志

读取数据流程：

1.请求zk 查询meta表的地址
2.根据meta表的地址查询rowkey属于哪个reginserver的哪个regin，元数据缓存到MetaCache
3.先去BlockCache 和MemStore查找，找不到才去storeFile找，如果在storeFile 查询到，就缓存到BlockCache里

HBase写数据流程：

写数据流程：

1.请求zk 查询meta表的地址
2.根据meta表的地址查询rowkey属于哪个reginserver的哪个regin，元数据缓存到MetaCache
3.先写WAL，再写MemStore，写入MemStore就返回了，
如果MemStore内存不够，会flush storeFile文件，然后合并多个storeFile

注： Hbase的写流程比读流程效率高，因为写流程只需要写入内存，读流程先读内存，如果读不到，还需要读磁盘文件。

HBase的flush（刷写）机制：

刷写条件：

1.MemStore大小达到128M
2.时间超过1小时
3.Reginserver的所有Memstore大小达到reginserver占用的堆内存大小的40%

　注：　上述条件默认每10s检查一次

为防止检查之前达到刷写条件，会触发阻塞机制.

阻塞机制触发条件：

Memstore达到512M
Reginserver的所有Memstore大小达到堆内存的0.95*0.4

避免阻塞机制的解决方案：

如果出现这种情况，可以增大memstore大小，增大reginserver的堆内存大小。

Compact合并机制：

minor compact 小合并：　　　

文件被选中条件：

1. 待合并文件数量大于3
2.待合并文件数量小于10
3.文件大小小于128M的文件一定会加入
4.排除特别大的文件

合并触发条件：

1.menstore flush
2.定期检查，默认10s

Major compact：

合并所有的HFile，默认7天执行一次，生产中默认关闭

手动：major_compact 表名

　　注意：真正的删除是在这一步进行

Region 拆分机制：

IncreasingToUpperBoundRegionSplitPolicy：

0.94版本~2.0版本默认切分策略：

切分策略稍微有点复杂，总体看和ConstantSizeRegionSplitPolicy思路相同，一个region大小大于设

置阈值就会触发切分。但是这个阈值并不像ConstantSizeRegionSplitPolicy是一个固定的值，而是会

在一定条件下不断调整，调整规则和region所属表在当前regionserver上的region个数有关系.

region split的计算公式是：

regioncount^3 * 128M * 2，当region达到该size的时候进行split

例如：

第一次split：1^3 * 256 = 256MB

第二次split：2^3 * 256 = 2048MB

第三次split：3^3 * 256 = 6912MB

第四次split：4^3 * 256 = 16384MB > 10GB，因此取较小的值10GB

后面每次split的size都是10GB了

SteppingSplitPolicy：

　　2.0版本默认切分策略，其它版本参考百度：

这种切分策略的切分阈值又发生了变化，相比 IncreasingToUpperBoundRegionSplitPolicy 简单了

一些，依然和待分裂region所属表在当前regionserver上的region个数有关系，如果region个数等于

1，

切分阈值为flush size（128M） * 2，否则为MaxRegionFileSize（10GB）。这种切分策略对于大集群中的大表、小表会

比 IncreasingToUpperBoundRegionSplitPolicy 更加友好，小表不会再产生大量的小region，而是

适可而止。

Hbase 预分区：

　　为了负载均衡，提高读写效率，否则刚开始读写都在一个机器上进行。

　　通常解决负载均衡问题，还有以下解决方案：

给row key 加前缀
对row key 进行hash
反转

Region 合并：

　　Region的合并不是为了性能，而是出于维护的目的。

通过Merge类冷合并Region：

需要先关闭hbase集群
需求：需要把student表中的2个region数据进行合并：

　　　　student,,1593244870695.10c2df60e567e73523a633f20866b4b5.

　　　　student,1000,1593244870695.0a4c3ff30a98f79ff6c1e4cc927b3d0d.

这里通过org.apache.hadoop.hbase.util.Merge类来实现，不需要进入hbase shell，直接执行（需要先关闭hbase集群）：

hbase org.apache.hadoop.hbase.util.Merge student \

student,,1595256696737.fc3eff4765709e66a8524d3c3ab42d59. \

student,aaa,1595256696737.1d53d6c1ce0c1bed269b16b6514131d0.

通过online_merge热合并Region：

不需要关闭hbase集群，在线进行合并。

与冷合并不同的是，online_merge的传参是Region的hash值，而Region的hash值就是Region名称的最

后那段在两个.之间的字符串部分。

需求：需要把lagou_s表中的2个region数据进行合并：

student,,1587392159085.9ca8689901008946793b8d5fa5898e06. \

student,aaa,1587392159085.601d5741608cedb677634f8f7257e000.

需要进入hbase shell：

merge_region

'c8bc666507d9e45523aebaffa88ffdd6','02a9dfdf6ff42ae9f0524a3d8f4c7777'

RowKey 设计：

RowKey长度原则
- rowkey是一个二进制码流，可以是任意字符串，最大长度64kb，实际应用中一般为10-100bytes，以byte[]形式保存，一般设计成定长。
- 建议越短越好，不要超过16个字节设计过长会降低memstore内存的利用率和HFile存储数据的效率。
RowKey散列原则
- 建议将rowkey的高位作为散列字段，这样将提高数据均衡分布在每个RegionServer，以实现负载均衡的几率。
RowKey唯一原则
- 必须在设计上保证其唯一性
RowKey排序原则
- HBase的Rowkey是按照ASCII有序设计的，我们在设计Rowkey时要充分利用这点

scan使用的时候注意：setStartRow，setEndRow 限定范围，范围越小，性能越高。