HBase之Compaction

Compaction

随着memstore的不断flush,storefile的数量将会不断增加。compaction将通过合并storefile来减少文件数量,并提高读性能。conpaction以store为单位

Compaction分为两种,minor和major。

  • minor通过选择较小的相邻文件,合并重写为单个storefile。minor合并不会删除delete或者过期的版本数据。
  • major合并的最终结果是每个store下只有一个StoreFile,major合并将会清除已标记删除的最大版本。
    HBase中发生显式删除时,数据实际上并没有被删除。只是会写入一个删除标记,这样在查询时将不会返回有该标记的数据。在major合并中,数据被最终删除。
    major合并默认每七天执行一次。可以使用compaction_switch命令动态开关rs的Compaction

触发条件

1.超过一定的storefile数量:flush不断执行,storefile的数量会不断增多
2.后台线程周期检查:线程 CompactionChecker,定期触发检查是否需要执行 Compaction
3.手动触发:通过hbase shell或API触发

相关参数

  • 选取策略相关
hbase.hstore.compaction.min.size=134217728
storeFile小于该值时,会选择进行minor compaction。大于等于该值时由hbase.hstore.compaction.ratio参数来决定是否compaction。在一些写业务中如果storeFile仅仅在1-2M之间,建议减小该值,避免compaction之后的文件大小仍然小于该值从而继续compaction。此参数越小,ratio check会越频繁。单位字节,默认128M

hbase.hstore.compaction.max.size=9223372036854775807
大于该值的storeFile不会进行compaction。增大该参数,会使一些较少同时较大的storeFile不会经常compaction。如果compaction发生较频繁,可以考虑增大该值。单位字节,默认LONG.MAX_VALUE

hbase.hstore.compaction.ratio=1.2F
对于minor compaction,该参数决定大于hbase.hstore.compaction.min.size的StoreFile是否进行压缩。增大该参数,写代价会变大,因为会合并更大的storefile,但此时读也会seek相对较少的storefile提高速度。

hbase.hstore.compaction.ratio.offpeak=5.0F
非高峰期参数 与hbase.hstore.compaction.ratio类似,只有hbase.offpeak.start.hour和hbase.offpeak.end.hour启用时才会生效

hbase.offpeak.start.hour=-1
非高峰期的开始时间,表示为0到23之间的整数(包括0和23)

hbase.offpeak.end.hour=-1
非高峰期的结束时间,表示为0到23之间的整数(包括0和23)

  • 触发条件相关
hbase.hstore.compaction.min=3
如果在任何store中StoreFile的数量超过该值,将会进行compaction。这个值越大,compaction发生的会越晚,耗费的时间也会更多

hbase.hstore.compaction.max=10
一次minor compaction可以合并的最大StoreFile数量

hbase.hregion.majorcompaction=604800000
majorcompaction之间的时间间隔,默认单位毫秒。设置为0将禁用自动majorcompaction,但用户请求和基于大小的major compactions将仍然会运行。compaction 将会在给定时间窗口内的某个随机时间开始,该时间为该值乘以hbase.hregion.majorcompaction.jitter,默认为7天。

hbase.hregion.majorcompaction.jitter=0.50

hbase.server.compactchecker.interval.multiplier=1000
compactchecker运行的间隔时间

hbase.server.thread.wakefrequency=10000 ms
compactchecker的sleep时间

hbase.hstore.blockingStoreFiles=16
任何一个store下的StoreFiles超过该值,则memstore的刷新将会被阻塞直到compaction完成或者达到阻塞等待的时间(hbase.hstore.blockingWaitTime)

hbase.hstore.blockingWaitTime=90000
  • 线程池相关
hbase.regionserver.thread.compaction.throttle=2684354560=2* hbase.hstore.compaction.max*hbase.hregion.memstore.flush.size
compaction有两个不同的线程池,分别用于 large compaction和small compaction。如果compaction大于该值,将会进入large compaction pool。

hbase.regionserver.thread.compaction.small 
hbase.regionserver.thread.compaction.large
指定线程池的线程数 
  • 吞吐相关
hbase.hstore.compaction.throughput.lower.bound=52428800
compaction的吞吐流量下限,字节/秒

hbase.hstore.compaction.throughput.higher.bound=104857600
compaction的吞吐流量上限,字节/秒

文件选取策略

hbase.hstore.defaultengine.compactionpolicy.class 通过该参数设置

  • RatioBasedCompactionPolicy:老版策略。找到一个合适的文件集合之后即停止。
  • ExploringCompactionPolicy:新版默认策略。相比起来,记录下所有合适的文件集合,并在这些文件集合中寻找最合适的集合。

ExploringCompactionPolicy

ExploringCompactionPolicy:默认策略,
1.列出store中所有的storefile,算法过滤出需要进行合并的子集
2.满足一些条件的storefile会被排除在外

  • 大于hbase.hstore.compaction.max.size参数大小的
  • bulk-load中明确指定排除合并的
    3.遍历上述列表,选出符合条件的集合,并执行一些健全检查
  • 如果集合中文件数量少于hbase.hstore.compaction.min或大于hbase.hstore.compaction.max,则不考虑compaction
  • 回退考虑:与列表中已经找到可以合并的集合中的storefile大小进行比较,具有更小storefile大小的集合将会被存储起来,以便在memstore阻塞且无法找到可合并的集合时使用
  • 对每个storefile执行检查,文件大小大于hbase.hstore.compaction.max.size的不考虑,文件大小大于或等于hbase.hstore.compaction.min.size的,如果此时该文件大小乘以hbase.hstore.compaction.ratio小于其他新的storefile(比当前文件时间更新的)之和,则会考虑
    4.通过比较找到最合适的集合并执行合并。如果此时存在多个storefile但是没有符合条件的,此时会执行回退考虑。

常见优化

1.关闭major compaction,改为手动触发执行。对于较大的storefile,也会类似引起IO升高,斯所以可以将满足compaction条件的最大文件设置小一点,具体根据业务来。
2.可以考虑略调大满足minor compaction的数量,避免频繁进行。

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>