HBase篇(4)-你不知道的HFile

【每日五分钟搞定大数据】系列,HBase第四篇

这一篇你可以知道,

HFile的内部结构

HBase读文件细粒度的过程

HBase随机读写快除了MemStore之外的原因

上一篇中提到了Hbase的数据以HFile的形式存在HDFS, 物理存储路径是:

这一篇我们来说下这个HFile,把路径从HFile开始再补充一下

顺便科普一下,HFile具体存储路径为:

如何读取HFile的内容:

这是我做的一个思维导图,这里面的内容就是我这章要讲的东西,有点多,大家慢慢消化。

HFile的逻辑分类

Scanned block section:扫描HFile时这个部分里面的所有block都会被读取到。

Non-scanned block section:和相面的相反,扫描HFile时不会被读取到。

Load-on-open-section:regionServer启动时就会加载这个部分的数据,不过不是最先加载。

Trailer:这个部分才是最先加载到内存的,记录了各种偏移量和版本信息。

HFile的物理分类

物理分类和逻辑分类对应的关系,可以在上面的图中看到

HFile有多个大小相等的block组成,Block分为四种类型:Data Block,Index Block,Bloom Block和Meta Block。

Data Block 用于存储实际数据,通常情况下每个Data Block可以存放多条KeyValue数据对;

Index Block和Bloom Block 都用于优化随机读的查找路径,其中Index Block通过存储索引数据加快数据查找,而Bloom Block通过一定算法可以过滤掉部分一定不存在待查KeyValue的数据文件,减少不必要的IO操作;

Meta Block 主要存储整个HFile的元数据。

Data Block

保存了实际的数据,由多个KeyValue 组成,块大小默认为64K(由建表时创建cf时指定或者HColumnDescriptor.setBlockSize(size)),在查询数据时,以block为单位加载数据到内存。

KeyValue 的结构

key 由这些内容组成:rowkey长度、rowkeyColumnFamily的长度、ColumnFamily、ColumnQualifier、KeyType(put、Delete、 DeleteColumn和DeleteFamily)

key length 固定长度的数值

value 二进制数据

value length 固定长度的数值

Index Block

data block index(Root Index Block ) Data Block第一层索引

Intermediate Level Data Index Block Data Block第二层索引

Leaf Index Block Data Block第三层索引

这三层索引我举个栗子放在一起说,第一层是必须要的,也是最快的,因为它会被加载到内存中。二三根据数据量决定,如果有的话在找的时候也会加载到内存。实际上就是一步步的缩小范围,类似B+树的结构:

假设要搜索的rowkey为bb,root index block(常驻内存)中有三个索引a,g,l,b在a和g之间,因此会去找索引 a 指向的二层索引

将索引 a 指向的中间节点索引块加载到内存,然后通过二分查找定位到 b 在 index a 和 c 之间,接下来访问索引 a 指向的叶子节点。

将索引 a 指向的中间节点索引块加载到内存,通过二分查找定位找到 b 在 index a 和 b 之间,最后需要访问索引b指向的数据块节点。

将索引 b 指向的数据块加载到内存,通过遍历的方式找到对应的 keyvalue 。

上面的流程一共IO了三次,HBase提供了一个BlockCache,是用在第4步缓存数据块,可以有一定概率免去随后一次IO。

相关配置:

Meta Block (可选的)

保存用户自定义的kv对,可以被压缩。比如booleam filter就是存在元数据块中的,该块只保留value值,key值保存在元数据索引块中。每一个元数据块由块头和value值组成。可以快速判断key是都在这个HFile中。

meta block index (可选的)

Meta Block的索引。

File Info ,Hfile的元信息

不被压缩,用户也可以在这一部分添加自己的元信息。

Trailer (记录起始位置)

记录了HFile的基本信息、偏移值和寻址信息Trailer Block

version 最先加载到内存的部分,根据version确定Trailer长度,再加载整个Trailer block

LoadOnOpenDataOffset load-on-open区的偏移量(便于将其加载到内存)

FirstDataBlockOffset:HFile中第一个Block的偏移量

LastDataBlockOffset:HFile中最后一个Block的偏移量

numEntries:HFile中kv总数

另外:Bloom filter相关的Block我准备专门写一篇文章,因为Bloom filter这个东西在分布式系统中非常常见而且有用,现在需要知道的是它是用来快速判断你需要查找的rowKey是否存在于HFile中(一堆的rowKey中)

重点来了!

看完上面的内容我们就可以解决文章开始提出的问题了:

HBase读文件细粒度的过程?

HBase随机读写快除了MemStore之外的原因?

这两个问题我一起回答。

0.这里从找到对应的Region开始说起,前面的过程可以看上一篇文章。

1.首先用MemStoreScanner搜索MemStore里是否有所查的rowKey(这一步在内存中,很快),

2.同时也会用Bloom Block通过一定算法过滤掉大部分一定不包含所查rowKey的HFile,

3.上面提到在RegionServer启动的时候就会把Trailer,和Load-on-open-section里的block先后加载到内存,

所以接下来会查Trailer,因为它记录了每个HFile的偏移量,可以快速排除掉剩下的部分HFile。

4.经过上面两步,剩下的就是很少一部分的HFile了,就需要根据Index Block索引数据(这部分的Block已经在内存)快速查找rowkey所在的block的位置;

5.找到block的位置后,检查这个block是否在blockCache中,在则直接去取,如果不在的话把这个block加载到blockCache进行缓存,

当下一次再定位到这个Block的时候就不需要再进行一次IO将整个block读取到内存中。

6.最后扫描这些读到内存中的Block(可能有多个,因为有多版本),找到对应rowKey返回需要的版本。

另外,关于blockCache很多人都理解错了,这里要注意的是:

blockCache并没有省去扫描定位block这一步,只是省去了最后将Block加载到内存的这一步而已。

这里又引出一个问题,如果BlockCache中有需要查找的rowKey,但是版本不是最新的,那会不会读到脏数据?

HBase是多版本共存的,有多个版本的rowKey那说明这个rowKey会存在多个Block中,其中一个已经在BlockCache中,则省去了一次IO,但是其他Block的IO是无法省去的,它们也需要加载到BlockCache,然后多版本合并,获得需要的版本返回。解决多版本的问题,也是rowKey需要先定位Block然后才去读BlockCache的原因。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181108G23JB600?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券