關於HFile的儲存結構梳理以及快速定位rowkey

 

一、HFile結構介紹

 

為了支援資料的隨機查詢，HFile結構分為六個部分：

1、資料區塊–儲存表中的資料，每一個資料區塊由塊頭和一些keyValue(record)組成，key的值是嚴格按照順序儲存的。塊大小預設為64K（由建表時建立cf時指定或者HColumnDescriptor.setBlockSize(size)），這一部分可以壓縮儲存。在查詢資料時，是以資料區塊為單位從硬碟load到記憶體。尋找資料時，是順序的遍曆該塊中的keyValue對。

2、中繼資料塊 (可選的)–儲存使用者自訂的kv對，可以被壓縮。比如booleam filter就是存在中繼資料塊中的，該塊只保留value值，key值儲存在中繼資料索引塊中。每一個中繼資料塊由塊頭和value值組成。可以快速判斷key是都在這個HFile中。

3、File Info–Hfile的元資訊，不被壓縮，使用者也可以在這一部分添加自己的元資訊。

4、資料索引塊 –Data Block的索引，每條索引的key是被索引的block的第一條記錄的key（格式為：頭資訊，資料區塊offset資料區塊大小塊第一個記錄的key，........）。

     這個參數控制hfile中索引塊的大小，預設值是128K，也就是說當索引的資訊超過128K後，就會新分配一個索引塊。hbase對於hfile的訪問都是通過索引塊來實現的，通過索引來定位所要查的資料到底在哪個資料區塊裡面。hfile中的索引塊可以分成三中，根索引塊，枝索引塊，葉索引塊。根索引塊是一定會有的，但是如果hfile中的資料區塊比較少的話，枝索引塊和葉索引塊就可能不存在。當單個的索引塊中沒有辦法儲存全部的資料區塊的資訊時，索引塊就會分裂，會產生葉索引塊和根索引塊，根索引塊是對葉索引塊的索引，如果資料區塊繼續增加就會產生枝索引塊，整個索引結果的層次也會加深。

      想象一下，如果整個hfile中只有根索引塊，那麼訪問真正的資料的路徑是，首先查根索引塊定位元據塊的位置，然後去查詢資料區塊找到需要的資料。整個過程涉及到一次對索引塊的掃描和一次對資料區塊的掃描。

      如果hfile總塊比較多，整個索引結構有2次的話，訪問的路徑是，首先訪問根索引塊定位葉索引塊，訪問葉索引塊定位元據塊，整個過程涉及到兩次對索引塊的掃描和一次對資料區塊的掃描。

     整個索引樹的深度越深，那麼訪問過程就越長，相應的掃描的時間也會越長。

      那是不是把hfile.index.block.max.size設定得越大越好呢？也不是的，如果索引塊太大了，對索引塊本身的掃描時間就會顯著的增加的。

       根索引塊一定是被緩衝到記憶體中的，這個是在hfile開啟的時候就緩衝的.

      想象一下，如果整個hfile中只有根索引塊，那麼訪問真正的資料的路徑是，首先查根索引塊定位元據塊的位置，然後去查詢數

    據塊找到需要的資料。整個過程涉及到一次對索引塊的掃描和一次對資料區塊的掃描。 

HFile的資料區塊，中繼資料塊通常採用壓縮方式儲存，壓縮之後可以大大減少網路IO和磁碟IO，隨之而來的開銷當然是需要花費cpu進行壓縮和解壓縮

HFile Data Block Index索引層級的問題，

hfile.data.block.size（預設64K）:同樣的資料量，資料區塊越小，資料區塊越多，索引塊相應的也就越多，索引層級就越深

hfile.index.block.max.size(預設128K)：控制索引塊的大小，索引塊越小，需要的索引塊越多，索引的層級越深

table key length：越大，索引層級越深

hfile中儲存的資料量：越大，索引層級越深

5、中繼資料索引塊 (可選的)–Meta Block的索引。

6、Trailer–這一段是定長的。儲存了每一段(由一種類型的塊組成)的位移量，讀取一個HFile時，會首先 讀取Trailer，Trailer儲存了每個段的起始位置(段的Magic Number用來做安全check)，然後，資料索引會被讀取到記憶體中，這樣，當檢索某個key時，不需要掃描整個HFile，而只需從記憶體中找到key所在的block，通過一次磁碟io將整個block讀取到記憶體中，再找到需要的key。資料索引塊採用LRU機制淘汰。

 

二、怎樣從一系列的HFile中找到某個rowkey?

     如果建立表時，指定了booleamFilter，那麼就根據booleamFilter快速的判斷該rowkey是否在這個HFile中。

     如果沒有定義booleamFilter，hbase在尋找先會根據時間戳記或者查詢列的資訊來進行過濾，過濾掉那些肯定不含有所需資料的storefile或者memstore，盡量把我們的查詢目標範圍縮小。

     儘管縮小了，但仍可能會有多個檔案需要掃描的。storefile的內部有序的，但是各個storefile之間並不是有序的。storefile的rowkey的範圍很有可能有交叉。所以查詢資料的過程也不可能是對storefile的順序尋找。
hbase會首先查看每個storefile的最小的rowkey，然後按照從小到大的順序進行排序，結果放到一個隊列中，排序的演算法就是按照hbase的三維順序，按照rowkey，column，ts進行排序，rowkey和column是升序，而ts是降序。
實際上並不是所有滿足時間戳記和列過濾的檔案都會加到這個隊列中，hbase會首先對各個storefile中的資料進行探測，只會掃描掃描那些存在比當前查詢的rowkey大的記錄的storefile。
    下面開始查詢資料，整個過程用到了類似歸併排序的演算法，首先通過poll取出隊列的頭storefile，會從storefile讀取一條記錄返回；接下來呢，該storefile的下條記錄並不一定是查詢結果的下一條記錄，因為隊列的比較順序是比較的每個storefile的第一條符合要求的rowkey。所以，hbase會繼續從隊列中剩下的storefile取第一條記錄，把該記錄與頭storefile的第二條記錄做比較，如果前者大，那麼返回頭storefile的第二條記錄；如果後者大，則會把頭storefile放回隊列重新排序，在重新取隊列的頭storefile。然後重複上面的整個過程，直到找到key所在的HFile。範圍縮小到該HFile後，就根據上面介紹的索引尋找定位到塊，快速的找到對應的記錄。