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版本引入的特性,主要是为了解决之前的方案中存在的问题, 比如,任务意外中断后,中间状态需要人工接入, 难以追溯任务状态等问题:

...未完待续

HBase ProcedureV2 分析