HBase ProcedureV2 分析

Procedure V2, 是hbase1.1版本引入的一套fault-tolerant的执行multi-steps-job的框架, 目前主要用在Master中, 比如创建表,删除表等操作

新旧比较

下面比较0.94版本和1.25版本下的建表流程

0.94

0.94版本中,创建表是通过HBaseAdmin类,向Master发起一个异步的建表请求,然后不断的扫描meta表,直到从meta表中扫描到的表的region数目和预期的数据相同,即认为建表成功, 时序图如下:

流程:

1. 从HBaseAdmin发起 createTable请求到master[异步请求]

2. Master做完基本检查后,如果有MasterCoprocessor,就调用coprocessor的preCreateTable做前置检查

3. 检查通过后,Master生成CreateTableHandler, 提交给ExecuterService服务去执行

　　3.1. hdfs的 hbaseroot/.tmp目录上创建TableDescriptor

　　3.2. hdfs的hbaseroot/.tmp目录上创建region及相关文件

　　3.3. 把tmp目录中创建好的表文件拷贝到hbaseroot目录下

3.4. 新增region信息到META表

3.5. 触发所有region的assignment,随机分配到集群alive的regionserver上

3. 6. zk上修改表的状态为TableState.ENABLED

4. HBaseAdmin在第1步完成后, 会通过MetaScan不断的去meta表查看所创建表的region数目是不是和预期的相等,如果是,建表成功,如果经过了一定的重试次数后(默认10*10=100次),依然失败,则抛出TableNotEnabledException异常

存在的问题:

1. 如果一切顺利还好,但是如果任意一步出现问题,则很难定位和修复,比如:

　　1. 3.3成功后,master宕机, 3.4还没有执行, 那么定位后,可以通过hbase hbck -fixMeta 工具做修复

2. 如果3.4部分成功, 就没有很好的工具做修复, 这时候就需要人工介入,去做回滚操作,然后再重新建表

1.2.5

procedure v2是在hbase1.1版本引入的特性,主要是为了解决之前的方案中存在的问题, 比如,任务意外中断后,中间状态需要人工接入, 难以追溯任务状态等问题, 用户可以选择是否开启procedure特性,如果不开启,就还是使用类似0.94版本的Handler机制.

Procedure有以下核心组件:

其中, ProcedureExecuter负责procedure的编排和运行, procedureStore用于持久化procedure的状态

　　

Procedure 有以下状态:　　

每个Procedure都会经过这几个状态,每次状态的变化,都会通过ProcedureStore记录到WAL中

Procedure V2有以下几个核心接口类:

1. Procedure 代表一个任务的基础类, 主要包含两个接口方法:

　　a. execute

b. rollback

2. ProcedureStore 持久化Procedure状态的类, 机器宕机恢复后会通过ProcedureStore获取之前没有运行完的任务状态,并且继续执行

3. ProcedureExecutor 类似于ExecutorService, 用于执行procedure,同时也负责Procedure任务的恢复和rollback等操作, 复杂程度超过ExecutorService

使用Procedure v2的场景下,时序图如下:

通过Procedure V2,可以将一个任务拆分成多个子Procedure, 具体的实现方式是, 父任务的execute返回多个Procedure子任务,这个时候, 父任务的状态变成Waiting, 并继续完成子任务,当所有子任务都成功后, 父任务继续执行

根据这个特性, hbase实现了一个StateMachineProcedure, 基于状态机, CreateTableProcedure被分成了多个状态:

enum CreateTableState {
  CREATE_TABLE_PRE_OPERATION = 1;
  CREATE_TABLE_WRITE_FS_LAYOUT = 2;
  CREATE_TABLE_ADD_TO_META = 3;
  CREATE_TABLE_ASSIGN_REGIONS = 4;
  CREATE_TABLE_UPDATE_DESC_CACHE = 5;
  CREATE_TABLE_POST_OPERATION = 6;
}

初始化状态下, 状态为CREATE_TABLE_PRE_OPERATION, 状态变化逻辑在ExecuteFromState中实现:

@Override
  protected Flow executeFromState(final MasterProcedureEnv env, final CreateTableState state)
      throws InterruptedException {
    if (LOG.isTraceEnabled()) {
      LOG.trace(this + " execute state=" + state);
    }
    try {
      switch (state) {
        case CREATE_TABLE_PRE_OPERATION:
          // Verify if we can create the table
          boolean exists = !prepareCreate(env);
          ProcedurePrepareLatch.releaseLatch(syncLatch, this);

          if (exists) {
            assert isFailed() : "the delete should have an exception here";
            return Flow.NO_MORE_STATE;
          }

          preCreate(env);
          setNextState(CreateTableState.CREATE_TABLE_WRITE_FS_LAYOUT);
          break;
        case CREATE_TABLE_WRITE_FS_LAYOUT:
          newRegions = createFsLayout(env, hTableDescriptor, newRegions);
          setNextState(CreateTableState.CREATE_TABLE_ADD_TO_META);
          break;
        case CREATE_TABLE_ADD_TO_META:
          newRegions = addTableToMeta(env, hTableDescriptor, newRegions);
          setNextState(CreateTableState.CREATE_TABLE_ASSIGN_REGIONS);
          break;
        case CREATE_TABLE_ASSIGN_REGIONS:
          assignRegions(env, getTableName(), newRegions);
          setNextState(CreateTableState.CREATE_TABLE_UPDATE_DESC_CACHE);
          break;
        case CREATE_TABLE_UPDATE_DESC_CACHE:
          updateTableDescCache(env, getTableName());
          setNextState(CreateTableState.CREATE_TABLE_POST_OPERATION);
          break;
        case CREATE_TABLE_POST_OPERATION:
          postCreate(env);
          return Flow.NO_MORE_STATE;
        default:
          throw new UnsupportedOperationException("unhandled state=" + state);
      }
    } catch (HBaseException|IOException e) {
      LOG.error("Error trying to create table=" + getTableName() + " state=" + state, e);
      setFailure("master-create-table", e);
    }
    return Flow.HAS_MORE_STATE;
  }

如果CreateTable过程中,在某一个状态下运行失败需要回滚, ProcedureExecutor会负责追溯回滚procedure的父Procedure,直到全部回滚; 如果Procedure执行或者回滚过程中出现宕机,Master在启动的时候,会启动ProcedureExecutor,从WAL中恢复出之前Procedure的状态;

 ProcedureStore的实现

...未完待续