HBase高性能随机查询之道 – HFile原理解析

在各色数据库系统百花齐放的今天，能让大家铭记的，往往是一个数据库所能带给大家的差异化能力。正如梁宁老师的产品思维课程中所讲到的，这是一个数据库系统所能带给产品使用者的"确定性"。

差异化能力通常需要从数据库底层开始构筑，而数据存储方式显得至关重要，因为它直接关乎数据写入与读取的效率。在一个系统中，这两方面的能力需要进行很好的权衡：如果设计有利于数据的快速写入，可能意味着查询时需要需要花费较大的精力去组织数据，反之，如果写入时花费精力去更好的组织数据，查询就会变的非常轻松。

探讨数据库的数据存储方式，其实就是探讨数据如何在磁盘上进行有效的组织。因为我们通常以如何高效读取和消费数据为目的，而不是数据存储本身。在RDBMS领域，因为键与数据的组织方式的区别，有两种表组织结构最为常见，一种是键与数据联合存储的索引组织表结构，在这种表结构下，查到键值意味着查找到数据;另外一种是键与数据分离存储的堆表结构。在这种表结构下，查找到键以后，只是拿到了数据记录的物理地址，还需要基于该物理地址去查找具体的数据记录。在大数据分析领域，有几种通用的文件格式，如Parquet, RCFile, ORCFile，CarbonData等等，这些文件大多基于列式的设计结构，来加速通用的分析型查询。但在实时数据库领域，却以各种私有的文件格式最为常见，如Bigtable的SSTable，HBase的HFile，Kudu的DiskRowSets，Cassandra的变种SSTable，MongoDB支持的每一种Storage Engine都是私有的文件格式设计，等等。

本文将详细探讨HBase的HFile设计，第一部分为HFile原理概述，第二部分介绍了一个HFile从无到有的生成过程，最后部分列出了几点与HFile有关的附加信息。

HFile原理概述

最初的HFile格式(HFile V1)，参考了Bigtable的SSTable以及Hadoop的TFile(HADOOP-3315)。如下图所示：

HFile在生成之前，数据在内存中已经是按序组织的。存放用户数据的KeyValue，被存储在一个个默认为64kb大小的Data Block中，在Data Index部分存储了每一个Data Block的索引信息{Offset，Size，FirstKey}，而Data Index的索引信息{Data Index Offset, Data Block Count}被存储在HFile的Trailer部分。除此以外，在Meta Block部分还存储了Bloom Filter的数据。下图更直观的表达出了HFile V1中的数据组织结构：

这种设计简单、直观。但用过0.90或更老版本的同学，对于这个HFile版本所存在的问题应该深有痛楚：Region Open的时候，需要加载所有的Data Block Index数据，另外，第一次读取时需要加载所有的Bloom Filter数据到内存中。一个HFile中的Bloom Filter的数据大小可达百MB级别，一个RegionServer启动时可能需要加载数GB的Data Block Index数据。这在一个大数据量的集群中，几乎无法忍受。

Data Block Index究竟有多大?

一个Data Block在Data Block Index中的索引信息包含{Offset, Size, FirstKey}，BlockOffset使用Long型数字表示，Size使用Int表示即可。假设用户数据RowKey的长度为50bytes，那么，一个64KB的Data Block在Data Block Index中的一条索引数据大小约为62字节。

假设一个RegionServer中有500个Region，每一个Region的数量为10GB(假设这是Data Blocks的总大小)，在这个RegionServer上，约有81920000个Data Blocks，此时，Data Block Index所占用的大小为81920000*62bytes，约为4.7GB。

这是HFile V2设计的初衷，HFile V2期望显著降低RegionServer启动时加载HFile的时延，更希望解决一次全量加载数百MB级别的BloomFilter数据带来的时延过大的问题。下图是HFile V2的数据组织结构：

较之HFile V1，我们来看看HFile V2的几点显著变化：

1.分层索引

无论是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基本上不会存在，文末部分会通过详细的计算阐述它基本不存在的原因，因此，索引逻辑被简化为：由Roo