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

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

这一篇你可以知道，

HFile的内部结构？

HBase读文件细粒度的过程？

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

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

NameSpace->Table->Region->CF->HFile

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

HFile->Block->KeyValue.

顺便科普一下，HFile具体存储路径为：

/hbase/data/<nameSpace>/<tableName>/<encoded-regionname>/<column-family>/<filename>

如何读取HFile的内容：

hbase org.apache.hadoop.hbase.io.hfile.HFile -f  /上面的路径指定某个HFile   -p

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

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+树的结构：

a，b，c，d，e
f，g，h，i，j
k，l，m，n，o

Root Index Block 第一层：a，g，l
Intermediate Level Data Index Block 第二层：a，c，e  ||  f，h，j  ||  k ，m，o
Leaf Index Block 第三层（部分）：a，b  || c，d  || e，f

1. 假设要搜索的rowkey为bb，root index block（常驻内存）中有三个索引a，g，l，b在a和g之间，因此会去找索引 a 指向的二层索引
2. 将索引 a 指向的中间节点索引块加载到内存，然后通过二分查找定位到 b 在 index a 和 c 之间，接下来访问索引 a 指向的叶子节点。
3. 将索引 a 指向的中间节点索引块加载到内存，通过二分查找定位找到 b 在 index a 和 b 之间，最后需要访问索引b指向的数据块节点。
4. 将索引 b 指向的数据块加载到内存，通过遍历的方式找到对应的 keyvalue 。

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

相关配置：

hfile.data.block.size（默认64K）:同样的数据量，数据块越小，数据块越多，索引块相应的也就越多，索引层级就越深

hfile.index.block.max.size(默认128K)：控制索引块的大小，索引块越小，需要的索引块越多，索引的层级越深

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的原因。