StripeCompactionPolicy
Stripes表示条纹，意为将Region分为多个条纹区间分别做compact，类似于将Region分为多个Sub-Region。
适用场景：
- Region较大：相对于较小的Region而言，对MemStore和Region的管理带来的负担更小。
- 新产生的行键不均匀分布在各Region：如基于时间序列的行键生成方式，新生成的数据行均分布在Region的同一个Sub-Region区间，只有新产生的那一部分行键相关数据会被合并，旧的数据行会很少合并或者根本不合并。
DateTieredCompactionPolicy
按时间分层合并，顾名思义，该合并策略与时间相关，适用于数据写入基于时间产生且无更新删除，数据读取会指定数据读取区间，并且读取新产生的数据的频率较大。
按时间分层合并策略通过感知需要合并的HFile的数据写入相关时间戳，并不会将新老数据合并为一个大的HFile，而是按时间分层结构来组织合并HFile，所以不同时间写入的相邻行键数据可能被放入不同的HFile，这样对基于时间区间的扫描效率是一个很大的提升，但是对基于行键的区间扫描效率会是一个很不友好的策略。
RatioBasedCompactionPolicy
基于比列的合并策略，该策略在0.98版本之前是HBase默认的策略，之后的版本使用了基于比例策略的一个改进版本（ExploringCompactionPolicy），如果是Major合并，那么该策略会将所有的StoreFile文件合并为一个大的文件，如果是Minor合并，使用如下策略选择需要合并的文件：
前提：假设最老的StoreFile文件大小最大，选择待合并的文件按时间排序，最旧的文件排最前。
配置项hbase.hstore.compaction.ratio合并参数，命名为R
配置项hbase.hstore.compaction.min最小待合并文件数，命名为A。
配置项hbase.hstore.compaction.max最大待合并文件数，命名为B。
配置项hbase.hstore.compaction.min.size最小合并文件总大小，命名为C，以R=0.1，A=3，B=5，C=20，待合并的文件为O=[50,40,30,30,20,10,5]为例子
- 计算一个待合并文件总大小的数组fileSizes[i,i+A-1) ，得到X = [150, 120, 90, 65, 35, 15, 5]。
- 从旧到新文件，逐一判断文件大小是否满足 fileSizes[i] > Math.max(C, (X[i + 1] * R)) ，当条件不满足后，i即为待合并的文件开始位置，该步骤是为了过滤掉大的文件，此处得到i=4。
- 最后得到需要合并的文件列表为O.subList(4,O.size-1)，得出结果为[20, 10, 5]。
简化后的代码片段如下所示
package com.mt.hbase.chpt07.compact;
import java.util.Arrays;
import java.util.LinkedList;
import java.util.List;
/**
* @author pengxu
* @Date 2018/12/9.
*/
public class RatioCompactPolicy {
public static List<integer> applyCompactionPolicy(List<integer> candidates , boolean mayBeStuck){
int minFileToCompact = 3;
int maxFileToCompact = 5;
int minCompactSize = 20;
double ratio = 0.1;
int start = 0;
// get store file sizes for incremental compacting selection.
final int countOfFiles = candidates.size();
long[] fileSizes = new long[countOfFiles];
long[] sumSize = new long[countOfFiles];
for (int i = countOfFiles - 1; i >= 0; --i) {
fileSizes[i] = candidates.get(i);
// calculate the sum of fileSizes[i,i+maxFilesToCompact-1) for algo
int tooFar = i + maxFileToCompact - 1;
sumSize[i] = fileSizes[i] + ((i + 1 < countOfFiles) ? sumSize[i + 1] : 0) - ((tooFar
< countOfFiles) ? fileSizes[tooFar] : 0);
}
while (countOfFiles - start >= minFileToCompact &&
fileSizes[start] > Math.max(minCompactSize, (sumSize[start + 1] * ratio))) {
++start;
}
if (start < countOfFiles) {
System.out.println("Default compaction algorithm has selected " + (countOfFiles - start)
+ " files from " + countOfFiles + " candidates");
} else if (mayBeStuck) {
// We may be stuck. Compact the latest files if we can.
int filesToLeave = candidates.size() - minFileToCompact;
if (filesToLeave >= 0) {
start = filesToLeave;
}
}
System.out.println("sumSize=" + Arrays.toString(sumSize));
System.out.println("start=" + start);
candidates.subList(0, start).clear();
System.out.println("fileToCompact =" + candidates);
return candidates;
}
public static void main(String[] args) {
int[] candidateIntArray = new int[] { 50, 40, 30, 30, 20, 10, 5 };
List<integer> candidateList = new LinkedList<integer>();
for(Integer candidate : candidateIntArray){
candidateList.add(candidate);
}
applyCompactionPolicy(candidateList,true);
}
}
ExploringCompactionPolicy
该策略继承自RatioBasedCompactionPolicy，其选择待合并的文件列表算法非常简单，即根据上述参数（最小待合并文件数、最大待合并文件数、合并参数、合并文件总大小）组合计算出一个文件数最多，文件总数最小的文件区间组合，这个计算类似用一个滑动窗口去计算窗口内文件数量与大小的比例，文件越小数量越多则为最优解。
FIFOCompactionPolicy
该策略继承自ExploringCompactionPolicy，仅仅选择所有数据均已经过期的StoreFile文件进行合并，所以表的列族需要指定数据的TTL，故该合并策略仅适用于临时存储数据，经过处理后会被全部丢弃的场景。
HBase从1.2.X开始到2.0.X，默认的压缩策略都是RatioBasedCompactionPolicy，可以通过如下两种方式修改默认的压缩策略：
- 修改hbase-site.xml配置项hbase.hstore.engine.class，该修改会应用到整个HBase集群。
- 执行表修改语句alter 's_behavior', CONFIGURATION => {'hbase.hstore.engine.class' => 'rg.apache.hadoop.hbase.regionserver.DefaultStoreEngine'}，该修改方式只对语句指定的表生效
