Table of Contents

HFile存储格式
Block块结构

HFile存储格式

HFile是參照谷歌的SSTable存储格式进行设计的。全部的数据记录都是通过它来完毕持久化，其内部主要採用分块的方式进行存储，如图所看到的：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

每一个HFile内部包括多种不同类型的块结构，这些块结构从逻辑上来讲可归并为两类。分别用于数据存储和数据索引(简称数据块和索引块)，当中数据块包括：

(1) DATA_BLOCK：存储表格数据

(2) BLOOM_CHUNK：存储布隆过滤器的位数组信息

(3) META_BLOCK：存储元数据信息

(4) FILE_INFO：存储HFile文件信息

索引块包括：

  • 表格数据索引块(ROOT_INDEX、INTERMEDIATE_INDEX、LEAF_INDEX)

    在早期的HFile版本号中(version-1)，表格数据是採用单层索引结构进行存储的。这样当数据量上升到一定规模时，索引数据便会消耗大量内存，导致的结果是Region载入效率低下(A region is not considered opened until all of its block index data is loaded)。

    因此在version-2版本号中。索引数据採用多层结构进行存储，载入HFile时仅仅将根索引(ROOT_INDEX)数据载入内存，中间索引(INTERMEDIATE_INDEX)和叶子索引(LEAF_INDEX)在读取数据时按需载入，从而提高了Region的载入效率。

  • 元数据索引块(META_INDEX)

    新版本号的元数据索引依旧是单层结构，通过它来获取元数据块信息。

  • 布隆索引信息块(BLOOM_META)

    通过索引信息来遍历要检索的数据记录是通过哪一个BLOOM_CHUNK进行映射处理的。

从存储的角度来看，这些数据块会划分到不同的区域进行存储。

  1. Trailer区域

    该区域位于文件的最底部。HFile主要通过它来实现相关数据的定位功能，因此须要最先载入，其数据内容是採用protobuf进行序列化处理的，protocol声明例如以下：

    message FileTrailerProto {
    
    optional uint64 file_info_offset = 1; 
    
    optional uint64 load_on_open_data_offset = 2; 
    
    optional uint64 uncompressed_data_index_size = 3; 
    
    optional uint64 total_uncompressed_bytes = 4; 
    
    optional uint32 data_index_count = 5; 
    
    optional uint32 meta_index_count = 6; 
    
    optional uint64 entry_count = 7; 
    
    optional uint32 num_data_index_levels = 8; 
    
    optional uint64 first_data_block_offset = 9; 
    
    optional uint64 last_data_block_offset = 10; 
    
    optional string comparator_class_name = 11;
    
    optional uint32 compression_codec = 12;
    
    optional bytes encryption_key = 13;
    
}

    FileInfo数据块在HFile中的偏移量信息；

    Load-on-open区域在HFile中的偏移量信息；

    全部表格索引块在压缩前的总大小；

    全部表格数据块在压缩前的总大小；

    根索引块中包括的索引实体个数；

    元数据索引块中包括的索引实体个数；

    文件所包括的KeyValue总数；

    表格数据的索引层级数。

    第一个表格数据块在HFile中的偏移量信息；

    最后一个表格数据块在HFile中的偏移量信息；

    在代码层面上Trailer是通过FixedFileTrailer类来封装的，可通过其readFromStream方法用来读取指定HFile的Trailer信息。

  2. Load-on-open区域

    HFile被载入之后。位于该区域中的数据将会被载入内存，该区域的起始位置通过Trailer来定位(通过其load_on_open_data_offset属性)。从该位置起依次保存的数据信息为：根索引快、元数据索引块、文件信息块以及布隆索引块。

  3. Scanned-Block区域

    在运行HFile顺序扫描时，位于该区域中的全部块信息都须要被载入，包括：表格数据块、布隆数据块和叶子索引块(后两者称之为InlineBlock)。

  4. Non-Scanned-Block区域

    在运行HFile顺序扫描时，位于该区域中的存储块可不被载入。包括：元数据块和中间索引块。

Block块结构

每一个Block块是由3部分信息组成的。各自是：header信息、data信息以及用于data校验的checksum信息。

不同类型的block仅仅是在data信息的存储结构上存在差异，而header信息和checksum信息存储结构基本一致。

  1. header主要用于存储每一个Block块的元数据信息

    这些信息包括：

    (1)blockType：块类型。HFile一共对外声明了10种不同类型的Block。各自是：DATA(表格数据块)、META(元数据块)、BLOOM_CHUNK(布隆数据块)、FILE_INFO(文件信息块)、TRAILER、LEAF_INDEX(叶子索引块)、INTERMEDIATE_INDEX(中间索引块)、ROOT_INDEX(根索引快)、BLOOM_META(布隆索引块)、和META_INDEX(元数据索引块)。

    (2)onDiskSizeWithoutHeader：data信息与checksum信息所占用的磁盘空间大小；

    (3)onDiskDataSizeWithHeader：data信息与header信息所占用的磁盘空间大小。

    (4)uncompressedSizeWithoutHeader：每一个block块在完毕解压缩之后的大小(不包括header和checksum占用的空间)；

    (5)prevBlockOffset：距离上一个同类型block块的存储偏移量大小。

    在v2版本号中，header的长度为固定的33字节。

  2. data主要用于封装每一个block块的核心数据内容

    • 假设是根索引块其数据内容例如以下：

      主要包括多条索引实体信息(索引实体的个数记录在Trailer中)以及midKey相关信息。当中每条索引实体信息是由3部分数据组成的。分别为：

      (1)Offset：索引指向的Block块在文件里的偏移量位置；

      (2)DataSize：索引指向的Block块所占用的磁盘空间大小(在HFile中的长度)；

      (3)Key：假设索引指向的是表格数据块(DATA_BLOCK)。该值为目标数据块中第一条数据记录的rowkey值(0.95版本号之前是这种，之后的版本号參考HBASE-7845)；假设索引指向的是其它索引块，该值为目标索引块中第一条索引实体的blockKey值。

      而midKey信息主要用于定位HFile的中间位置，以便于对该HFile运行split拆分处理，其数据内容相同由3部分信息组成，分别为：

      (1)midLeafBlockOffset：midKey所属叶子索引块在HFile中的偏移量位置。

      (2)midLeafBlockOnDiskSize：midKey所属叶子索引块的大小(在HFile中的长度)。

      (3)midKeyEntry：midKey在其所属索引块中的偏移量位置。

    • 假设是非根索引块其数据内容例如以下：

      watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="" />

      相同包括多条索引实体信息。但不包括midKey信息。除此之外还包括了索引实体的数量信息以及每条索引实体相对于首个索引实体的偏移量位置。

    • 假设是表格数据块其数据内容为多条KeyValue记录，每条KeyValue的存储结构可參考Memstore组件实现章节。

    • 假设是元数据索引块其数据内容同叶子索引块相似。仅仅只是索引实体引向的是META数据块。

    • 假设是布隆数据块其数据内容为布隆过滤器的位数组信息。

    • 假设是布隆索引块其数据内容例如以下：

      同其它索引块相似，包括多条索引实体信息，每条索引实体引向布隆数据块(BLOOM_CHUNK)。除此之外还包括与布隆过滤器相关的元数据信息。包括：

      (1)version：布隆过滤器版本号，在新版本号HBase中布隆过滤器通过CompoundBloomFilter类来实现，其相应的版本号号为3。

      (2)totalByteSize：全部布隆数据块占用的磁盘空间总大小；

      (3)hashCount：元素映射过程中所使用的hash函数个数。

      (4)hashType：元素映射过程中所採用的hash函数类型(通过hbase.hash.type属性进行声明)。

      (5)totalKeyCount：全部布隆数据块中已映射的元素数量；

      (6)totalMaxKeys：在满足指定误报率的情况下(默觉得百分之中的一个)，全部布隆数据块可以映射的元素总量。

      (7)numChunks：眼下已有布隆数据块的数量；

      (8)comparator：所映射元素的排序比較类，默觉得org.apache.hadoop.hbase.KeyValue.RawBytesComparator

    • 假设是文件信息块其数据内容採用protobuf进行序列化，相关protocol声明例如以下：

      message FileInfoProto {
      
    repeated BytesBytesPair map_entry = 1; // Map of name/values
      
}

  3. checksum信息用于校验data数据是否正确

块信息读取

数据块的读取操作主要是通过FSReader类的readBlockData方法来实现的。在运行数据读取操作之前。须要首先知道目标数据块在HFile中的偏移量位置。有一些数据块的偏移量信息是可通过Trailer进行定位的。如：

  • 根索引块(ROOT_INDEX)的偏移量信息可通过Trailer的load_on_open_data_offset属性来定位，在知道了根索引块的存储信息之后，便可通过它来定位全部DATA_BLOCK在HFile中的偏移量位置；

  • 首个DATA_BLOCK的偏移量信息可通过Trailer的first_data_block_offset属性来定位。

在不知道目标数据块大小的情况下须要对HFile运行两次查询才干读取到终于想要的HFileBlock数据。第一次查询主要是为了读取目标Block的header信息，由于header具有固定的长度(HFileV2版本号为33字节)。因此在知道目标Block的偏移量之后，便可通过读取指定长度的数据来将header获取。

获取到header之后便可通过其onDiskSizeWithoutHeader属性来得知目标数据块的总大小。

totalSize = headerSize + onDiskSizeWithoutHeader

然后再次从Block的偏移量处读取长度为totalSize字节的数据。以此来构造完整的HFileBlock实体。

由以上逻辑来看，假设在读取数据块之前。可以事先知道该数据块的大小。那么便可省去header的查询过程。从而有效减少IO次数。

为此，HBase採用的做法是在读取指定Block数据的同一时候。将下一个Block的header也一并读取出来(通过读取totalSize + headerSize长度的数据)，并通过ThreadLocal将该header进行缓存。

这样假设当前线程所訪问的数据是通过两个连续的Block进行存储的，那么针对第二个Block的訪问仅仅需运行一次IO就可以。

获取到HFileBlock实体之后，可通过其getByteStream方法来获取内部数据的输入流信息，在依据不同的块类型来选择相应的API进行信息读取：

(1)假设block为根索引块。其信息内容可通过BlockIndexReader进行读取，通过其readMultiLevelIndexRoot方法；

(2)假设为元数据索引块。相同採用BlockIndexReader进行读取，通过其readRootIndex方法；

(3)假设为非根索引块，可通过BlockIndexReader的locateNonRootIndexEntry方法来将数据指针定位到目标block的索引位置上。从而对目标block的偏移量、大小进行读取；

(4)假设为文件信息块，通过FileInfo类的read方法进行读取。

(5)假设为布隆索引块，通过HFile.Reader实体的getGeneralBloomFilterMetadata方法进行读取。

(6)假设为布隆数据块，通过该HFileBlock实体的getBufferWithoutHeader方法来获取布隆数据块的位数组信息(參考CompoundBloomFilter类的实现)。

块数据生成

Block数据在写入HFile之前是暂存于内存中的。通过字节数组进行存储，当其数据量大小达到指定阀值之后，在開始向HFile进行写入。

写入成功后，须要再次开启一个全新的Block来接收新的数据记录。该逻辑通过HFileBlock.Writer类的startWriting方法来封装。方法运行后。会首先开启ByteArrayOutputStream输出流实例，然后在将其包装成DataOutputStream对象，用于向目标字节数组写入要加入的Block实体信息。

在HFile.Writer内部。不同类型的数据块是通过不同的Writer进行写入的，其内部封装了3种不同类型的子Writer(这些Writer共用一个FSDataOutputStream用于向HFile写入Block数据)，分别例如以下：

  • HFileBlock.Writer

    通过该Writer完毕表格数据块(DataBlock)向HFile的写入逻辑。大致流程例如以下：

    每当运行HFile.Writer类的append方法进行加入数据时。会检測当前DataBlock的大小是否已经超过目标阀值。假设没有，直接将数据写入DataBlock，否则须要进行例如以下处理：

    1. 将当前DataBlock持久化写入HFile

      写入之前须要首先生成目标数据块的header和checksum信息。当中checksum信息可通过ChecksumUtil的generateChecksums方法进行获取。而header信息可通过putHeader方法来生成。

    2. 生成当前DataBlock的索引信息

      索引信息是由索引key。数据块在HFile中的偏移量位置和数据块的总大小3部分信息组成的，当中索引key可通过CellComparator.getMidpoint方法进行获取。方法会试图返回一条数据记录可以满足例如以下约束条件：

      (1)索引key在排序上大于上一个DataBlock的最后一条记录。

      (2)索引key在排序上小于当前DataBlock的第一条记录；

      (3)索引key的size是最小的。

      经过这样处理之后可以总体减少索引块的数据量大小，从而节省了内存空间的使用，并提高了载入效率。

    3. 将索引信息写入索引块

      通过HFileBlockIndex.BlockIndexWriter的addEntry方法。

    4. 推断是否有必要将InlineBlock进行持久化

      InlineBlock包括叶子索引块和布隆数据块。它们的持久化逻辑分别通过BlockIndexWriter和CompoundBloomFilterWriter来完毕。

    5. 开启新的DataBlock进行数据写入，同一时候将老的数据块退役

      假设集群开启了hbase.rs.cacheblocksonwrite配置，须要将老数据块缓存至BlockCache中。

  • HFileBlockIndex.BlockIndexWriter

    通过该Writer完毕索引数据块(IndexBlock)向HFile的写入逻辑。

    在HFile内部。索引数据是分层级进行存储的，包括根索引块、中间索引块和叶子索引块。

    当中叶子索引块又称之为InlineBlock，由于它会穿插在DataBlock之间进行存储。同DataBlock相似。IndexBlock一開始也是缓存在内存里的。每当DataBlock写入HFile之后。都会向当前叶子索引块加入一条索引实体信息。

    假设叶子索引块的大小超过hfile.index.block.max.size限制，便開始向HFile进行写入。写入格式为：索引实体个数、每条索引实体相对于块起始位置的偏移量信息。以及每条索引实体的具体信息(參考Block块结构)。

    这主要是叶子索引块的写入逻辑。而根索引块和中间索引块的写入则主要在HFile.Writer关闭的时候进行。通过BlockIndexWriter的writeIndexBlocks方法。

    在HFile内部，每一个索引块是通过BlockIndexChunk对象进行封装的，其对内声明了例如以下数据结构：

    (1)blockKeys，封装每一条索引所指向的Block中第一条记录的key值；

    (2)blockOffsets，封装每一条索引所指向的Block在HFile中的偏移量位置；

    (3)onDiskDataSizes，封装每一条索引所指向的Block在HFile中的长度。

    除此之外。根索引块还比較特殊。其对内声明了numSubEntriesAt集合，集合类型为List<Long>，每当有叶子索引块写入HFile之后都会向该集合加入一条实体信息，实体的index为当前叶子索引块的个数。value为索引实体总数。这样。通过numSubEntriesAt集合便能确定midKey(中间索引)处在哪个叶子索引块上，在通过blockKeys、blockOffsets和onDiskDataSizes便可以获取最后的midkey信息。

    然后将其作为根索引块的一部分写入HFile。并通过FixedFileTrailer来标记根索引块的写入位置。

    须要注意的是根索引块的大小也是受上限约束的，假设其大小大于hfile.index.block.max.size參数阀值(默觉得128kb)，须要将其拆分成多个中间索引块，然后在对这些中间索引块创建根索引，以此来减少根索引块的大小，具体逻辑可參考BlockIndexWriter类的writeIntermediateLevel方法实现。

  • CompoundBloomFilterWriter

    通过该Writer完毕布隆数据向HFile的写入逻辑。

    布隆数据在HFile内部相同是分块进行存储的，每一个数据块通过ByteBloomFilter类来封装，负责存储指定区间的数据集映射信息(參考布隆过滤器实现章节)。

    每当运行HFile.Writer的append方法向DataBlock加入KeyValue数据之前。都要调用ByteBloomFilter的add方法来生成该KeyValue的布隆映射信息，为了满足目标容错率，每一个ByteBloomFilter实体可以映射的KeyValue数量是受上限约束的，假设达到目标上限值须要将其持久化到HFile中进行存储，然后开启新的ByteBloomFilter实例来接管之前的逻辑。

    每当布隆数据块写入成功之后。都会运行BlockIndexWriter的addEntry方法来创建一条布隆索引实体，实体的key值为布隆数据块所映射的第一条KeyValue的key值。

    同叶子索引块一样，布隆数据块也被称之为InlineBlock，在写入DataBlock的同一时候会对该类型的数据块进行穿插写入。这主要是布隆数据块的写入逻辑，而布隆索引块主要是在HFile.Writer关闭的时候进行创建的。通过CompoundBloomFilterWriter.MetaWriter的write方法。将布隆索引数据连同meta信息一同写入HFile。

HFile存储格式的更多相关文章

  1. HFile

    HFile存储格式 HBase中的所有数据文件都存储在Hadoop HDFS文件系统上,主要包括两种文件类型: 1. HFile, HBase中KeyValue数据的存储格式,HFile是Hadoop ...

  2. HBase原理和架构

    HBase是什么 HBase在生态体系中的位置 HBase vs HDFS HBase表的特点 HBase是真正的分布式存储,存储级别达到TB级别,而才传统数据库就不是真正的分布式了,传统数据库在底层 ...

  3. 基于Apache Hudi 的CDC数据入湖

    作者:李少锋 文章目录: 一.CDC背景介绍 二.CDC数据入湖 三.Hudi核心设计 四.Hudi未来规划 1. CDC背景介绍 首先我们介绍什么是CDC?CDC的全称是Change data Ca ...

  4. HBase数据存储格式

    好的数据结构,对于检索数据,插入数据的效率就会很高. 常见的数据结构 B+树 根节点和枝节点非常easy,分别记录每一个叶子节点的最小值,并用一个指针指向叶子节点.  叶子节点里每一个键值都指向真正的 ...

  5. HBase – 探索HFile索引机制

    本文由  网易云发布. 作者: 范欣欣 本篇文章仅限内部分享,如需转载,请联系网易获取授权. 01 HFile索引结构解析 HFile中索引结构根据索引层级的不同分为两种:single-level和m ...

  6. 9 hbase源码系列（九）StoreFile存储格式

    hbase源码系列(九)StoreFile存储格式    从这一章开始要讲Region Server这块的了,但是在讲Region Server这块之前得讲一下StoreFile,否则后面的不好讲下去 ...

  7. Hive文件存储格式

    hive文件存储格式 1.textfile textfile为默认格式   存储方式:行存储   磁盘开销大 数据解析开销大   压缩的text文件 hive无法进行合并和拆分 2.sequencef ...

  8. 转载：稀疏矩阵存储格式总结+存储效率对比:COO,CSR,DIA,ELL,HYB

    http://www.cnblogs.com/xbinworld/p/4273506.html 稀疏矩阵是指矩阵中的元素大部分是0的矩阵,事实上,实际问题中大规模矩阵基本上都是稀疏矩阵,很多稀疏度在9 ...

  9. Parquet与ORC：高性能列式存储格式(收藏)

    背景 随着大数据时代的到来,越来越多的数据流向了Hadoop生态圈,同时对于能够快速的从TB甚至PB级别的数据中获取有价值的数据对于一个产品和公司来说更加重要,在Hadoop生态圈的快速发展过程中,涌 ...

随机推荐

  1. JS Object 属性判断

    in 方法 var shapeInfo = {name:“lium”}; if (“name” in shapeInfo) {...}

  2. java_lock锁

    lock锁是一个接口,jdk5.0新增的接口: 在线程中创建一个他的实现类对象Reentrantlock,默认为fals可以改为true,改为true后是有序的 把操作共享资源的代码放入try中,在t ...

  3. B2. Concurrent 线程池（Executor）

    [概述] 与数据库连接管理类似,线程的创建和销毁会耗费较大的开销,使用 “池化技术” 来更好地利用当前线程资源,减少因线程创建和销毁带来的开销,这就是线程池产生的原因. [无限创建线程的不足] 在生产 ...

  4. mysql limit关键字

    select * from table_name limit [index, ] length; limit后面跟2个参数: index:索引号,从0开始计算,表示从哪一行开始: length:长度, ...

  5. SQL server 表操作语句（原创）

    CREATE TABLE [dbo].[test] ([id11] int NOT NULL ,[as] varchar(1) COLLATE Chinese_PRC_CI_AS NULL ,[asd ...

  6. 51nod 1021 石子归并 - 区间dp（经典）

    题目地址:http://www.51nod.com/onlineJudge/questionCode.html#!problemId=1021 经典区间dp,dp[i][j] 表示将从 i 到 j 堆 ...

  7. Wireshark does not show SSL/TLS

    why it doesn't show as "TLS/SSL"? Because it's not on the standard port for SSL/TLS. You c ...

  8. Python之使用eval()函数将字符串的数据结构提取出来

    data = input('请输入你要修改的对象:').strip() ''' 输入下面的字典列表 [{'backend':'www.oldboy1.org','record':{'server':' ...

  9. Error: Divergence detected in AMG solver: k

    ** Error: Divergence detected in AMG solver: k A:Since you were working on convergence issue from pa ...

  10. The Bells are Ringing（枚举）

    Description Perhaps you all have heard the mythical story about Tower of Hanoi (The details of this ...