CompactionChecker大概是2hrs 46mins 40sec 执行一次
线程先检查文件数是否大于配置，一旦大于就会触发compaction。
如果不满足，它会接着检查是否满足major compaction条件，
如果当前store中hfile的最早更新时间早于某个值mcTime，
就会触发major compaction（默认7天触发一次，可配置手动触发）。
手动触发
一般来讲，手动触发compaction通常是为了执行major compaction，一般有这些情况需要手
动触发合并
是因为很多业务担心自动major compaction影响读写性能，因此会选择低峰期手动触
发；
也有可能是用户在执行完alter操作之后希望立刻生效，执行手动触发major
compaction； 是HBase管理员发现硬盘容量不够的情况下手动触发major compaction删除大量过期数
据；
合并策略
承载了大量IO请求但是文件很小的HFile，compaction本身不会消耗太多IO，而且合并完成之后对读的
性能会有显著提升。
线程池选择
HBase CompacSplitThread类内部对于Split、Compaction等操作专门维护了各自所使用的
线程池
和Compaction相关的是如下的longCompactions和shortCompactions
前者用来处理大规模compaction，后者处理小规模compaction
默认值为2 * maxFlilesToCompact * hbase.hregion.memstore.flush.size
如果flush size 大小是128M，该参数默认值就是2 * 10 * 128M = 2.5G
合并策略选择
1.HBase 主要有两种 minor 策略: RatioBasedCompactionPolicy (0.96.x之前)和
ExploringCompactionPolicy(当前默认)
2.RatioBasedCompactionPolicy(基于比列的合并策略) 从老到新逐一扫描HFile文件，满足以下条件之一停止扫描 当前文件大小<比当前文件新的所有文件大小总和*ratio(高峰期1.2，非高峰期5) 当前所剩候选文件数<=阈值(默认为3) 3.ExploringCompactionPolicy策略(默认策略) 基于Ratio策略，不同之处在于Ratio策略找到一个合适文件集合就停止扫描，而Exploring策略 会记录所有合适的文件集合，然后寻找最优解，待合并文件数最多或者待合并文件数相同的情况下 文件较小的进行合并 4.FIFO Compaction策略
收集过期文件并删除，对应业务的列簇必须设置有TTL
5.Tier-Based Compaction策略(分层策略) 针对数据热点情况设计的策略，根据候选文件的新老程度将其划分为不同的等级，每个等级都有对 应的Ratio，表示该等级文件比选择为参与Compation的概率
6.Stripe Compation策略(条纹策略) 将整个Store中的文件按照key划分为多个range，此处称为stripe，一个Stripe内部就类似于 一个小Region，可以执行Minon Compation和major Compation
执行文件合并
分别读出待合并hfile文件的KV，并顺序写到位于./tmp目录下的临时文件中
将临时文件移动到对应region的数据目录
将compaction的输入文件路径和输出文件路径封装为KV写入WAL日志，并打上compaction
标记，最后强制执行sync
将对应region数据目录下的compaction输入文件全部删除
数据切分（Region Spilt）
通过切分，一个region变为两个近似相同大小的子region，再通过balance机制均衡到不同 region
server上，使系统资源使用更加均衡。
切分原因
数据分布不均匀。
同一 region server 上数据文件越来越大，读请求也会越来越多。一旦所有的请求都落在同一
个 region server 上，尤其是很多热点数据，必然会导致很严重的性能问题。
compaction性能损耗严重。
compaction本质上是一个排序合并的操作，合并操作需要占用大量内存，因此文件越大，占
用内存越多
compaction有可能需要迁移远程数据到本地进行处理（balance之后的compaction就会存在
这样的场景），如果需要迁移的数据是大文件的话，带宽资源就会损耗严重。
资源耗费严重
HBase的数据写入量也是很惊人的，每天都可能有上亿条的数据写入
不做切分的话一个热点region的新增数据量就有可能几十G，用不了多长时间大量读请求就会
把单台region server的资源耗光。
触发时机
每次数据合并之后都会针对相应region生成一个requestSplit请求，requestSplit首先会执行
checkSplit，检测file size是否达到阈值，如果超过阈值，就进行切分。
检查阈值算法主要有两种：ConstantSizeRegionSplitPolicy（ 0.94版本）和
IncreasingToUpperBoundRegionSplitPolicy（当前）
ConstantSizeRegionSplitPolicy :
系统会遍历region所有store的文件大小，如果有文件大小 > hbase.hregion.max.filesize(默 认10G)，就会触发切分操作。
IncreasingToUpperBoundRegionSplitPolicy：
如果store大小大于一个变化的阀值就允许split。
默认只有1个region，那么逻辑这个region的store大小超过 1 * 1 * 1 * flushsize * 2 =
128M * 2 =256M 时，才会允许split
切分之后会有两个region，其中一个region中的某个store大小大于 2 * 2 * 2 * flushsize * 2
= 2048M 时，则允许split
后续超过hbase.hregion.max.filesize + hbase.hregion.max.filesize * 随机小数 *
hbase.hregion.max.filesize.jitter才允许split
基本也就固定了，如果粗劣的计算可以把这个hbase.hregion.max.filesize的大小作为最后的
阀值，默认是10G
切分流程
寻找切分点
将一个region切分为两个近似大小的子region，首先要确定切分点。切分操作是基于region执
行的，每个region有多个store（对应多个column famliy）。系统首先会遍历所有store，找
到其中最大的一个，再在这个store中找出最大的HFile，定位这个文件中心位置对应的
rowkey，作为region的切分点。
开启切分事务
切分线程会初始化一个SplitTransaction对象，从字面上就可以看出来split流程是一个类似‘事 务’的过程，整个过程分为三个阶段：prepare - execute - rollback
prepare阶段
在内存中初始化两个子region，具体是生成两个HRegionInfo对象，包含tableName、
regionName、startkey、endkey等。同时会生成一个transaction journal，这个对象
用来记录切分的进展
execute 阶段
region server 更改ZK节点 /region-in-transition 中该region的状态为SPLITING。
master检测到region状态改变。
region在存储目录下新建临时文件夹.split保存split后的daughter region信息。
parent region关闭数据写入并触发flush操作，将写入region的数据全部持久化到磁盘。
在.split文件夹下新建两个子文件夹，称之为daughter A、daughter B，并在文件夹中生
成引用文件，分别指向父region中对应文件。
将daughter A、daughter B拷贝到HBase根目录下，形成两个新的region。
parent region通知修改 hbase.meta 表后下线，不再提供服务。
开启daughter A、daughter B两个子region。
通知修改 hbase.meta 表，正式对外提供服务。 rollback阶段
如果execute阶段出现异常，则执行rollback操作。
为了实现回滚，整个切分过程被分为很多子阶段，回滚程序会根据当前进展到哪个子阶
段清理对应的垃圾数据。
74
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
