網(wǎng)易視頻云：HBase–存儲文件HFile結(jié)構(gòu)解析

1、網(wǎng)易視頻云：HBase 存儲文件HFile結(jié)構(gòu)解析網(wǎng)易視頻云是網(wǎng)易推出的PaaS視頻云服務，主要應用于在線教育、直播秀場、遠程醫(yī)療、企業(yè)協(xié)作等領域。今天，網(wǎng)易視頻云技術專家與大家分享一下：HBase 存儲文件HFile結(jié)構(gòu)解析。HFile是HBase存儲數(shù)據(jù)的文件組織形式，參考BigTable的SSTable和Hadoop的TFile實現(xiàn)。從HBase開始到現(xiàn)在，HFile經(jīng)歷了三個版本，其中V2在0.92引入，V3在0.98引入。HFileV1版本的在實際使用過程中發(fā)現(xiàn)它占用內(nèi)存多，HFile V2版本針對此進行了優(yōu)化，HFile V3版本基本和V2版本相同，只是在cell層面添加了Tag數(shù)

2、組的支持。鑒于此，本文主要針對V2版本進行分析，對V1和V3版本感興趣的同學可以參考其他信息。HFile邏輯結(jié)構(gòu)HFile V2的邏輯結(jié)構(gòu)如下圖所示：文件主要分為四個部分：Scanned block section，Non-scanned block section，Opening-time data section和Trailer。Scanned block section：顧名思義，表示順序掃描HFile時所有的數(shù)據(jù)塊將會被讀取，包括Leaf Index Block和Bloom Block。Non-scanned block section：表示在HFile順序掃描的時候數(shù)據(jù)不會被讀取，主

3、要包括Meta Block和Intermediate Level Data Index Blocks兩部分。Load-on-open-section：這部分數(shù)據(jù)在HBase的region server啟動時，需要加載到內(nèi)存中。包括FileInfo、Bloom filter block、data block index和meta block index。Trailer：這部分主要記錄了HFile的基本信息、各個部分的偏移值和尋址信息。HFile物理結(jié)構(gòu)如上圖所示， HFile會被切分為多個大小相等的block塊，每個block的大小可以在創(chuàng)建表列簇的時候通過參數(shù)blocksize > 65

4、535進行指定，默認為64k，大號的Block有利于順序Scan，小號Block利于隨機查詢，因而需要權(quán)衡。而且所有block塊都擁有相同的數(shù)據(jù)結(jié)構(gòu)，如圖左側(cè)所示，HBase將block塊抽象為一個統(tǒng)一的HFileBlock。HFileBlock支持兩種類型，一種類型不支持checksum，一種不支持。為方便講解，下圖選用不支持checksum的HFileBlock內(nèi)部結(jié)構(gòu)：上圖所示HFileBlock主要包括兩部分：BlockHeader和BlockData。其中BlockHeader主要存儲block元數(shù)據(jù)，BlockData用來存儲具體數(shù)據(jù)。block元數(shù)據(jù)中最核心的字段是BlockTy

5、pe字段，用來標示該block塊的類型，HBase中定義了8種BlockType，每種BlockType對應的block都存儲不同的數(shù)據(jù)內(nèi)容，有的存儲用戶數(shù)據(jù)，有的存儲索引數(shù)據(jù)，有的存儲meta元數(shù)據(jù)。對于任意一種類型的HFileBlock，都擁有相同結(jié)構(gòu)的BlockHeader，但是BlockData結(jié)構(gòu)卻不相同。下面通過一張表簡單羅列最核心的幾種BlockType，下文會詳細針對每種BlockType進行詳細的講解：HFile中Block塊解析上文從HFile的層面將文件切分成了多種類型的block，接下來針對幾種重要block進行詳細的介紹，因為篇幅的原因，索引相關的block不會在本文

6、進行介紹，接下來會寫一篇單獨的文章對其進行分析和講解。首先會介紹記錄HFile基本信息的TrailerBlock，再介紹用戶數(shù)據(jù)的實際存儲塊DataBlock，最后簡單介紹布隆過濾器相關的block。Trailer Block主要記錄了HFile的基本信息、各個部分的偏移值和尋址信息，下圖為Trailer內(nèi)存和磁盤中的數(shù)據(jù)結(jié)構(gòu)，其中只顯示了部分核心字段：HFile在讀取的時候首先會解析Trailer Block并加載到內(nèi)存，然后再進一步加載LoadOnOpen區(qū)的數(shù)據(jù)，具體步驟如下：1. 首先加載version版本信息，HBase中version包含majorVersion和minorVers

7、ion兩部分，前者決定了HFile的主版本： V1、V2 還是V3；后者在主版本確定的基礎上決定是否支持一些微小修正，比如是否支持checksum等。不同的版本決定了使用不同的Reader對象對HFile進行讀取解析2. 根據(jù)Version信息獲取trailer的長度（不同version的trailer長度不同），再根據(jù)trailer長度加載整個HFileTrailer Block3. 最后加載load-on-open部分到內(nèi)存中，起始偏移地址是trailer中的LoadOnOpenDataOffset字段，load-on-open部分的結(jié)束偏移量為HFile長度減去Trailer長度，loa

8、d-on-open部分主要包括索引樹的根節(jié)點以及FileInfo兩個重要模塊，F(xiàn)ileInfo是固定長度的塊，它紀錄了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等；索引樹根節(jié)點放到下一篇文章進行介紹。Data BlockDataBlock是HBase中數(shù)據(jù)存儲的最小單元。DataBlock中主要存儲用戶的KeyValue數(shù)據(jù)（KeyValue后面一般會跟一個timestamp，圖中未標出），而KeyValue結(jié)構(gòu)是HBase存儲的核心，每個數(shù)據(jù)都是以KeyValue結(jié)構(gòu)在HBas

9、e中進行存儲。KeyValue結(jié)構(gòu)在內(nèi)存和磁盤中可以表示為：每個KeyValue都由4個部分構(gòu)成，分別為key length，value length，key和value。其中key value和value length是兩個固定長度的數(shù)值，而key是一個復雜的結(jié)構(gòu)，首先是rowkey的長度，接著是rowkey，然后是ColumnFamily的長度，再是ColumnFamily，最后是時間戳和KeyType（keytype有四種類型，分別是Put、Delete、 DeleteColumn和DeleteFamily），value就沒有那么復雜，就是一串純粹的二進制數(shù)據(jù)。BloomFilter M

10、eta Block & Bloom BlockBloomFilter對于HBase的隨機讀性能至關重要，對于get操作以及部分scan操作可以剔除掉不會用到的HFile文件，減少實際IO次數(shù)，提高隨機讀性能。在此簡單地介紹一下Bloom Filter的工作原理，Bloom Filter使用位數(shù)組來實現(xiàn)過濾，初始狀態(tài)下位數(shù)組每一位都為0，如下圖所示：假如此時有一個集合S = x1, x2, xn，Bloom Filter使用k個獨立的hash函數(shù)，分別將集合中的每一個元素映射到1,m的范圍。對于任何一個元素，被映射到的數(shù)字作為對應的位數(shù)組的索引，該位會被置為1。比如元素x1被hash函數(shù)

11、映射到數(shù)字8，那么位數(shù)組的第8位就會被置為1。下圖中集合S只有兩個元素x和y，分別被3個hash函數(shù)進行映射，映射到的位置分別為（0，2，6）和（4，7，10），對應的位會被置為1:現(xiàn)在假如要判斷另一個元素是否是在此集合中，只需要被這3個hash函數(shù)進行映射，查看對應的位置是否有0存在，如果有的話，表示此元素肯定不存在于這個集合，否則有可能存在。下圖所示就表示z肯定不在集合x，y中：HBase中每個HFile都有對應的位數(shù)組，KeyValue在寫入HFile時會先經(jīng)過幾個hash函數(shù)的映射，映射后將對應的數(shù)組位改為1，get請求進來之后再進行hash映射，如果在對應數(shù)組位上存在0，說明該get

12、請求查詢的數(shù)據(jù)不在該HFile中。HFile中的位數(shù)組就是上述Bloom Block中存儲的值，可以想象，一個HFile文件越大，里面存儲的KeyValue值越多，位數(shù)組就會相應越大。一旦太大就不適合直接加載到內(nèi)存了，因此HFile V2在設計上將位數(shù)組進行了拆分，拆成了多個獨立的位數(shù)組（根據(jù)Key進行拆分，一部分連續(xù)的Key使用一個位數(shù)組）。這樣一個HFile中就會包含多個位數(shù)組，根據(jù)Key進行查詢，首先會定位到具體的某個位數(shù)組，只需要加載此位數(shù)組到內(nèi)存進行過濾即可，減少了內(nèi)存開支。在結(jié)構(gòu)上每個位數(shù)組對應HFile中一個Bloom Block，為了方便根據(jù)Key定位具體需要加載哪個位數(shù)組，H

13、File V2又設計了對應的索引Bloom Index Block，對應的內(nèi)存和邏輯結(jié)構(gòu)圖如下：Bloom Index Block結(jié)構(gòu)中totalByteSize表示位數(shù)組的bit數(shù)，numChunks表示Bloom Block的個數(shù)，hashCount表示hash函數(shù)的個數(shù)，hashType表示hash函數(shù)的類型，totalKeyCount表示bloom filter當前已經(jīng)包含的key的數(shù)目，totalMaxKeys表示bloom filter當前最多包含的key的數(shù)目, Bloom Index Entry對應每一個bloom filter block的索引條目，作為索引分別指向scann

14、ed block section部分的Bloom Block，Bloom Block中就存儲了對應的位數(shù)組。Bloom Index Entry的結(jié)構(gòu)見上圖左邊所示，BlockOffset表示對應Bloom Block在HFile中的偏移量，F(xiàn)irstKey表示對應BloomBlock的第一個Key。根據(jù)上文所說，一次get請求進來，首先會根據(jù)key在所有的索引條目中進行二分查找，查找到對應的Bloom Index Entry，就可以定位到該key對應的位數(shù)組，加載到內(nèi)存進行過濾判斷?？偨Y(jié)這篇小文首先從宏觀的層面對HFile的邏輯結(jié)構(gòu)和物理存儲結(jié)構(gòu)進行了講解，并且將HFile從邏輯上分解為各種類型的Block，再接著從微觀的視角分別對Trailer Block、Data Bloc