目录
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触发
相关参数
- 选取策略相关
bash
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）- 触发条件相关
bash
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- 线程池相关
bash
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
指定线程池的线程数 - 吞吐相关
bash
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的数量，避免频繁进行。