flush刷新机制(溢写合并机制):

流程: 客户端不断将数据写入到memStore内存中, 当内存中数据达到一定阈值后, 需要将数据溢写刷新的HDFS中 形成一个storeFile文件
阈值: 128M 或者 1小时 满足任意个都会触发flush机制

内部详细流程: hbase 2.0架构 以上流程:
1) 客户端不断向memStore中写入数据, 当memStore只数据达到阈值后, 就会启动flush操作
2) 首先hbase会先关闭掉当前这个已经达到阈值的内存空间, 然后开启一个新的memStore的空间,用于继续写入工作
3) 将这个达到阈值的内存空间数据放入到 内存队列中, 此队列的特性是只读,在hbase 2.0架构中, 可以设置此队列的数据尽可能晚的刷新到HDFS中, 当这个队列中数据达到某个阈值后(内存不足), 这个时候触发flush刷新操作 (队列中可能存储了多个memStore的数据)
4) flush线程会将队列中所有的数据全部读取出来, 然后对数据进行排序合并操作, 将合并后数据存储到HDFS中, 形成一个storeFile的文件
注意: 在 hbase2.0以下的架构中, 不存在推迟刷新功能, 同样也不存在 合并数据的操作
当memStore数据达到阈值后, 放入到队列中, 专门有一个flush刷新监控队列,一旦有数据直接刷新到HDFS上

注意说明:
hbase 2.0 只是提供了基于内存的合并功能, 但是默认情况下 不开启的, 所以 在默认情况下整个flush机制基本和2.0以下的版本是一致的, 但是一旦开启了, 就是刚刚描述流程

合并方案: 三种
基础型(basic): 直接将多个memStore数据合并在一起直接刷新到HDFS上,如果数据存在过期的数据, 或者是已经标记为删除的数据, 基础型不做任何处理
饥渴型(eager): 在将多个memStore合并的过程中, 积极判断数据是否存在过期, 或者是否已经标记删除, 如果有, 直接过滤掉这些标记删除和过期的数据即可
适应性(adaptive): 检查数据是否有过期数据, 如果过期数据量达到一定阈值后, 就会自动使用饥渴型, 否则就使用基础型