HBase 手动 flush 机制梳理

对应 HBase 版本0.94.1，对照了开源的版本和工做使用的某发行版

问题：在 HBase shell 里面输入 flush 'table_or_region_name'以后，发生了什么？具体的实现是怎么样的？对于现有的某个表，我如何在作操做以前估算 flush 执行的时间？

1. HBase shell 入口

HBase shell 使用 ruby 实现，在 putty 敲hbase shell，调用的是${HBASE_HOME}/bin/hbase这个 bash 脚本，根据shell这个参数，触发调用 ruby 代码，相关的部分以下：

if [ "$COMMAND" = "shell" ] ; then
if [ "$JRUBY_HOME" != "" ] ; then
CLASSPATH="$JRUBY_HOME/lib/jruby.jar:$CLASSPATH"
HBASE_OPTS="$HBASE_OPTS -Djruby.home=$JRUBY_HOME -Djruby.lib=$JRUBY_HOME/lib"
fi
CLASS="org.jruby.Main -X+O ${JRUBY_OPTS} ${HBASE_HOME}/bin/hirb.rb"

在 hirb.rb 里面，引入相关的包（${HBASE_HOME}/lib/ruby目录下），而后启动一个运行的 CLI 环境。

进入正题了。

在 hbase shell 里面，全部执行的命令，都在${HBASE_HOME}/lib/ruby/shell/commands目录下，有对应的${COMMAND}.rb的对应文件。

找到 flush.rb，核心代码以下：

def command(table_or_region_name)
format_simple_command do
admin.flush(table_or_region_name)
end
end

这里调用了 admin.rb 这个文件里面的方法：

@admin = org.apache.hadoop.hbase.client.HBaseAdmin.new(configuration)
def flush(table_or_region_name)
@admin.flush(table_or_region_name)
end

到这里，就找到了 Java 程序的入口，调用了 HBaseAdmin.flush(table_or_region_name)这个方法。
后续几部分的类图以下：

2. HBaseAdmin 包装

HBaseAdmin 类下面包含了三个 flush 方法：

public void flush(String tableNameOrRegionName) throws IOException, InterruptedException {}
public void flush(byte[] tableNameOrRegionName) throws IOException, InterruptedException {}
private void flush(ServerName sn, HRegionInfo hri) throws IOException {}




• 第一个，做为入口，将 String 参数转化为 byte[]，交给第二个
• 第二个，主要的工做方法，按输入参数是 region 名、分区表、不分区表，分别进行处理
• 第三个，单独针对 region 进行 flush

第一个略过。

第二个，逻辑清晰：

• 若是是参数为 Region，就调用第三个 flush 处理
• 若是不是分区表，就获取该表包含的全部 Region，挨个调用第三个 flush 处理，
• 若是地分区表，处理方式与其余的不一样，调用了一个分区表公共处理方法 execPartitionTableAction 订制实现了匿名类 PartitionTableActionCallableFactory，进行单独处理。

注意

• 对于没有预分区的表，简单地在一个 for 循环里面，串行处理
• 对于分区表，execPartitionTableAction中使用了并发数据结构 Future，对分区是并行处理

第三个，对每一个 Region 进行 flush，其实是第二个 flush 中全部 case 最终的归宿。

在第三个 flush 中，实现代码以下：

HRegionInterface rs = this.connection.getHRegionConnection(sn.getHostname(), sn.getPort());
rs.flushRegion(hri);

HRegionInterface 是一个抽象接口，flushRegion 是一个抽象方法。在0.94.1这个版本下，只有 HRegionServer 实现了 HRegionInterface 接口，因此要在 HRegionServer 里面找到具体的代码实现。

3. HRegionServer 包装

在 HRegionServer 类里面，包含了三个 flush 的实现：

public void flushRegion(byte[] regionName) throws IllegalArgumentException, IOException {}
public void flushRegion(byte[] regionName, long ifOlderThanTS) throws IllegalArgumentException, IOException {}
@QosPriority (priority=100)
public void flushRegion(HRegionInfo regionInfo) throws NotServingRegionException, IOException {}

 

• 第一个，简单地传入 regionName，肯定 Region 在线，而后调用region.flushcache()
• 第二个，传入 regionName 和 超时时间戳 ifOlderThanTS ，肯定 Region 在线，且未超时的状况下，将数据 flush 出去
• 第三个，@QosPriority (priority=100)标记，使用了自定义声明，给该方法赋值 rpc 调用的优先级；方法体checkOpen()检查 RegionServer 在线后，调用region.flushcache()

接下来，查看看下 HRegion 类下面flushcache()的实现。

4. HRegion 实现

flushcache只是个入口方法，会作一些 flush 以前的准备工做，包括：创建任务状态监控、判断 Coprocessor、处理未 WAL 的 put 、写加锁等。以后，调用内部方法internalFlushcache开始flush。

在 internalFlushcache 方法实现中，作了 MVCC 的一些工做，最终，调用了StoreFlusher的flushCache方法实现。

internalFlushcache 为了保证数据一致性作了不少的检查、校验、加锁，目前功力不够，先标记下，进入下一层。

看下 StoreFlusher 的实现。

5. StoreFlusher 实现

StoreFlusher 是个接口，在0.94.1这个版本里面，只有 Store.StoreFlusherImpl 一个实现类。

在 StoreFlusher 接口里面能够看到，flush 操做执行的过程当中包含3个部分：

1. prepare，这是个短操做，建立 snapshot，这个过程当中会暂停写操做
2. flushCache，flush 执行的过程当中，是不会阻塞该 store 上的任何操做（读写）
3. commit，将 flush 出的文件添加到 store 目录下，清除 memstore 快照，短操做，会足暂停 scan

6. StoreFlusherImpl 实现

StoreFlusherImpl 是 Store 类的内部私有类，前面提到的 StoreFlusher 的3个方法，由 StoreFlusherImpl实现后，prepare 是本身实现，flushCache和 commit 都是调用外部 Store类的方法来完成。

6.1 prepare

public void prepare() {
memstore.snapshot();
this.snapshot = memstore.getSnapshot();
this.snapshotTimeRangeTracker = memstore.getSnapshotTimeRangeTracker();
}

调用了 MemStore 的方法，作快照。

6.2 flushCache

从 StoreFlusherImpl 调用 Store 类的flushCache方法，包装了internalFlushCache方法来实现。
逻辑比较清晰：

• 启动一个 StoreScanner，根据时间戳和ScanType 参数，找出须要被 Flush 的行
• 启动一个StoreFile Writer，把读出来的数据，写入到一个 StoreFile 中，并将该 StoreFile 的路径返回，供后续 commit 阶段使用

6.3 commit

StoreFlusherImpl 类的 commit 方法首先调用外部 Store类的commitFile方法，主要作的事情有两件：

• 将 flushCache 生成的 StoreFile 移动到 Store所在目录下
• 更新 Store 的相关统计参数

而后会调用外部 Store类的updateStorefiles更新 Store 类的 storefile，更新文件后，须要调用needsCompaction()，查看下是否由于本次 flush 执行形成的文件变化会触发 Compaction。若是触发 Compaction，会启动 Compaction 相关的一套机制继续执行，后续再单独介绍。

至此，手动 flush 操做背后的实现，初步梳理完毕。前面只是一个调用路径的梳理，后面继续丰富和补充。