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会越频繁。单位字节，默认128Mhbase.hstore.compaction.max.size=9223372036854775807
大于该值的storeFile不会进行compaction。增大该参数，会使一些较少同时较大的storeFile不会经常compaction。如果compaction发生较频繁，可以考虑增大该值。单位字节，默认LONG.MAX_VALUEhbase.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.50hbase.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的数量，避免频繁进行。