hbase1.3版本启动流程及优化

由于线上集群有上千台机器,启动时间在30分钟左右,需要对启动流程进行优化,

阅读了hbase启动相关的源码,

首先,hbase启动分为需要三个组件,hmaster和regionserver,zookeeper

hmaster:在启动过程中主要负责region分配给那个regionserver,

regionserver:会将regionserver分配过的的region初始化到能够提供服务的状态

zookeeper:在启动的过程中保存启动过程中的中间状态,

一个region打开的状态变换如下图所示:

 

整体的流程为:hmaster先从hdfs中读取hbase/meta数据,hbase/meta是一张系统表,记录了所有的region信息的所有信息,打开meta region的过程即如上图所示,

在load所有的meta数据,获取到所有的region信息之后,按照上边同样的方法,对每一个region执行上边的操作,regionServer收到hmaster分配的region之后执行启动操作,最终执行完成之后,将完成的信息写入zookeeper,master监听对应的zookeeper信息,收到事件之后,将region的状态标记为open,并计入meta表中,当所有的region都完成open,或者failed_open之后,master算是启动完成;

region的所有状态:

整个启动过程实际上是一个非常复杂的过程,涉及到很多准备工作,由于已经能定为到以上这个过程是最慢的,所以着重看了这部分的流程;

关于优化:在网上找到了360关于优化hbase0.8x版本的文档,

其中提到了:

1.region是串行分配,修改为并行分配

2.regionServer打开region的过程中rpc请求namenode 4次,优化到1次 (还未验证1.3版本如何做的)

3.meta表更新操作修改为并行

4.操作zk的过程是串行的

对于上边这些方法,1和3通过阅读源码已经放在了1.3版本中

在验证的过程中,做了一下记录,当region数增加的时候Joined the cluster时间的变化,这个数据是在一个hmaster和一个regionserver的情况下做的测试:

另外查看了hbase在hadoop的数据

meta在hbase中所占的存储,140条,332.4k,每条2.4k左右,40w条接近1G数据,

可想而知,当region条数变多时,这样量级的数据要load到内存中,再处理这样多的数据,一定是个比较漫长的过程

改进方案:

目前还未验证的方法:

1.修改参数hbase.assignment.usezk,在分配region的过程中不使用zk;

2.修改hbase.assignment.threads.max,默认30,增加这里的线程数目;

3.查看regionserver收到消息启动时的流程是否有优化空间;

还有个没想明白的点:

如果regionserver没有启动完成的情况,hmaster启动需要分配,在分配的过程中,新的regionserver启动,这个过程region是怎么进行分配的;还需要进行验证;

如果新加入regionserver会导致重新的rebalance,那么我们将regionserver都启动之后再启动hmaster,就不会触发reblance的操作,不过这个目前只是猜测,还没有验证;