flush溢写流程: hbase 2.0版本后的流程
随着客户端不断写入数据到达memStore中, memStore内存就会被写满(128M), 当memStore内存达到一定的阈值后, 此时就会触发flush刷新线程, 将数据最终写入HDFS上, 形成一个StoreFile文件
1) 当memStore的内存写满后, 首先将这个内存空间关闭, 然后开启一个新的memStore, 将这个写满内存空间的数据存储到一个pipeline的管道(队列)中 (只能读, 不能改)
2) 在Hbase的2.0版本后, 这个管道中数据, 会尽可能晚刷新到磁盘中, 一直存储在内存中, 随着memStore不断的溢写, 管道中数据也会不断的变多
3) 当管道中数据, 达到一定的阈值后, hbase就会启动一个flush的刷新线程, 对pipeline管道中数据一次性全部刷新到磁盘上,而且在刷新的过程中, 对管道中数据进行排序合并压缩操作, 在HDFS上形成一个合并后的storeFile文件

1.0版本中:
区别在于 : 不存在尽可能晚的刷新 , 也不存在合并溢写操作
注意: 虽然说在2.0时代加入这个内存合并方案, 但是默认情况下是不开启的

2.0中内存合并的策略:

basic(基础型):
说明: 仅做作为基本的合并, 不会对过期数据进行清除操作
优点: 效率高 ,适合于这种有大量写的模式
弊端: 如果数据中大多数都是已经过期的时候, 此时做了许多无用功, 对磁盘IO也会比较大
eager(饥渴型):
说明: 在合并的过程中, 尽可能的去除过期的无用的数据, 保证合并后数据在当下都是可用的
优点: 合并后的文件会较少, 对磁盘IO比较低, 适用于数据过期比较快的场景(比如购物车数据)
弊端: 由于合并需要多干活,会资源使用也会更多, 导致合并效率降低, 虽然IO减少, 但是依然效率是比较低下的
adaptive(适应型):
说明: 在合并的过程中, 会根据数据的重复情况来决定是否需要采用哪种方案, 当重复数据过多, 就会采用eager型, 否则使用basic(基础型)
优点: 更智能化, 自动切换
弊端: 如果重复数据比较多但是写入也比较频繁, 此时采用eager, 会导致资源被eager占用较大, 从而影响写入的效率

如何配置内存合并策略:

方案一: 全局配置, 所有表都生效

方案二: 针对某个表来设置

二、HBase的storeFile的合并机制

触发时机:

minor: 触发时机 storeFile文件达到3及以上的时候 | 刚刚启动Hbase集群的时候
major: 默认触发时间: 7天 | 刚刚启动Hbase集群的时候

hbase矛盾点: HBase支持随机读写功能, HBase基于HDFS, 而HDFS不支持随机读写, 如何解决呢?

1) 在Hbase中, 所有的数据随机操作,都是对内存中数据进行处理, 如果是添加, 在内存中加入数据, 如果修改, 同样也是添加操作(时间戳记录版本), 如果删除,本应该是直接到磁盘中将数据删除, 但是HDFS不支持, 在内存中记录好这个标记,不显示给用户看即可
2) 在进行storeFile的major合并操作的时候, 此时将HDFS的数据读取出来到内存中, 边读取边处理, 边将数据追加到HDFS中

三、Hbase的split机制(region分裂)

split在最终达到10GB时候, 就会执行split分裂, 分裂之后, 就会形成两个新的Region, 原有Region就会被下线, 新的region会分别各种切分后Hfile文件
注意: split的最终10Gb 指的是当Hbase中Region数量达到9个及以上的时候, 采用按照10GB进行分裂,而什么分裂取决于以下这个公式:

Min (R^2 * “hbase.hregion.memstore.flush.size”, “hbase.hregion.max.filesize”) R为同一个table中在同一个region server中region的个数。

R: 表的Region的数量
flush.size: 默认值为 128M
max.Filesize: 默认值 10GB

思考: 如果现在我希望, Region在5个时候, 最好就可以按照10GB分裂, 如何解决呢?

调整flush.size的大小