HBASE Compaction 简介
HBASE Compaction 简介
序
since: 2021年4月8日 9:43
auth: Hadi
参考：
https://blog.csdn.net/u011598442/article/details/90632702
http://hbasefly.com/2016/07/25/hbase-compaction-2/?oudery=krl7p&xovahc=btigk
为什么要执行Compaction
HBase 是基于LSM-Tree 存储模型设计的，写入路径上是先写入WAL，
在写入memstore缓存，满足一定条件后执行flush操作将缓存数据刷新到磁盘，
生成一个HFile数据文件。
随着HFile文件越来越多，就会影响查询性能（io次数增加）
所以HBase会合并小的HFile，来减少文件数量，这种合并叫做Compaction。
Compaction 类型
是一个资源密集型操作（磁盘和网络皆有），网络IO在于HFile最终是存储在HDFS上的，HDFS通常会有副本同步，造成网络IO。
Compaction 分类
Minor Compaction 和 Major Compaction两种，图示如下：
Minor
选取一些小的、相邻的HFile合并成一个更大的HFile。
默认情况下，minor会删除TTL过期数据。
Major
将一个Store中的所有的HFlie合并成一个HFile。
物理删除 delete，TTL，version 数据。
生产环境下请关闭major功能，在业务低峰期手动触发
Compaction 触发条件
HBase触发Compaction的条件有三种： memstore Flush、后台线程周期检查、手动触发。
memstore flush
compaction的根源就是flush，
memstore达到一定阈值或者其他条件时就会触发flush操作，刷写到磁盘生成HFile文件。
HBase每次flush后，会判断是否需要进行compaction，满足minor/major的条件便会触发执行。
后台线程周期检查
CompactionChecker 会定期检查，
周期：
hbase.server.thread.wakefrequency * hbase.server.compactchecker.interval.multiplier
一段事件内没有写入请求仍然需要做compact检查。
hbase.server.thread.wake.wakefrequency（默认10000 10s ）HBase服务端线程的唤醒时间
用于周期性检查 log roller、memstore flusher 等操作的周期性检查
hbase.server.compactchecker.interval.multiplier（默认1000）
compaction周期性检查乘数因子
默认算下来就是10*1000=1hrs,46mins,40sec
Compaction参数解析
Major Compaction
大合并时间间隔
hbase.hregion.majorcompaction
605800000 （ms）
默认为7天调度（0.96及以前为1天一次），设置为0表示禁用触发major compaction
生产环境请配置为0，手动进行触发major compaction
Major compaction 抖动参数
hbase.hregion.majorcompaction.jitter
0.5
避免major compaction 同时在各个regionserver上同时发生，避免此操作给集群带来很大压力。
major compaction就会在+或-两者乘积的时间范围内随机发生。
Minor Compaction
最少合并HFile数量
hbase.hstore.compaction.min
3
最少3个符合HFile的合并文件才进行合并
建议调大，如果过小，则会带来更频繁的Minor Compaction
最多合并HFile数量
hbase.hstore.compaction.max
10
最多满足Hfile 10个进行合并。
不建议调大，过大导致压缩时间的延长
小于多少的HFile参与合并
hbase.hstore.compaction.min.size
128MB （memstoreFlushSize）
HFile如果小于128MB，则会被选中进行compaction
一般别改，但如果write-heavy，写压力很大的场景，需要微调该参数，减小参数值。
加入每次memsotre大小达到1~2M就flush，生成HFile了，此时生成的每个HFile都会加入压缩队列。
而且压缩生成的HFile又会进入压缩队列，继续压缩。
大于多少的HFile不参与合并
hbase.hstore.compaction.max.size
Long.MAX_VALUE
HFile如果小于128MB，则会被选中进行compaction
一般别改。
hbase.hstore.compaction.ratio
1.2
这个ratio参数的作用是判断 文件大小 > hbase.hstore.compaction.min.size的HFile是否也是适合进行minor
一般别改。建议取值范围在1.0~1.4之间
hbase.hstore.compaction.ratio.offpeak
5.0
此参数与compaction ratio参数含义相同，是在原有文件选择策略基础上增加了一个非高峰期的ratio控制
这个参数受另外两个参数 hbase.offpeak.start.hour 与 hbase.offpeak.end.hour 控制，
这两个参数值为[0, 23]的整数，
用于定义非高峰期时间段，默认值均为-1表示禁用非高峰期ratio设置。
compaction 线程池选择
Hbase RegionServver 内部专门有一个CompactSplitThread
用于维护执行minor compaction 、major compaction、split、merge操作的线程池。（前面有CompactionChecker检查）
其中与compaction操作有关的线程池称之为
largeCompactions（又名longCompactions) 与 smallCompactions （又名shortCompactions）
前者处理大规模compaction，后者处理小规模compaction。
线程池大小都默认为1.
这里major compaction的操作并不是一定指向largeCompactions 操作。
判定方法为：
hbase.regionserver.thread.compaction.throttle
默认为2 * hbase.hstrore.compaction.max* hbase.hregion.memstore.flush.size
如果flush size 大小事128MB，则计算出来为2.5G。
一次compaction的文件总大小如果超过改配置，就会分配给largeCompactions，不然就是smallCompactions
hbase.regionserver.thread.compaction.large
hbase.regionserver.thread.compaction.small
这两个配置可以进行调整，建议范围为2~5之间，不建议设置过大否则可能消费过多的服务端资源，造成不良影响。
Compaction 策略原则
compaction的设计必须要有一个平衡点，一方面保证compaction的基本效果，另一方面不能带来严重的IO压力。
所以compaction的策略必须根据应用场景和数据集来进行设计。
HBase在后续就提供一种机制来针对不同设计策略进行测试，让用户针对自己的业务场景选择合适的compaction策略。
0.96版本中HBase对架构进行了一定的调整，
提供了Compaction插件接口，用户实现这些接口就可能根据自己的应用场景和数据集定制特定的compaciton策略。
并且Compaction可以支持table/cf粒度级别的策略设置，是的用户可以根据应用场景的不同设计不同的策略。
所以：根据业务场景和数据集来设定Compaction的策略！
减少Compaction的文件数
文件根据rowkey、version等属性进行分割，再将这些重要的属性合并
不要合并大文件，合并时间会很长
不要合并不需要合并的文件
TSDB时序数据场景下的老数据，基本上就不会查询到，因此不进行合并也不会影响查询的性能
小region更有利于合并
小region在进行合并的时候，只会生成少量文件
写入放大的概率和频率小一丢丢
Compaction 策略介绍
HBase的compaction policy 有四种：
RatioBasedCompactionPolicy
0.96.X以前的默认
ExploringCompactionPolicy
0.96.X以后的默认
性能更高
一般不会进行更改
FIFOCompactionPolicy
收集所有过期的数据文件并删除
不会执行真正的重写
适合时序数据
StripeCompactionPolicy
将一个大Region切分为很多小subRegion
适用于Region大小大于2G的场景，要求Rowkey具有一定的统一格式。
来规避Major Compaction
加快查询速度
Compaction 对读写请求的影响
写入放大
Hbase Compaction会带来写入放大，特别是在写多读少的情况下，就会比较明显。
随着minor compaction 以及major Compcation 的发生，数据会被反复读取/写入。
这里会涉及到网络IO和磁盘IO （HDFS中的副本）
读路径上的延时毛刺
HBase执行compaction操作结果会使文件数基本稳定，进而IO Seek次数相对稳定。
延迟就会稳定在一定范围内，然而，compaction操作会带来很大的带宽压力，以及短时间的IO压力。
因此compaction就是使用短时间的磁盘网络IO来换取后续的查询的低延迟。
这种短时间的压力就会造成读请求在实验上会有比较大的毛刺。
写请求上的短暂阻塞
Compaction对写请求也有很大的影响。
主要表现在HFile较多的场景下，会对写请求的速度进行限制。
如果底层HFile数量超过
hbase.hstore.blockingStoreFiles
10
flush操作将会受到阻塞，阻塞时长为
hbase.hstore.blockingWaitTime
90000 (1.5min)
在这段时间内，如果compaction操作使得HFile下降到了预设阀值，则停止阻塞。
如果超过时间后，也会恢复进行flush操作。
Compaction总结
Hbase Compation操作是为了数据读取做的优化，总的来说是以牺牲了磁盘网络IO来换取了读性能的基本稳定。
在实际运用中，合理使用Compaction策略是极为重要的。