HBase region的split

转自：https://www.aliyun.com/jiaocheng/811424.html

可以这样理解region和hbase的架构: 1、Table在行的方向上分割为多个Region; 2、Region按大小分割的,每个表开始只有一个region,随着数据增多,region不断增大,当增大到一个阀值的时候,region就会等分会两个新的region,之后会有越来越多的region; 3、Region是Hbase中分布式存储和负载均衡的最小单元,不同Region分布到不同RegionServer上。

 

 

深入到region的内部,我们可以看到这样的region的解剖图。

 

 

region内部分成多个store。每个store负责管理和存储一个column family的数据。也就是说,一张表有多少个column family,一个region内部会生成多少个store与之对应。一个store里会有一个memstore和n个storefile。其中memstore是在regionserver的内存中。而storefile会保存持久化的保存在HDFS上。

 

region的设计让我想起了level db的设计。事实上region在实现过程中也在很大程度上参考了bit table的tablet的设计,也就是level db的设计。

 

memstore带来了两个好处:

 

1 所有的写入操作只写入wal日志文件和memstore中。wal日志文件是追加写, 而且磁盘的顺序IO速度很快, 因此写操作是极快完成的。

 

2 数据有了一个高速缓存。部分读请求可以直接命中缓存而省去了读磁盘之苦。

 

wal日志文件,hbase中的叫法是HLog,也是放在HDFS中。因为HDFS这一层的存在,使得一个数据库服务的high available的问题变得简单了。如果一个region server发生了故障,那么它所管理的memstore肯定就丢失了。但由于wal日志文件的存在,接管的region server可以轻易的将原来的region接管过来。它只需要找到wal日志文件中还没有落地成HFile的部分,重放请求并写入memstore就可以了。

 

如果数据不断的写入同一个region,会发生什么事?

 

首先随着数据的写入, memstore肯定是不够用了,需要flush到磁盘上形成Hfile。

 

随着HFile越来越多,可能触发compact过程。将多个HFile合并成一个HFile。

 

然后数据越来越多,HFile也越来越大。虽然HFile当中有索引,但索引的查询也是需要时间的。

 

另外大量的读写请求会汇聚到同一台region server上,服务器也会越来越繁忙。当达到它性能的极限后。。。天知道会发生些什么。

 

因此,当一个region过大之后,是需要进行split的。split的目的,是将一个region尽可能均匀的分成两个region。因为所有的HFile数据文件都是不可修改的, 所以新创建的子region不会重写数据到新文件中。在子region中,首先会使用的是父region的数据文件的reference。当子region逐渐通过compact,不再使用父region的数据文件的reference,就可以清理掉这些reference和父region的文件。

 

split的过程,由单个region的region server所发起。整个过程牵涉很多服务,zookeeper/master都会涉及到。region server需要在split开始前和结束后通知master, 更新meta表使client可以发现新的子region, 此外还需更新hdfs中的目录和文件。为了在错误发生时回滚, region server在内存中保存着split的执行journal。

 

当split发生时有这些步骤:

 

1 region server发起split。它会在zookeeper上创建一个节点,名称叫做/hbase/region-in-transition/region-name。状态为splitting。

 

2 因为master会监听/hbase/region-in-transition目录,所以它会得知split的发生。

 

3 region server在父region的hdfs目录下,创建一个叫做.splits的子目录。

 

4 region server在服务内部将父region关闭,并flush memstore。region在本地数据结构中的状态标记为offline也就是离线。此时,所有客户端访问父region的请求都会失败,并抛出NotServingRegionException异常。客户端会在等待一定时间后重试这个请求。

 

5 region server在.splits目录下创建子region的目录以及必要的数据结构。对于一个store file会创建两个reference file,并将reference file指向父region的文件。

 

6 region server创建真正的region目录,并移动这些reference文件。

 

7 region server 发送一个PUT请求到meta表,请求将父region在META中的状态设置成offline,并增加子region的信息。注意,此时并没有在meta表中增加子region的行,而只是修改父region的信息。在这时,客户端请求读、写父region的数据,都依然是返回出错。如果此时region server挂掉,那么接手它工作的region server依然能将split的工作做完。

 

8 region server同时打开两个子region接受请求。

 

9 region server将两个子region的加入到meta表中。此时,客户端会发现新的region,并可以向新的region发送请求。如果客户端本地有缓存meta表信息,缓存会失效。

 

10 region server将zookeeper上的/hbase/region-in-transition/region-name的状态改成split。master可以感知到split的完成。在迟些时候,balancer可以将子region分配到其他的region server。

 

11 split已经完成。但还有些垃圾需要清理。meta和hdfs中还保存着父region的reference。子region在compact之后会删除父region的reference。而master的垃圾回收任务,会定期检查region是否还在使用reference, 如果不再使用就会全部删除父region的数据文件。

 

在使用HBase的过程中,我曾经遇到过一个问题。在压力测试写一张hbase的表的过程中,出现了一张表一直不能结束split过程,而一直处在splitting的状态。而客户端也一直抛出NotServerRegionException异常。

 

查询了一下对应的region server的日志发现,一直打印这样的错误,非常频繁,一秒钟之内有几百上千次。

 

hbase-gdata-regionserver-tdmtest2.log

 

2017-02-18 15:16:53,542 WARN [B.DefaultRpcServer.handler=29,queue=2,port=60020] regionserver.HRegion: Failed getting lock in batch put, row=3eb3b773-5fac-4638-86d1-930d68604ae3 org.apache.hadoop.hbase.regionserver.WrongRegionException: Requested row out of range for row lock on HRegion login_event_20170217,8024051d-360b-4877-a9b9-ebef10810e65,1487322174053.c9be23e25c28188f0af105e9a79593ec., startKey='8024051d-360b-4877-a9b9-ebef10810e65', getEndKey()='', row='3eb3b773-5fac-4638-86d1-930d68604ae3'at org.apache.hadoop.hbase.regionserver.HRegion.checkRow(HRegion.java:3636)at org.apache.hadoop.hbase.regionserver.HRegion.getRowLockInternal(HRegion.java:3667)at org.apache.hadoop.hbase.regionserver.HRegion.doMiniBatchMutation(HRegion.java:2430)at org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2297)at org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2252)at org.apache.hadoop.hbase.regionserver.HRegion.batchMutate(HRegion.java:2256)at org.apache.hadoop.hbase.regionserver.HRegionServer.doBatchOp(HRegionServer.java:4538)at org.apache.hadoop.hbase.regionserver.HRegionServer.doNonAtomicRegionMutation(HRegionServer.java:3718)at org.apache.hadoop.hbase.regionserver.HRegionServer.multi(HRegionServer.java:3607)at org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:30954)at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2093)at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:101)at org.apache.hadoop.hbase.ipc.RpcExecutor.consumerLoop(RpcExecutor.java:130)at org.apache.hadoop.hbase.ipc.RpcExecutor$1.run(RpcExecutor.java:107)at java.lang.Thread.run(Thread.java:745)

 

通过仔细分析上面的步骤可以发现,这个region server的错误发生在第四步之后和第八步之前。因为客户端还没找到新的region,而且在对应的meta表里也没有发现新的region。因此我采取了重启对应region server的方式进行处理。因为此时如果错误发生在第7步之前,接手的region server不知道split的发生,依然可以正常处理请求。而错误发生在第7步之后,region server会完成split的过程。

 

重启region server的过程需要注意,千万不能使用 stop-hbase.sh进行关闭,因为这样会关闭整个集群。

 

而需要在对应的region server上用 bin/graceful_stop.sh regionservername的方式进行关闭。使用bin/hbase-daemon.sh start regionserver。启动之后,故障排除,region split完成。集群恢复了服务。