共計(jì) 3569 個(gè)字符，預(yù)計(jì)需要花費(fèi) 9 分鐘才能閱讀完成。

本篇內(nèi)容介紹了“怎么掌握 HBase 架構(gòu)”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓丸趣 TV 小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

HBase 讀的實(shí)現(xiàn)

通過前文的描述，我們知道在 HBase 寫時(shí)，相同 Cell(RowKey/ColumnFamily/Column 相同) 并不保證在一起，甚至刪除一個(gè) Cell 也只是寫入一個(gè)新的 Cell，它含有 Delete 標(biāo)記，而不一定將一個(gè) Cell 真正刪除了，因而這就引起了一個(gè)問題，如何實(shí)現(xiàn)讀的問題？要解決這個(gè)問題，我們先來分析一下相同的 Cell 可能存在的位置：首先對(duì)新寫入的 Cell，它會(huì)存在于 MemStore 中；然后對(duì)之前已經(jīng) Flush 到 HDFS 中的 Cell，它會(huì)存在于某個(gè)或某些 StoreFile(HFile) 中；最后，對(duì)剛讀取過的 Cell，它可能存在于 BlockCache 中。既然相同的 Cell 可能存儲(chǔ)在三個(gè)地方，在讀取的時(shí)候只需要掃瞄這三個(gè)地方，然后將結(jié)果合并即可 (Merge Read)，在 HBase 中掃瞄的順序依次是：BlockCache、MemStore、StoreFile(HFile)。其中 StoreFile 的掃瞄先會(huì)使用 Bloom Filter 過濾那些不可能符合條件的 HFile，然后使用 Block Index 快速定位 Cell，并將其加載到 BlockCache 中，然后從 BlockCache 中讀取。我們知道一個(gè) HStore 可能存在多個(gè) StoreFile(HFile)，此時(shí)需要掃瞄多個(gè) HFile，如果 HFile 過多又是會(huì)引起性能問題。

Compaction

MemStore 每次 Flush 會(huì)創(chuàng)建新的 HFile，而過多的 HFile 會(huì)引起讀的性能問題，那么如何解決這個(gè)問題呢？HBase 采用 Compaction 機(jī)制來解決這個(gè)問題，有點(diǎn)類似 Java 中的 GC 機(jī)制，起初 Java 不停的申請(qǐng)內(nèi)存而不釋放，增加性能，然而天下沒有免費(fèi)的午餐，最終我們還是要在某個(gè)條件下去收集垃圾，很多時(shí)候需要 Stop-The-World，這種 Stop-The-World 有些時(shí)候也會(huì)引起很大的問題，比如參考本人寫的這篇文章，因而設(shè)計(jì)是一種權(quán)衡，沒有完美的。還是類似 Java 中的 GC，在 HBase 中 Compaction 分為兩種：Minor Compaction 和 Major Compaction。

Minor Compaction 是指選取一些小的、相鄰的 StoreFile 將他們合并成一個(gè)更大的 StoreFile，在這個(gè)過程中不會(huì)處理已經(jīng) Deleted 或 Expired 的 Cell。一次 Minor Compaction 的結(jié)果是更少并且更大的 StoreFile。（這個(gè)是對(duì)的嗎？BigTable 中是這樣描述 Minor Compaction 的：As write operations execute, the size of the memtable in- creases. When the memtable size reaches a threshold, the memtable is frozen, a new memtable is created, and the frozen memtable is converted to an SSTable and written to GFS. This minor compaction process has two goals: it shrinks the memory usage of the tablet server, and it reduces the amount of data that has to be read from the commit log during recovery if this server dies. Incom- ing read and write operations can continue while com- pactions occur.  也就是說它將 memtable 的數(shù)據(jù) flush 的一個(gè) HFile/SSTable 稱為一次 Minor Compaction）

Major Compaction 是指將所有的 StoreFile 合并成一個(gè) StoreFile，在這個(gè)過程中，標(biāo)記為 Deleted 的 Cell 會(huì)被刪除，而那些已經(jīng) Expired 的 Cell 會(huì)被丟棄，那些已經(jīng)超過最多版本數(shù)的 Cell 會(huì)被丟棄。一次 Major Compaction 的結(jié)果是一個(gè) HStore 只有一個(gè) StoreFile 存在。Major Compaction 可以手動(dòng)或自動(dòng)觸發(fā)，然而由于它會(huì)引起很多的 IO 操作而引起性能問題，因而它一般會(huì)被安排在周末、凌晨等集群比較閑的時(shí)間。

更形象一點(diǎn)，如下面兩張圖分別表示 Minor Compaction 和 Major Compaction。

HRegion Split

最初，一個(gè) Table 只有一個(gè) HRegion，隨著數(shù)據(jù)寫入增加，如果一個(gè) HRegion 到達(dá)一定的大小，就需要 Split 成兩個(gè) HRegion，這個(gè)大小由 hbase.hregion.max.filesize 指定，默認(rèn)為 10GB。當(dāng) split 時(shí)，兩個(gè)新的 HRegion 會(huì)在同一個(gè) HRegionServer 中創(chuàng)建，它們各自包含父 HRegion 一半的數(shù)據(jù)，當(dāng) Split 完成后，父 HRegion 會(huì)下線，而新的兩個(gè)子 HRegion 會(huì)向 HMaster 注冊上線，處于負(fù)載均衡的考慮，這兩個(gè)新的 HRegion 可能會(huì)被 HMaster 分配到其他的 HRegionServer 中。關(guān)于 Split 的詳細(xì)信息。

HRegion 負(fù)載均衡

在 HRegion Split 后，兩個(gè)新的 HRegion 最初會(huì)和之前的父 HRegion 在相同的 HRegionServer 上，出于負(fù)載均衡的考慮，HMaster 可能會(huì)將其中的一個(gè)甚至兩個(gè)重新分配的其他的 HRegionServer 中，此時(shí)會(huì)引起有些 HRegionServer 處理的數(shù)據(jù)在其他節(jié)點(diǎn)上，直到下一次 Major Compaction 將數(shù)據(jù)從遠(yuǎn)端的節(jié)點(diǎn)移動(dòng)到本地節(jié)點(diǎn)。

HRegionServer Recovery

當(dāng)一臺(tái) HRegionServer 宕機(jī)時(shí)，由于它不再發(fā)送 Heartbeat 給 ZooKeeper 而被監(jiān)測到，此時(shí) ZooKeeper 會(huì)通知 HMaster，HMaster 會(huì)檢測到哪臺(tái) HRegionServer 宕機(jī)，它將宕機(jī)的 HRegionServer 中的 HRegion 重新分配給其他的 HRegionServer，同時(shí) HMaster 會(huì)把宕機(jī)的 HRegionServer 相關(guān)的 WAL 拆分分配給相應(yīng)的 HRegionServer(將拆分出的 WAL 文件寫入對(duì)應(yīng)的目的 HRegionServer 的 WAL 目錄中，并并寫入對(duì)應(yīng)的 DataNode 中），從而這些 HRegionServer 可以 Replay 分到的 WAL 來重建 MemStore。

HBase 架構(gòu)簡單總結(jié)

在 NoSQL 中，存在著名的 CAP 理論，即 Consistency、Availability、Partition Tolerance 不可全得，目前市場上基本上的 NoSQL 都采用 Partition Tolerance 以實(shí)現(xiàn)數(shù)據(jù)得水平擴(kuò)展，來處理 Relational DataBase 遇到的無法處理數(shù)據(jù)量太大的問題，或引起的性能問題。因而只有剩下 C 和 A 可以選擇。HBase 在兩者之間選擇了 Consistency，然后使用多個(gè) HMaster 以及支持 HRegionServer 的 failure 監(jiān)控、ZooKeeper 引入作為協(xié)調(diào)者等各種手段來解決 Availability 問題，然而當(dāng)網(wǎng)絡(luò)的 Split-Brain(Network Partition) 發(fā)生時(shí)，它還是無法完全解決 Availability 的問題。從這個(gè)角度上，Cassandra 選擇了 A，即它在網(wǎng)絡(luò) Split-Brain 時(shí)還是能正常寫，而使用其他技術(shù)來解決 Consistency 的問題，如讀的時(shí)候觸發(fā) Consistency 判斷和處理。這是設(shè)計(jì)上的限制。
從實(shí)現(xiàn)上的優(yōu)點(diǎn)：

HBase 采用強(qiáng)一致性模型，在一個(gè)寫返回后，保證所有的讀都讀到相同的數(shù)據(jù)。

通過 HRegion 動(dòng)態(tài) Split 和 Merge 實(shí)現(xiàn)自動(dòng)擴(kuò)展，并使用 HDFS 提供的多個(gè)數(shù)據(jù)備份功能，實(shí)現(xiàn)高可用性。

采用 HRegionServer 和 DataNode 運(yùn)行在相同的服務(wù)器上實(shí)現(xiàn)數(shù)據(jù)的本地化，提升讀寫性能，并減少網(wǎng)絡(luò)壓力。

內(nèi)建 HRegionServer 的宕機(jī)自動(dòng)恢復(fù)。采用 WAL 來 Replay 還未持久化到 HDFS 的數(shù)據(jù)。

可以無縫的和 Hadoop/MapReduce 集成。

實(shí)現(xiàn)上的缺點(diǎn)：

WAL 的 Replay 過程可能會(huì)很慢。

災(zāi)難恢復(fù)比較復(fù)雜，也會(huì)比較慢。

Major Compaction 會(huì)引起 IO Storm。

“怎么掌握 HBase 架構(gòu)”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注丸趣 TV 網(wǎng)站，丸趣 TV 小編將為大家輸出更多高質(zhì)量的實(shí)用文章！