- StoreFile Compaction
由于MemStore每次刷写都会生成一个新的HFile，且同一个字段的不同版本（timestamp）和不同类型（Put/Delete）有可能会分布在不同的HFile中，因此查询时需要遍历所有的HFile。为了减少HFile的个数，以及清理掉过期和删除的数据，会进行 StoreFile Compaction。
Compaction分为两种，分别是Minor Compaction和Major Compaction。
（1）Minor Compaction
触发时机：小文件[小于128M]数达到3个会触发
结果：尽可能的将一些 较小的HFile 合并成一个 较大的HFile，合并文件的时候只是单纯的合并文件的内容，不会删除过期数据与无效数据
（2）Major Compaction
触发时机：默认是7天合并一次，hbase.hregion.maiorcompaction(默认值604800000ms)，设置为0，即取消自动合并
- 由于Major Compaction需要将数据读出来然后合并重写，所以会十分耗费资源
结果: 将每个 Store 中的，所有的 StoreFIle 合并成一个文件，合并文件的时候，会删除过期数据与无效数据
- Region Split
默认情况下，每个Table起初只有一个Region，随着数据的不断写入，Region会自动进行拆分。刚拆分时，两个子Region都位于当前的Region Server，但处于负载均衡的考虑，HMaster有可能会将某个Region转移给其他的Region Server。
Region Split时机：
1）0.94版本之前：使用的是 ConstantSizeRegion SplitPolicy 策略。
当1个 Region 中的某个 Store下所有StoreFile的总大小超过hbase.hregion.max.filesize（默认10G），该Region就会进行拆分。
2）0.94版本~2.0版本：使用的是 IncreasingToUpperBoundRegion SplitPolicy 策略。
当1个 Region中 的某个Store下所有StoreFile的总大小超过Min(R^3 * 2 * "hbase.hregion.memstore.flush.size",hbase.hregion.max.filesize")，该Region就会进行拆分，其中R为当前Region Server中属于该Table的Region个数。
R == 0 || R>100 ? 10G : Min(10G, 2 * 128M * R^3)
3）2.0版本之后：使用的是 Stepping SplitPolicy 策略。
当前RegionServer中属于该Table的Region个数为1，分裂阈值等于flushSize*2，否则为hbase.hregion.max.filesize。
R == 1 ? 2*128M : 10G