您现在的位置:诗歌范文 > 西方文学 > 正文

深入HBase架构解析(一)

	深入HBase架构解析(一)

虽然上面这张图展现的是最新的HRegionServer的架构(但是并不是那么的精确),但是我一直比较喜欢看以下这张图,即使它展现的应该是以前的架构。

HRegionServer中数据写流程图解当客户端发起一个Put请求时,首先它从hbase:meta表中查出该Put数据最终需要去的HRegionServer。

然后客户端将Put请求发送给相应的HRegionServer,在HRegionServer中它首先会将该Put操作写入WAL日志文件中(Flush到磁盘中)。 写完WAL日志文件后,HRegionServer根据Put中的TableName和RowKey找到对应的HRegion,并根据ColumnFamily找到对应的HStore,并将Put写入到该HStore的MemStore中。 此时写成功,并返回通知客户端。

MemStoreFlushMemStore是一个InMemorySortedBuffer,在每个HStore中都有一个MemStore,即它是一个HRegion的一个ColumnFamily对应一个实例。

它的排列顺序以RowKey、ColumnFamily、Column的顺序以及Timestamp的倒序,如下所示:每一次Put/Delete请求都是先写入到MemStore中,当MemStore满后会Flush成一个新的StoreFile(底层实现是HFile),即一个HStore(ColumnFamily)可以有0个或多个StoreFile(HFile)。 有以下三种情况可以触发MemStore的Flush动作,需要注意的是MemStore的最小Flush单元是HRegion而不是单个MemStore。

据说这是ColumnFamily有个数限制的其中一个原因,估计是因为太多的ColumnFamily一起Flush会引起性能问题?具体原因有待考证。 在MemStoreFlush过程中,还会在尾部追加一些meta数据,其中就包括Flush时最大的WALsequence值,以告诉HBase这个StoreFile写入的最新数据的序列,那么在Recover时就直到从哪里开始。

在HRegion启动时,这个sequence会被读取,并取最大的作为下一次更新时的起始sequence。 HFile格式HBase的数据以KeyValue(Cell)的形式顺序的存储在HFile中,在MemStore的Flush过程中生成HFile,由于MemStore中存储的Cell遵循相同的排列顺序,因而Flush过程是顺序写,我们直到磁盘的顺序写性能很高,因为不需要不停的移动磁盘指针。 HFile参考BigTable的SSTable和Hadoop的实现,从HBase开始到现在,HFile经历了三个版本,其中V2在引入,V3在引入。

首先我们来看一下V1的格式:V1的HFile由多个DataBlock、MetaBlock、FileInfo、DataIndex、MetaIndex、Trailer组成,其中DataBlock是HBase的最小存储单元,在前文中提到的BlockCache就是基于DataBlock的缓存的。 一个DataBlock由一个魔数和一系列的KeyValue(Cell)组成,魔数是一个随机的数字,用于表示这是一个DataBlock类型,以快速监测这个DataBlock的格式,防止数据的破坏。 DataBlock的大小可以在创建ColumnFamily时设置(()),默认值是64KB,大号的Block有利于顺序Scan,小号Block利于随机查询,因而需要权衡。

Meta块是可选的,FileInfo是固定长度的块,它纪录了文件的一些Meta信息,例如:AVG_KEY_LEN,AVG_VALUE_LEN,LAST_KEY,COMPARATOR,MAX_SEQ_ID_KEY等。

DataIndex和MetaIndex纪录了每个Data块和Meta块的其实点、未压缩时大小、Key(起始RowKey?)等。

Trailer纪录了FileInfo、DataIndex、MetaIndex块的起始位置,DataIndex和MetaIndex索引的数量等。

其中FileInfo和Trailer是固定长度的。

HFile里面的每个KeyValue对就是一个简单的byte数组。

但是这个byte数组里面包含了很多项,并且有固定的结构。

我们来看看里面的具体结构:开始是两个固定长度的数值,分别表示Key的长度和Value的长度。

紧接着是Key,开始是固定长度的数值,表示RowKey的长度,紧接着是RowKey,然后是固定长度的数值,表示Family的长度,然后是Family,接着是Qualifier,然后是两个固定长度的数值,表示TimeStamp和KeyType(Put/Delete)。 Value部分没有这么复杂的结构,就是纯粹的二进制数据了。

随着HFile版本迁移,KeyValue(Cell)的格式并未发生太多变化,只是在V3版本,尾部添加了一个可选的Tag数组。 HFileV1版本的在实际使用过程中发现它占用内存多,并且BloomFile和BlockIndex会变的很大,而引起启动时间变长。

其中每个HFile的BloomFilter可以增长到100MB,这在查询时会引起性能问题,因为每次查询时需要加载并查询BloomFilter,100MB的BloomFiler会引起很大的延迟;另一个,BlockIndex在一个HRegionServer可能会增长到总共6GB,HRegionServer在启动时需要先加载所有这些BlockIndex,因而增加了启动时间。

为了解决这些问题,在版本中引入HFileV2版本:在这个版本中,BlockIndex和BloomFilter添加到了DataBlock中间,而这种设计同时也减少了写的内存使用量;另外,为了提升启动速度,在这个版本中还引入了延迟读的功能,即在HFile真正被使用时才对其进行解析。

FileV3版本基本和V2版本相比,并没有太大的改变,它在KeyValue(Cell)层面上添加了Tag数组的支持;并在FileInfo结构中添加了和Tag相关的两个字段。

关于具体HFile格式演化介绍,可以参考。

对HFileV2格式具体分析,它是一个多层的类B+树索引,采用这种设计,可以实现查找不需要读取整个文件:DataBlock中的Cell都是升序排列,每个block都有它自己的Leaf-Index,每个Block的最后一个Key被放入Intermediate-Index中,Root-Index指向Intermediate-Index。 在HFile的末尾还有BloomFilter用于快速定位那么没有在某个DataBlock中的Row;TimeRange信息用于给那些使用时间查询的参考。 在HFile打开时,这些索引信息都被加载并保存在内存中,以增加以后的读取性能。 这篇就先写到这里,未完待续。

。 。

。

参考:https:///blog/in-depth-look-hbase-architecture#.VdNSN6Yp3qxhttp:///wiki/=Understanding_Hbase_and_BigTablehttp:///:///2011/01/:///archive/:44阅读(55993)所属分类:、。

上一篇: SVM入门(八)松弛变量
下一篇:没有了
回到顶部