Hfile结构
文件主要分为四个部分：Scanned block section，Non-scanned block section，Opening-time data section和Trailer。
- Scanned block section：顾名思义，表示顺序扫描HFile时所有的数据块将会被读取，包括Leaf Index Block和Bloom Block。
- Non-scanned block section：表示在HFile顺序扫描的时候数据不会被读取，主要包括Meta Block和Intermediate Level Data Index Blocks两部分。
- Load-on-open-section：这部分数据在HBase的region server启动时，需要加载到内存中。包括FileInfo、Bloom filter block、data block index和meta block index。
- Trailer：这部分主要记录了HFile的基本信息、各个部分的偏移值和寻址信息。
分层索引
无论是Data Block Index还是Bloom Filter，都采用了分层索引的设计。
Data Block的索引，在HFile V2中做多可支持三层索引：最底层的Data Block Index称之为Leaf Index Block，可直接索引到Data Block；中间层称之为Intermediate Index Block，最上层称之为Root Data Index，Root Data index存放在一个称之为”Load-on-open Section“区域，Region Open时会被加载到内存中。基本的索引逻辑为：由Root Data Index索引到Intermediate Block Index，再由Intermediate Block Index索引到Leaf Index Block，最后由Leaf Index Block查找到对应的Data Block。在实际场景中，Intermediate Block Index基本上不会存在，文末部分会通过详细的计算阐述它基本不存在的原因，因此，索引逻辑被简化为：由Root Data Index直接索引到Leaf Index Block，再由Leaf Index Block查找到的对应的Data Block。
交叉存放
在”Scanned Block Section“区域，Data Block(存放用户数据KeyValue)、存放Data Block索引的Leaf Index Block(存放Data Block的索引)与Bloom Block(Bloom Filter数据)交叉存在。
按需读取
无论是Data Block的索引数据，还是Bloom Filter数据，都被拆成了多个Block，基于这样的设计，无论是索引数据，还是Bloom Filter，都可以按需读取，避免在Region Open阶段或读取阶段一次读入大量的数据，有效降低时延。
我们先假设没有Bloom Filter数据。当MemStore中所有的KeyValues全部写完以后，HFile Writer开始在close方法中处理最后的”收尾”工作：
- 写入最后一个Data Block。
- 写入最后一个Leaf Index Block。如上属于Scanned Block Section部分的”收尾”工作。
- 如果有MetaData则写入位于Non-Scanned Block Section区域的Meta Blocks，事实上这部分为空。
- 写Root Block Index Chunk部分数据：如果Root Block Index Chunk超出了预设大小，则输出位于Non-Scanned Block Section区域的Intermediate Index Block数据，以及生成并输出Root Index Block(记录Intermediate Index Block索引)到Load-On-Open Section部分。如果未超出大小，则直接输出为Load-On-Open Section部分的Root Index Block。
- 写入用来索引Meta Blocks的Meta Index数据（事实上这部分只是写入一个空的Block）。
- 写入FileInfo信息，FileInfo中包含：Max SequenceID, MajorCompaction标记，TimeRanage信息，最早的Timestamp, Data BlockEncoding类型，BloomFilter配置，最大的Timestamp，KeyValue版本，最后一个RowKey，平均的Key长度，平均Value长度，Key比较器等。
- 写入Bloom Filter元数据与索引数据。注：前面每一部分信息的写入，都以Block形式写入，都包含Header与Data两部分，Header中的结构也是相同的，只是都有不同的Block Type，在Data部分，每一种类型的Block可以有自己的定义。
- 写入Trailer部分信息， Trailer中包含：Root Index Block的Offset，FileInfo部分Offset，Data Block Index的层级，Data Block Index数据总大小，第一个Data Block的Offset，最后一个Data Block的Offset，Comparator信息，Root Index Block的Entries数量，加密算法类型，Meta Index Block的Entries数量，整个HFile文件未压缩大小，整个HFile中所包含的KeyValue总个数，压缩算法类型等。
至此，一个完整的HFile已生成。我们可以通过下图再简单回顾一下Root Index Block、Leaf Index Block、Data Block所处的位置以及索引关系：
Bloom Filter包含Bloom元数据(Hash函数类型，Hash函数个数等)与位图数据(BloomData)，为了避免每一次读取时加载所有的Bloom Data，HFile V2中将BloomData部分分成了多个小的Bloom Block。BloomData数据也被当成一类Inline Block，与Data Block、Leaf Index Block交叉存在，而关于Bloom Filter的元数据与多个Bloom Block的索引信息，被存放在Load-On-Open Section部分。但需要注意的是，在FileInfo部分，保存了关于BloomFilter配置类型信息，共包含三种类型：不启用，基于Row构建BloomFilter，基于Row+Column构建Bloom Filter。混合了BloomFilter Block以后的HFile构成如下图所示：
为啥这么快
再来看hbase如何在hdfs上去检索一行数据。首先要只要hbase的检索都是以rowkey值或者rowkey值范围来检索数据的，现在root表中检索mata表的的hregion位置，root表只会有一个region而且永远不会
被拆分以保证能够一次获取到mata表的hregion的位置，在mata表中保存所有的用户表的region的信息，region的rowkey有该region对应的表和第一行的rowkey等组成，因为一个表的rowkey在所有的
region上都是有序的字典排序，所有要检索一个rowkey只要通过对比mata表中region的rowkey就可以知道包含改rowkey的数据在那个region上，meta中还包含了region所咋的hregionserver的信息，通过
mata中的region的信息可以直接定位到包含改rowkey数据的所在的region在哪台hregionserver上。
知道region在哪台hregionserver上对已快速定位rowkey的数据还是不够的，region会根据families把数据才分成store，一个store只能包含一个family，在保存到hdfs的时候store其实就是一个目录而已，真正存数据的是filestroe也就是hfile，每一个hfile当达到一定大小的时候就会拆分成两个hfile所以一个store目录中会包含多个hfile。
因为table是按照rowkey来划分region的，region默认的大小为256M，通常会设置得更高1G,2G,4G等，所以hfile不可能比region的的值要大。但是hfile有可能还是很大，在hdfs上会拆分成不同的block放在不同的datanode上，这样子仍然无法做到精确定位。
hfile 继续划分，有data block，block index，trailler等组成，已经定位到rowkey所在的hfile时，会先读取hfile的trailer的信息以获取block index的位置，block index的key就是data block中的第一个rowkey，所以通过block index 的key就能精确的定位到要检索的rowkey在那个data block上，然后直接将该data block读取到内存，需要注意的是这里的data block已经很小了（默认是64k，不同于hdfs上的block默认为64M，hbase的hfile中的block要小的多）这样子足以读取该block到内存中，将该block进行遍历就能获取到需要的rowkey取出数据，以为这里的block只有64k这样的遍历非常迅速。这就是为什么hfile的data block要设置的如此之小的原因。
