Hbase合并流程分析

Posted 2021-04-19 大数据伐木累

Hbase是一种The Log-Structured Merge-Tree架构模式，每次当数据达到一定大小的时候flush到磁盘持久化到文件系统上。但随着数据不断的写入，flush的次数不断增多，小文件会越来的越多，导致读取IO增加，延迟增大。因此，Hbase需要不断的取合并这些小文件，这个过程就是Compaction。

简介

Compaction过程看似复杂其实很简单，首先从region中筛选出可以合并的文件，然后顺序将KeyValue读取出来，按大小排序后写到一个新的文件当中，将原来的文件移动到回收站，然后让合并好的文件提供服务。合并包含两类：Mini Compaction和Major Compaction。

Mini Compaction

选取原始flush文件或者较小的hfile文件进行合并，合并过程中不会删除delete标记和ttl过期数据，只会按顺序将数据合并成更大的数据文件。

Major Compaction

将所有可选择的文件合并成一个更大的hfile文件，同时会删除delete数据，ttl过期数据和超过设置版本号的数据。这个过程占用系统IO资源过大，会对线上业务产生一定影响，一般推荐在周末或夜间数据量较小的时候进行，或者直接关闭Major Compaction直接手动执行。

流程

触发Compaction：

• Memstore flush：

  每当Memstore写到配置文件指定大小的时候会触发flush操作生成新的hfile文件，这个时候compact线程会自动检查当前待合并文件个数是否符合合并要求，如果符合则触发mini compaction执行合并。

• 系统周期性检查：

  Hbase会定期判断是否满足合并条件，如果满足合并条件则执行合并操作。检查周期：hbase.server.thread.wakefrequency*hbase.server.compactchecker.interval.multiplier，如果文件数不满足合并条件会继续检查是否满足major compaction。

• Hbase shell：

  人为在Hbase shell中执行合并操作。

选择Hfile文件策略：

• RatioBasedCompactionPolicy

  条件一：指定hfile文件小于比它新的所有文件大小和*ratio(非高峰：hbase.offpeak.start.hour至hbase.offpeak.end.hour为1.2，高峰5)

  条件二：当前所剩候选文件个数不大于最小合并文件数（hbase.store.compaction.min）当找到满足条件的文件后，待合并文件为指定hfile文件以及比它更新的所有文件。

• ExploringCompactionPolicy

  选择待合并文件条件同RatioBasedCompactionPolicy，进而在此基础上继续优化，为了减少系统的IO消耗会继续计算出一个最优的合并方案：

  规则一：尽可能先合并较小的文件，减少文件个数

  规则二：尽可能合并大小相差不大的文件，减少不必要IO

选择线程池：

Compaction中有两个线程池largeCompactions和smallCompaction，其中从字面意思可以看出large是进行较大合并的，small是进行小规模合并操作的。若待compact的文件总大小如果大于值throttlePoint（hhbase.regionserver.thread.compaction.throttle）分配给largeCompactions，否则分配给smallCompactions。

合并文件：

1. 将要合并的HFIle中KeyValue读取到内存中进行排序，将配好序的结果写入到一个稍大的Hfile中放在.tmp目录下

2. 移动所有合并好的数据文件到region数据目录

3. 将合并操作写入hlog中

4. 将待合并文件全部删除

幂等性：

若1失败，.tmp目录对数据没有影响也不会被读取到。

若2失败，region数据目录下数据会造成冗余，但是hbase读取过程中会对所有符合要求的rowkey数据进行排序，结果仍然唯一。

若3失败，hbase恢复时会重新读取hlog，恢复compaction完成接下来的流程

若4失败，hbase会通过hlog删除合并前待合并文件