HBase Flush操作流程以及对读写服务的影响

  • Post author:
  • Post category:其他



HBase的Flush操作的触发条件:

1)Manual调用,HRegionInterface#flushRegion,可以被用户态org.apache.hadoop.hbase.client.HBaseAdmin调用flush操作实现,该操作会直接触发HRegion的internalFlush。

2)HRegionServer的一次更新操作,使得整个内存使用超过警戒线。警戒线是globalMemStoreLimit, RS_JVM_HEAPSIZE * conf.getFloat(“hbase.regionserver.global.memstore.upperLimit”),凡是超过这个值的情况,会直接触发FlushThread,从全局的HRegion中选择一个,将其MemStore刷入hdfs,从而保证rs全局的memstore容量在可控的范围。


RS上HRegion的选择算法:

步骤1:RS上的Region,按照其MemStore的容量进行排序。

步骤2:选出Region下的Store中的StoreFile的个数未达到hbase.hstore.blockingStoreFiles,并且MemStore使用最多的Region。— bestFlushableRegion

步骤3:选出Region下的MemStore使用最多的Region。— bestAnyRegion

步骤4:如果bestAnyRegion的memstore使用量超出了bestFlushableRegion的两倍,这从另外一个角度说明,虽然当前bestAnyRegion有超过blockingStoreFiles个数的文件,但是考虑到RS内存的压力,冒着被执行Compaction的风险,也选择这个Region,因为收益大。否则,直接使用bestFlushableRegion。

指定的Region写入hdfs的过程:

步骤1:获得updatesLock的写锁,阻塞所有对于该Region的更新操作。由此,可知Flush操作会阻塞Region区域内Row的更新操作(Put、Delete、Increment),因为在阻塞更新操作期间,涉及到Memstore的snapshot操作,如果不做限制,那么很可能一个put操作的多个KV,分别落在kvset和snapshot当中,从而与hbase保证row的原子性相悖。

步骤2:mvcc推进一次写操作事务。每个Region维护了一个mvcc对象(Multi Version

Consistency Control),用来控制读写操作的事务性。

步骤3:从HLog中获取一个新的newSeqNum,更新HLog的lastSeqWritten。由于此时该Region的更新操作会暂停,因此,会暂时删除lastSeqWritten记录的<RegionName,lastSeqNum>,写入<”snp”+RegionName, newSeqNum>到lastSeqWritten中。这里的lastSeqWritten是HLog用来存储每个Regiond到当前时刻最后一次提交操作的SeqNum。

步骤4:为Region下的每个Store的MemStore执行snapshot操作。



如上图所示,HRegion上Store的个数是由Table中ColumnFamily的个数确定,每个Store是由一个MemStore和数个StoreFile(HFile)文件组成,在正常的更新操作过程中,更新的内容会写入MemStore里的kvset结构中。HRegion执行Flush操作,实际上是把MemStore的内容全部刷入hdfs的过程。虽然,目前更新操作已经通过加写锁阻塞,可是读操作仍然可以继续,因此,在memstore执行snapshot的过程中,通过reference,snapshot会指向kvset,然后给kvset指向一个全新的内存区域。代码如下:



步骤5:释放updatesLock的写锁,此时该HRegion可以接收更新操作。

步骤6:更新mvcc读版本到当前写版本号。

这里有一个小插曲,在更新操作时,mvcc. completeMemstoreInsert 的操作在updatesLock的范围之外,这样在多线程高并发情况下,就存在已经写入MemStore的kvset当中,但是事务还未完成提交的情况。该场景相关代码如下:



从4358行,我们可以清晰看到,通过updatesLock保证了更新操作写入了MemStore的kvset,但假定Flush线程在其它更新线程4363行之后,获得了updatesLock写锁,并执行了snapshot操作。那么,这里的mvcc就会出现读写的事务号不一致的情况,因此,在Region的Flush线程就需要使用waitForRead(w),等待更新到目前写版本号。

步骤7:将Store内的snapshot写成一个StoreFile临时文件。

步骤8:重命名storefile文件,更新Store里文件和Memstore状态。

在步骤8完成之前,整个Hregion的读请求,是和之前没有影响的。因为在读请求过程中,StoreScanner对于kvset和snapshot进行进行同步读取,即使kvset切换成snapshot,scan的操作仍然可以继续,这部分的内容是由MemStoreScanner来控制。

在读过程中,Store里的scanner有两部份,一个是StoreFileScanner,另外一个是MemStoreScanner,它们都继承了KeyValueScanner接口,并通过StoreScanner中的KeyValueHeap封装起来。于此类似,在RegionScannerImpl也是通过一个KeyValueHeap把每个Store的StoreScanner封装起来,从而直接提供对外的服务。

读到这里,可能细心的工程师们,就会有一个疑问:Flush操作对于读的影响究竟有没有呢?

有影响,但比较小。在步骤8以前那些阶段,MemStoreScanner做到了对于kvset与snapshot的自由切换。



如上所示,如果kvset被重置,那么theNext将不再等于kvsetNextRow,从而切换成开始从snapshot迭代器中获取数据。

因此,在步骤1~7之间,对于读服务影响不大。但是在步骤8操作最后一步时,需要把生成storefile更新到可用的Store中的StoreFile列表,并清除snapshot的内容。

于是,此时ChangedReaderOberver就开始起作用了。

// Tell listeners of the change in readers.

notifyChangedReadersObservers();



这里最为关键的是,将storescanner用来封装全部StoreFileScanner和MemStoreScanner的heap清空,它会触犯的作用是在执行next()操作时,会触发resetScannerStack操作,会重新加载Store下的所有Scanner,并执行seek到最后一次更新的key。这个过程会使得flush操作对于某些next操作变得突然顿一下。