系列歷史文章

2021年大資料HBase（十四）：HBase的原理及其相關的作業機制

2021年大資料HBase（十三）：HBase讀取和存盤資料的流程

2021年大資料HBase（十二）：Apache Phoenix 二級索引

2021年大資料HBase（十一）：Apache Phoenix的視圖操作

2021年大資料HBase（十）：Apache Phoenix的基本入門操作

2021年大資料HBase（九）：Apache Phoenix的安裝

2021年大資料HBase（八）：Apache Phoenix的基本介紹

2021年大資料HBase（七）：Hbase的架構！【建議收藏】

2021年大資料HBase（六）：HBase的高可用！【建議收藏】

2021年大資料HBase（五）：HBase的相關操作-JavaAPI方式！【建議收藏】

2021年大資料HBase（四）：HBase的相關操作-客戶端命令式！【建議收藏】

2021年大資料HBase（三）：HBase資料模型

2021年大資料HBase（二）：HBase集群安裝操作

2021年大資料HBase（一）：HBase基本簡介

HBase的原理及其相關的作業機制

一、HBase的flush重繪機制(溢寫合并機制)

hbase2.0: flush溢寫的流程說明

flush溢寫流程: hbase 2.0版本后的流程
隨著客戶端不斷寫入資料到達memStore中, memStore記憶體就會被寫滿(128M), 當memStore記憶體達到一定的閾值后, 此時就會觸發flush重繪執行緒, 將資料最終寫入HDFS上, 形成一個StoreFile檔案
1) 當memStore的記憶體寫滿后, 首先將這個記憶體空間關閉, 然后開啟一個新的memStore, 將這個寫滿記憶體空間的資料存盤到一個pipeline的管道(佇列)中 (只能讀, 不能改)
2) 在Hbase的2.0版本后, 這個管道中資料, 會盡可能晚重繪到磁盤中, 一直存盤在記憶體中, 隨著memStore不斷的溢寫, 管道中資料也會不斷的變多
3) 當管道中資料, 達到一定的閾值后, hbase就會啟動一個flush的重繪執行緒, 對pipeline管道中資料一次性全部重繪到磁盤上,而且在重繪的程序中, 對管道中資料進行排序合并壓縮操作, 在HDFS上形成一個合并后的storeFile檔案

1.0版本中:
區別在于 : 不存在盡可能晚的重繪 , 也不存在合并溢寫操作
注意: 雖然說在2.0時代加入這個記憶體合并方案, 但是默認情況下是不開啟的

2.0中記憶體合并的策略:

basic(基礎型):
說明: 僅做作為基本的合并, 不會對過期資料進行清除操作
優點: 效率高 ,適合于這種有大量寫的模式
弊端: 如果資料中大多數都是已經過期的時候, 此時做了許多無用功, 對磁盤IO也會比較大
eager(饑渴型):
說明: 在合并的程序中, 盡可能的去除過期的無用的資料, 保證合并后資料在當下都是可用的
優點: 合并后的檔案會較少, 對磁盤IO比較低, 適用于資料過期比較快的場景(比如購物車資料)
弊端: 由于合并需要多干活,會資源使用也會更多, 導致合并效率降低, 雖然IO減少, 但是依然效率是比較低下的
adaptive(適應型):
說明: 在合并的程序中, 會根據資料的重復情況來決定是否需要采用哪種方案, 當重復資料過多, 就會采用eager型, 否則使用basic(基礎型)
優點: 更智能化, 自動切換
弊端: 如果重復資料比較多但是寫入也比較頻繁, 此時采用eager, 會導致資源被eager占用較大, 從而影響寫入的效率

如何配置記憶體合并策略:

方案一: 全域配置, 所有表都生效

方案二: 針對某個表來設定

二、HBase的storeFile的合并機制

觸發時機:

minor: 觸發時機 storeFile檔案達到3及以上的時候 | 剛剛啟動Hbase集群的時候
major: 默認觸發時間: 7天 | 剛剛啟動Hbase集群的時候

hbase矛盾點: HBase支持隨機讀寫功能, HBase基于HDFS, 而HDFS不支持隨機讀寫, 如何解決呢?

1) 在Hbase中, 所有的資料隨機操作,都是對記憶體中資料進行處理, 如果是添加, 在記憶體中加入資料, 如果修改, 同樣也是添加操作(時間戳記錄版本), 如果洗掉,本應該是直接到磁盤中將資料洗掉, 但是HDFS不支持, 在記憶體中記錄好這個標記,不顯示給用戶看即可
2) 在進行storeFile的major合并操作的時候, 此時將HDFS的資料讀取出來到記憶體中, 邊讀取邊處理, 邊將資料追加到HDFS中

三、Hbase的split機制(region分裂)

split在最終達到10GB時候, 就會執行split分裂, 分裂之后, 就會形成兩個新的Region, 原有Region就會被下線, 新的region會分別各種切分后Hfile檔案
注意: split的最終10Gb 指的是當Hbase中Region數量達到9個及以上的時候, 采用按照10GB進行分裂,而什么分裂取決于以下這個公式:

Min (R^2 * “hbase.hregion.memstore.flush.size”, “hbase.hregion.max.filesize”) R為同一個table中在同一個region server中region的個數，

R: 表的Region的數量
flush.size: 默認值為 128M
max.Filesize: 默認值 10GB

思考: 如果現在我希望, Region在5個時候, 最好就可以按照10GB分裂, 如何解決呢?

調整flush.size的大小