【每日五分钟搞定大数据】系列，HBase第四篇 这一篇你可以知道， HFile的内部结构？ HBase读文件细粒度的过程？ HBase随机读写快除了MemStore之外的原因？ 上一篇中提到了Hbase的数据以HFile的形式存在HDFS， 物理存储路径是： NameSpace->Table->Region->CF->HFile 这一篇我们来说下这个HFile，把路径从HFile开始再补充一下 HFile->Block->KeyValue. 顺便科普一下，HFile具体存储路径为： /hbase/data///// 如何读取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 假设要搜索的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。 相关配置： 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的原因。https://www.cnblogs.com/uncledata/p/9927235.html