一条数据的HBase之旅，简明HBase入门教程10：Flush与Compaction旧流程回顾

前面一系列文章中，已经讲述了如下内容：

• HBase写数据可选接口以及接口定义

• 通过一个样例，介绍了RowKey定义以及列定义的一些方法，以及如何组装Put对象

• 数据路由，数据分发、打包，以及Client通过RPC发送写数据请求至RegionServer

• RegionServer接收数据以后，将数据写到每一个Region中。写数据流程先写WAL再写MemStore，这里展开了一些技术细节

• 简单介绍了HBase权限控制模型

至此，数据已经被写入WAL与MemStore，可以说数据已经被成功写到HBase中了。事实上，上篇文章讲到的Flush流程是"简化"后的流程，在2.0版本中，这里已经变的更加复杂。

这是1.X系列版本以及更早版本中的Flush&Compaction行为：

MemStore中的数据，达到一定的阈值，被Flush成HDFS中的HFile文件。

但随着Flush次数的不断增多，HFile的文件数量也会不断增多，那这会带来什么影响？在HBaseCon 2013大会上，Hontonworks的名为《Compaction Improvements in Apache HBase》的演讲主题中，提到了他们测试过的随着HFile的数量的不断增多对读取时延带来的影响：

尽管关于Read的流程在后面文章中才会讲到，但下图可以帮助我们简单的理解这其中的原因：

图中说明了从一个文件中指定RowKey为“66660000431^201803011300”的记录，以及从两个文件中读取该行记录的区别，明显，从两个文件中读取，将导致更多的IOPS。这就是HBase Compaction存在的一大初衷，Compaction可以将一些HFile文件合并成较大的HFile文件，也可以把所有的HFile文件合并成一个大的HFile文件，这个过程可以理解为：将多个HFile的“交错无序状态”，变成单个HFile的“有序状态”，降低读取时延。小范围的HFile文件合并，称之为Minor Compaction，一个列族中将所有的HFile文件合并，称之为Major Compaction。除了文件合并范围的不同之外，Major Compaction还会清理一些TTL过期/版本过旧以及被标记删除的数据。下图直观描述了旧版本中的Flush与Compaction流程：