Hbase-之StoreFile的Compaction

1 前言

在谈及storefile的compaction内容之前，我们先搞清楚几个模棱两可的术语：

StoreFile实际上是针对Hbase的专业术语，实际上与HFile是同一个概念，在compaction的期间，用StoreFile代替HFile称呼会更好；
Store与ColumnFamily实际上是同一个概念，我们可以称StoreFile与Store有关系或者StoreFile与ColumnFamily有关系；
假如你想用StoreFile代替HFile，Store代替ColumnFamily都是可以的，反之亦然。

当每个Store对应的MemStore达到指定的阈值hbase.hregion.memstore.flush.size,就会将其中的内容flush到StoreFile，所以随着时间的推移，StoreFile的数量会越来越多，为了减少Store中的StoreFile的数量，Compaction操作通过将这些StoreFile merge合并到一起。

为了提高读取操作的性能，compaction将会占用大量的集群资源，这个一把双刃剑，可能会帮助，也可能会阻碍性能表现，这取决于多个因素。

这里还有一点！！！！！！！！！！compaction操作不是region merge！！！！！！！！！

compaction是在每个Store内部对相关的StoreFile进行合并；
region merge是针对region级别的合并，主要是将原数据以及HDFS上的region目录进行合并，不涉及到StoreFile的合并；

2 compaction分类

compaction操作分为2类：minor 和major，可以通过以下几种方式区分minor compaction和major compaction

minor compaction通常选取少量同时小且相邻的StoreFile，然后将他们的内容归并写入一个更大的StoreFile；
- minor compaction的最终结果是Store中的StoreFile大小变大了，且StoreFile的数量变少了。
major compaction通常不会事先过滤掉deletes和过期版本的数据，因为在这次归并的过程中，compaction操作会将这些操作类型的数据删除，按照默认设置，Hbase会每7天进行一次major compaction。
- 而major compaction的最终结果是每个Store最终只有一个StoreFile，major compaction同时会处理deleted的墓碑标记以及数据，以及版本信息

3 major compaction与deletes的关系

Hbase执行一个delete操作的时候，并不会将数据真正的从文件中删除，而是在StoreFile中为该数据建立一个tombstone marker，这个marker会保证在查询的时候不返回该数据，当执行一次major compaction操作的时候，这个被标记的数据才被清除，同时tombstone也将会被从StoreFile中移除；但是假如delete操作不是手动执行而是由于TTL超时的原因，该数据不会创建tombstone，而是在写入最终的那个最终的compact storefile的时候，该数据不会被写入文件。

4 major compaction与max version的关系

当你需要创建一个ColumnFamily的时候，你能为该ColumnFamily指定允许保留的最大的版本数量，通过HColumnDescriptor.setMaxVersions(int versions)方法，默认值为3，如果插入的版本数量超过默认指定的版本数量，那么就会将多余的版本数据过滤掉，只将最新的3个版本的数据写入到最终的那个StoreFile。

major compaction可能会影响查询的结果，且这种情况只会发生在compaction操作完成之前

假如将cf的默认最大版本数量设置为2
然后我们为同一个Cell插入3个版本的数据，依次为：

1
2
3
那么假如我们需要查询所有版本的数据，那么只有2、3版本的数据会被返回，而1被标记成多余版本；
但是如果你删除2、3其中的1个，那么1又会被变成有效版本，返回结果将会是1，2或者1，3

假如在删除2或者3其中之一之前，进行了major compaction，那么1的数据就不存在了，此时你再删除2、3其中之一，那么返回所有version的数据的时候只有2或3其中一个版本的Cell数据被返回。

所以总的来说，major compaction对用户来说实际上不是完全透明的！～～～

hbase的GC以及版本信息、过期时间信息可以参阅 bending time in hbase。

从理论上来讲，major compaction可以提升查询性能，然而，在一个高负载的系统下，major compaction也需要占用不合适的大量的资源，这对集群性能是不利的，在默认情况下major compaction被调度成每7天执行一次，通常有时major compaction刚好在系统搞负载的情况下执行，这是非常不利的，所以我们可以手动管理major compaction，具体操作可以参考内部管理的managed compaction。

如果需要精确major compaction的具体执行时间，我们可以禁用系统major compaction功能，通过hbase.hregion.majorcompaction,但是官方不建议禁用major compaction自动管理操作,因为major compaction是清理归并StoreFile的必要操作，我们可以通过hbase shell 或者Admin API手动运行major compaction。

major compaction不是region merge！

4.1 如何手动执行major compaction

我们可以针对不同范围的数据进行major compaction

Table
Region
Table-ColumnFamily

具体的Admin API，可以参考官方Hbase AdminAPI文档，下面是文档中的部分描述


//majorCompact table级别的compact
void majorCompact(TableName tableName)throws IOException
Major compact a table. Asynchronous operation in that this method requests that a Compaction run and then it returns. It does not wait on the completion of Compaction (it can take a while).
Parameters:
tableName - table to major compact
Throws:
IOException - if a remote or network exception occurs//majorCompactRegion Region级别的majorcompact
void majorCompactRegion(byte[] regionName)throws IOException
Major compact a table or an individual region. Asynchronous operation in that this method requests that a Compaction run and then it returns. It does not wait on the completion of Compaction (it can take a while).
Parameters:
regionName - region to major compact
Throws:
IOException - if a remote or network exception occurs//majorCompact columnfamily级别的majorcompact
void majorCompact(TableName tableName,byte[] columnFamily)throws IOException
Major compact a column family within a table. Asynchronous operation in that this method requests that a Compaction run and then it returns. It does not wait on the completion of Compaction (it can take a while).
Parameters:
tableName - table to major compact
columnFamily - column family within a table
Throws:
IOException - if a remote or network exception occurs

5 compaction 开启&关闭（慎用）

我们可以开启或者关闭compaction操作，当我们关闭compaction的时候，目前正在compaction的操作也会停止，我们可以在hbase shell中使用

#通过hbase shell来关闭compaction，该设置会在服务器重启之后失效
hbase > compaction_switch

如果想在regionserver之间设置restart之后自动生效的持久化配置，我们可以在hbase-site.xml中配置以下参数

#该参数是关闭所有的compcation，包括major和minor
#hbase.hregion.majorcompaction只是单独关闭major
hbase.regionserver.compaction.enabled=false

6 compaction 策略 - hbase0.96.x and 更高版本

当compact很大的storefile或者compact大量的storefiles的情况下，可能会造成这种情况：产生的IO负载超过了Hbase集群在不出现性能问题情况下的所能处理的IO上限；

所以Hbase选择合适的storefiles进入到compcation操作的方法称为compaction policy。

在hbase-0.96.x以前的hbase版本只支持1种compaction策略，这种策略被称为:RatioBasedCompactionPolicy,该策略到如今还是可以使用的，hbase-0.96.x及之后版本的引入的新的策略，也是默认的策略被称为：ExploringCompactionPolicy,该策略在出现之后也被移植到hbase-0.94和hbase-0.95版本上去使用。

简而言之，ExploringCompactionPolicy尝试找到每个Store中最适合进行compact操作的Storefile的集合，然后用最少的资源来处理，而RatioBasedCompactionPolicy则是取到符合标准的第一个Storefile的集合。

但是无论使用哪种compaction策略，Storefile文件集合的选择通过几个可以配置的参数来控制且通过多步操作来实现。这些参数将会被上下文解释，并且会将这些配置参数添加到一个能显示它们的描述、默认信息、改变它们的一张表中。

6.1 compaction算法阻塞

当MemStore达到一定的阈值，它会将内容数据flush到一个StoreFile。然而，Store的StoreFiles的数量是有一个上限的，这个上限通过hbase.hstore.blockingStoreFiles参数进行控制，如果StoreFile的数量超过这个值，MemStore的Flush操作将会等待直到StoreFile的数量通过一个或者多个compaction减少到该值以下。

如果恰好碰到MemStore太大，而且此时StoreFile的数量也超过参数限定范围，那么compaction算法就会阻塞，默认这个阻塞的时间既MemStore flush需要等待的时间为hbase.hstore.blockingWaitTime毫秒(ms)，如果等待时间超过这个值，那么无论如何MemStore都会进行Flush操作，就算hbase.hstore.blockingStoreFiles限定的StoreFile的数量达到上限，也会毫不留情的进行flush。

请思考一下以下问题：

hbase.hstore.blockingStoreFiles的值实际是允许flush的，但是该Store的数据在读取的时候会有更高的延迟。尝试查找出为什么Compaction操作没有跟上，是写入操作激增造成这样的情况吗？然后这种场景是定期发生还是偶发？还是Hbase集群的写入资源配置不足？

6.2 `ExploringCompactionPolicy 算法`

ExploringCompactionPolicy算法在选取最优storefile集合之前，会先考虑相邻的storefile，尽量将相邻的storefile放进选取的最集合中。该策略能减少major compaction的频率从而缩减性能开销。

通常ExploringCompactionPolicy能适用于大部分的场景，而且它是默认的策略。

具体的逻辑流程可以参考：https://hbase.apache.org/2.2/book.html#exploringcompaction.policy

6.3`RatioBasedCompactionPolicy 算法`

https://hbase.apache.org/2.2/book.html#compaction.ratiobasedcompactionpolicy.algorithm

6.4 compaction相关的可配置参数

可参考：compaction算法参数