全網(wǎng)最詳細(xì)的大數(shù)據(jù)HBase文章系列，強烈建議收藏加關(guān)注！?

新文章都已經(jīng)列出歷史文章目錄，幫助大家回顧前面的知識重點。

目錄

系列歷史文章

HBase的原理及其相關(guān)的工作機制

一、HBase的flush刷新機制(溢寫合并機制)

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

2.0中內(nèi)存合并的策略:

如何配置內(nèi)存合并策略:

二、HBase的storeFile的合并機制

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

四、regionServer的上線流程

五、regionServer的下線流程

六、master的上線和下線

1、Master上線

2、Master下線

---

系列歷史文章

2021年大數(shù)據(jù)HBase（十七）：HBase的360度全面調(diào)優(yōu)

2021年大數(shù)據(jù)HBase（十六）：HBase的協(xié)處理器(Coprocessor)

2021年大數(shù)據(jù)HBase（十五）：HBase的Bulk Load批量加載操作

2021年大數(shù)據(jù)HBase（十四）：HBase的原理及其相關(guān)的工作機制

2021年大數(shù)據(jù)HBase（十三）：HBase讀取和存儲數(shù)據(jù)的流程

2021年大數(shù)據(jù)HBase（十二）：Apache Phoenix 二級索引

2021年大數(shù)據(jù)HBase（十一）：Apache Phoenix的視圖操作

2021年大數(shù)據(jù)HBase（十）：Apache Phoenix的基本入門操作

2021年大數(shù)據(jù)HBase（九）：Apache Phoenix的安裝

2021年大數(shù)據(jù)HBase（八）：Apache Phoenix的基本介紹

2021年大數(shù)據(jù)HBase（七）：Hbase的架構(gòu)！【建議收藏】

2021年大數(shù)據(jù)HBase（六）：HBase的高可用！【建議收藏】

2021年大數(shù)據(jù)HBase（五）：HBase的相關(guān)操作-JavaAPI方式！【建議收藏】

2021年大數(shù)據(jù)HBase（四）：HBase的相關(guān)操作-客戶端命令式！【建議收藏】

2021年大數(shù)據(jù)HBase（三）：HBase數(shù)據(jù)模型

2021年大數(shù)據(jù)HBase（二）：HBase集群安裝操作

2021年大數(shù)據(jù)HBase（一）：HBase基本簡介

HBase的原理及其相關(guān)的工作機制

一、HBase的flush刷新機制(溢寫合并機制)

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

flush溢寫流程: ? hbase 2.0版本后的流程
? ? ? 隨著客戶端不斷寫入數(shù)據(jù)到達(dá)memStore中, memStore內(nèi)存就會被寫滿(128M), 當(dāng)memStore內(nèi)存達(dá)到一定的閾值后,?此時就會觸發(fā)flush刷新線程, 將數(shù)據(jù)最終寫入HDFS上, 形成一個StoreFile文件
1) 當(dāng)memStore的內(nèi)存寫滿后, 首先將這個內(nèi)存空間關(guān)閉, 然后開啟一個新的memStore, 將這個寫滿內(nèi)存空間的數(shù)據(jù)存儲到一個pipeline的管道(隊列)中 (只能讀, 不能改)
2) 在Hbase的2.0版本后, 這個管道中數(shù)據(jù), 會盡可能晚刷新到磁盤中, 一直存儲在內(nèi)存中, ?隨著memStore不斷的溢寫, 管道中數(shù)據(jù)也會不斷的變多
3) 當(dāng)管道中數(shù)據(jù), 達(dá)到一定的閾值后, hbase就會啟動一個flush的刷新線程, 對pipeline管道中數(shù)據(jù)一次性全部刷新到磁盤上,而且在刷新的過程中, 對管道中數(shù)據(jù)進(jìn)行排序合并壓縮操作, 在HDFS上形成一個合并后的storeFile文件

1.0版本中:?
區(qū)別在于 : 不存在 盡可能晚的刷新 , 也不存在合并溢寫操作
注意: 雖然說在2.0時代加入這個內(nèi)存合并方案, 但是默認(rèn)情況下是不開啟的

2.0中內(nèi)存合并的策略:

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

如何配置內(nèi)存合并策略:

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

方案二: 針對某個表來設(shè)置

二、HBase的storeFile的合并機制

觸發(fā)時機: ?

minor: 觸發(fā)時機 storeFile文件達(dá)到3及以上的時候 | 剛剛啟動Hbase集群的時候
major: 默認(rèn)觸發(fā)時間: 7天 ?| 剛剛啟動Hbase集群的時候

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

1) 在Hbase中, 所有的數(shù)據(jù)隨機操作,都是對內(nèi)存中數(shù)據(jù)進(jìn)行處理, 如果是添加, 在內(nèi)存中加入數(shù)據(jù), 如果修改, 同樣也是添加操作(時間戳記錄版本), ?如果刪除,本應(yīng)該是直接到磁盤中將數(shù)據(jù)刪除, 但是HDFS不支持, 在內(nèi)存中記錄好這個標(biāo)記,不顯示給用戶看即可
2) 在進(jìn)行storeFile的major合并操作的時候, 此時將HDFS的數(shù)據(jù)讀取出來到內(nèi)存中, 邊讀取邊處理, 邊將數(shù)據(jù)追加到HDFS中

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

• split在最終達(dá)到10GB時候, 就會執(zhí)行split分裂, 分裂之后, 就會形成兩個新的Region, 原有Region就會被下線, 新的region會分別各種切分后Hfile文件

• 注意: split的 最終10Gb 指的是當(dāng)Hbase中Region數(shù)量達(dá)到9個及以上的時候, 采用按照10GB進(jìn)行分裂,而什么分裂取決于以下這個公式:

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

R: 表的Region的數(shù)量
flush.size: 默認(rèn)值為 128M
max.Filesize: 默認(rèn)值 10GB

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

調(diào)整flush.size的大小

四、regionServer的上線流程

• Master使用ZooKeeper來跟蹤region server狀態(tài)
• 當(dāng)某個region server啟動時

1. 首先在zookeeper上的server目錄下建立代表自己的znode
2. 由于Master訂閱了server目錄上的變更消息，當(dāng)server目錄下的文件出現(xiàn)新增或刪除操作時，master可以得到來自zookeeper的實時通知
3. 一旦region server上線，master能馬上得到消息。

五、regionServer的下線流程

• 當(dāng)region server下線時，它和zookeeper的會話斷開，ZooKeeper而自動釋放代表這臺server的文件上的獨占鎖
• Master就可以確定

1. region server和zookeeper之間的網(wǎng)絡(luò)斷開了
2. region server掛了

• 無論哪種情況，region server都無法繼續(xù)為它的region提供服務(wù)了，此時master會刪除server目錄下代表這臺region server的znode數(shù)據(jù)，并將這臺region server的region分配給其它還活著的節(jié)點

六、master的上線和下線

1、Master上線

Master啟動進(jìn)行以下步驟:

1. 從zookeeper上獲取唯一一個代表active master的鎖，用來阻止其它master成為master
2. 一般hbase集群中總是有一個master在提供服務(wù)，還有一個以上的‘master’在等待時機搶占它的位置。
3. 掃描zookeeper上的server父節(jié)點，獲得當(dāng)前可用的region server列表
4. 和每個region server通信，獲得當(dāng)前已分配的region和region server的對應(yīng)關(guān)系
5. 掃描.META.region的集合，計算得到當(dāng)前還未分配的region，將他們放入待分配region列表

2、Master下線

• 由于master只維護(hù)表和region的元數(shù)據(jù)，而不參與表數(shù)據(jù)IO的過程，master下線僅導(dǎo)致所有元數(shù)據(jù)的修改被凍結(jié)

1. 無法創(chuàng)建刪除表
2. 無法修改表的schema
3. 無法進(jìn)行region的負(fù)載均衡
4. 無法處理region 上下線
5. 無法進(jìn)行region的合并
6. 唯一例外的是region的split可以正常進(jìn)行，因為只有region server參與
7. 表的數(shù)據(jù)讀寫還可以正常進(jìn)行

• 因此master下線短時間內(nèi)對整個hbase集群沒有影響。
• 從上線過程可以看到，master保存的信息全是可以冗余信息（都可以從系統(tǒng)其它地方收集到或者計算出來）

注意:
?? ?master下線短期對hbase沒有太大的影響, 因為master不會參與數(shù)據(jù)IO操作, 數(shù)據(jù)讀寫操作不會使用master
?? ?master下線主要是影響了對表的一些 以及對region的操作

---

• 📢博客主頁：https://lansonli.blog.csdn.net
• 📢歡迎點贊 👍 收藏 ?留言 📝 如有錯誤敬請指正！
• 📢本文由 Lansonli 原創(chuàng)，首發(fā)于 CSDN博客🙉
• 📢大數(shù)據(jù)系列文章會每天更新，停下休息的時候不要忘了別人還在奔跑，希望大家抓緊時間學(xué)習(xí)，全力奔赴更美好的生活?

總結(jié)

以上是生活随笔為你收集整理的2021年大数据HBase（十四）：HBase的原理及其相关的工作机制的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。