【大数据学习 | HBASE高级】storeFile文件的合并

Compaction 操作分成下面两种：

**Minor Compaction：**是选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，对于删除、过期、多余版本的数据不进行清除。
**Major Compaction：**是指将所有的StoreFile合并成一个StoreFile，对于删除、过期、多余版本的数据进行清除。优先采用Minor Compaction，如果达不到要求，再执行Major Compaction 。

注：Compaction的触发时机Major Compaction时间会持续比较长，整个过程会消耗大量系统资源，对上层业务有比较大的影响。因此线上业务都会将关闭自动触发Major Compaction功能，改为手动在业务低峰期触发。

HBase中可以触发compaction的因素 有很多，最常见的因素有这么三种：Memstore Flush、后台线程周期性检查、手动触发。

1）Memstore Flush：

每当 RegionServer发生一次Memstore flush操作之后也会进行检查是否需要进行Compaction操作。

2）周期性检查：

通过CompactionChecker线程来定时检查是否需要执行compaction（RegionServer启动时在initializeThreads()中初始化），每隔10000毫秒（可配置）检查一次。

一般系统触发都是minorCompact

合并主要有以下几个参数进行配置

java 复制代码

hbase.store.compaction.ratio默认值1.2f，大于最小值但是小于1.2倍数的大小的数据也参加合并
hbase.hstore.compaction.min 默认值2，每次合并最少两个hfile
hbase.hstore.compaction.max 默认值10，每次合并最多10个hfile
hbase.hstore.compaction.min.size 小于这个值的file肯定会参加合并
hbase.hregion.memstore.flush.size (128 mb).
hbase.hstore.compaction.max.size 大于这个值的肯定不会参加合并

3）手动触发：

手动触发compection通常是为了执行major compaction，执行命令"major_compact '表名'"，原因如下：

自动major compaction影响读写性能，因此会选择低峰期手动触发；

 执行完alter操作之后希望立刻生效，执行手动触发major compaction；

java 复制代码

# 创建表
create 'hainiu:student1','cf1'

put 'hainiu:student1','id01','cf1:name', 'n1'
flush 'hainiu:student1'
scan 'hainiu:student1'  # 拿到n1 的时间戳

put 'hainiu:student1','id01','cf1:name', 'n2'
flush 'hainiu:student1'
scan 'hainiu:student1'  # 拿到n2 的时间戳

# 用 n1的时间戳指定查询，是能查询到的
get 'hainiu:student1', 'id01', {COLUMN => 'cf1:name', TIMESTAMP => 1673596645265} 

# 执行major合并, 由于n1是历史版本，所以n1被合并没了， 只留下n2(最新版本数据)
major_compact 'hainiu:student1'

# 用 n1的时间戳指定查询，查询不到了（n1被合并没了）
get 'hainiu:student1', 'id01', {COLUMN => 'cf1:name', TIMESTAMP => 1673596645265}