HBase架構(gòu)設(shè)計(jì)是怎樣的

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

Hadoop生態(tài)的分布式數(shù)據(jù)庫

1、什么是分布式數(shù)據(jù)庫？

從狹義的理解就是分布式關(guān)系型數(shù)據(jù)庫，主要特指目前熱門的NewSQL。

從廣義的理解，分庫分表的傳統(tǒng)關(guān)系型數(shù)據(jù)庫，傳統(tǒng)關(guān)系型數(shù)據(jù)庫集群，關(guān)系型數(shù)據(jù)庫的主從架構(gòu)，分布式KV數(shù)據(jù)庫（例如：HBase），分布式文檔數(shù)據(jù)庫（例如：MongoDB），分布式關(guān)系數(shù)據(jù)庫(例如：TiDB)等，統(tǒng)稱為分布式數(shù)據(jù)庫。

本文主要講Google一脈相承的Hadoop生態(tài)下的分布式數(shù)據(jù)庫架構(gòu)設(shè)計(jì)，以及傳統(tǒng)RDBMS與NoSQL的分布式環(huán)境下的一致性對(duì)比。

2、Hadoop HDFS的數(shù)據(jù)存儲(chǔ)模型

最早Google發(fā)明了GFS分布式文件系統(tǒng)，之后對(duì)應(yīng)的開源項(xiàng)目就是鼎鼎大名的Hadoop HDFS。

GFS/HDFS的特點(diǎn)表現(xiàn)在順序的、成塊的、無索引的向文件塊中寫入數(shù)據(jù)，并在集群環(huán)境中按塊(block)均勻分布存儲(chǔ)，使用時(shí)再根據(jù)MapReduce、Spark的并行任務(wù)，按塊批次的讀取分析。這樣就把寫入和并行讀取的性能發(fā)揮到了極致，具備了任何建立索引的數(shù)據(jù)庫都無法比擬的讀寫速度。

HDFS的數(shù)據(jù)寫入結(jié)構(gòu)示意圖

上圖是一個(gè)寫入HDFS數(shù)據(jù)的例子，我們需要知道HDFS這些事情：

• 需要寫入HDFS的文件會(huì)被分成數(shù)據(jù)塊，一個(gè)數(shù)據(jù)塊通常是64M或者128M。

• 數(shù)據(jù)塊在HDFS集群中默認(rèn)有三個(gè)副本，平均分配在不同的DataNode數(shù)據(jù)節(jié)點(diǎn)上。

• 由于HDFS的分布式架構(gòu)是中心化管理，因此并沒有數(shù)據(jù)節(jié)點(diǎn)主副的概念，只有順序的概念，所有數(shù)據(jù)節(jié)點(diǎn)都是存儲(chǔ)數(shù)據(jù)塊副本的，全部通過namenode節(jié)點(diǎn)安排數(shù)據(jù)節(jié)點(diǎn)的寫入順序。

• 數(shù)據(jù)節(jié)點(diǎn)的寫入過程就像一個(gè)數(shù)據(jù)管道，根據(jù)客戶端就近原則，形成數(shù)據(jù)節(jié)點(diǎn)的排隊(duì)，當(dāng)?shù)谝粋€(gè)節(jié)點(diǎn)寫入數(shù)據(jù)包后，然后再向數(shù)據(jù)管道的下一個(gè)數(shù)據(jù)節(jié)點(diǎn)復(fù)制，以此類推，并得到完成確認(rèn)。

3、HBase的架構(gòu)設(shè)計(jì)

為了更好的理解HBase/Bigtable，一定需要先鋪陳一下它們所依賴的分布式文件系統(tǒng)基礎(chǔ)環(huán)境，然后再看看這些巧奪天工的分布式數(shù)據(jù)庫設(shè)計(jì)如何形成的。

由于GFS/HDFS集群的高性能設(shè)計(jì)是建立在放棄隨機(jī)查找的基礎(chǔ)之上。那么如何既能擁有隨機(jī)查找的特性，又能充分利用好HDFS/GFS的集群優(yōu)勢(shì)，而且還能在分布式環(huán)境下，具備數(shù)據(jù)寫入的強(qiáng)一致性呢？這才涌現(xiàn)出了HBase/Bigtable這類基于分布式文件系統(tǒng)的分布式數(shù)據(jù)庫。

但大家要注意了，實(shí)際上HBase/Bigtable的隨機(jī)查找設(shè)計(jì)目標(biāo)并不是解決復(fù)雜的join關(guān)聯(lián)查找或二次索引范圍查找，而是實(shí)現(xiàn)簡單的一個(gè)K-V查詢模型，滿足海量數(shù)據(jù)的存放條件下，通過主鍵查找結(jié)果，能達(dá)到毫秒級(jí)響應(yīng)的數(shù)據(jù)庫。

HBase的數(shù)據(jù)寫入結(jié)構(gòu)示意圖

上圖就是HBase的寫入過程以及HDFS作為物理層支撐的架構(gòu)示意圖。

HBase按照LSM-Tree索引加上SSTable數(shù)據(jù)結(jié)構(gòu)建立了NoSQL常用的數(shù)據(jù)存儲(chǔ)模型。寫入過程分成了下面幾個(gè)部分：

• 客戶端向HBase的Region Server寫入數(shù)據(jù)，會(huì)首先進(jìn)入到WAL（Write-Ahead-Log）預(yù)寫日志中，然后再進(jìn)入到選擇的Region的MemStore中，那這個(gè)WAL的目的是什么呢？保命用的！因?yàn)橐坏㏑egion Server斷電或異常崩潰，MemStore的數(shù)據(jù)是在內(nèi)存里，肯定就丟了，MemStore恢復(fù)的時(shí)候就靠WAL存的日志數(shù)據(jù)了。MemStore真正同步數(shù)據(jù)后，WAL才會(huì)從本地寫入HDFS，否則回滾。

• Region的MemStore是一個(gè)放在內(nèi)存里的高速操作區(qū)，MVCC事務(wù)操作，最近寫入記錄讀取都可以在此處快速完成，當(dāng)數(shù)據(jù)在MemStore寫滿后，就會(huì)刷入到Store File磁盤存儲(chǔ)區(qū)。

• Store File存儲(chǔ)區(qū)就是不斷通過memstore刷盤而形成的HFile，每個(gè)HFile默認(rèn)分配128M，大小正好與HDFS的一個(gè)數(shù)據(jù)塊（block）一致，HFile的物理位置就是存儲(chǔ)在HDFS的每個(gè)數(shù)據(jù)塊中，HFile就是不可更改的了，并通過HDFS的副本機(jī)制，形成三副本保證數(shù)據(jù)的可靠性。

3、HDFS與HBase的協(xié)作配合

從上述的HDFS和HBase系統(tǒng)的配合中（GFS與BigTable同理）我們可以看到Hadoop生態(tài)體系設(shè)計(jì)的巧妙結(jié)構(gòu)：

• HDFS對(duì)于大文件塊的順序?qū)懭?，批量分析，HDFS的無索引、順序?qū)懭?、管道?fù)制機(jī)制充分體現(xiàn)了Google的暴力美學(xué)～解決問題的方式務(wù)實(shí)、簡單、直接、高效。

• HBase作為列簇設(shè)計(jì)的K-V數(shù)據(jù)庫，又實(shí)現(xiàn)了細(xì)膩入微的設(shè)計(jì)思想，通過LSM-Tree索引和SSTable數(shù)據(jù)結(jié)構(gòu)建立起原生數(shù)據(jù)庫存儲(chǔ)層。

• HBase機(jī)制上WAL、MemStore、StoreFile形成數(shù)據(jù)操作的多元素協(xié)作。

• HBase架構(gòu)上HRegion Server、HRegion、HLog、HStore層層嵌套，形成分布式數(shù)據(jù)庫的集群化能力。

最關(guān)鍵的就是HBase與HDFS的分工思想，HBase解決業(yè)務(wù)數(shù)據(jù)記錄寫入，K-V隨機(jī)查找（毫秒級(jí)），由Region Server控制的行級(jí)事務(wù)等一些列分布式數(shù)據(jù)庫特征；而HDFS解決小文件匯聚成大文件的高性能處理，分布式文件系統(tǒng)的海量存儲(chǔ)，數(shù)據(jù)多副本的可靠性，以及成為Mapreduce、Spark、Hive等其他框架與HBase之間協(xié)作的基礎(chǔ)平臺(tái)。

最后再說說有些NoSQL的弱一致性為什么就可以被接受? 

回顧一下最開始的MySQL的異步模式復(fù)制，它為什么是MySQL的默認(rèn)復(fù)制模式? 

若滿足最終一致性，那么這類分布式系統(tǒng)選擇了CAP定理中的AP，就是說為了保證系統(tǒng)內(nèi)部無論是否出錯(cuò)，都會(huì)給客戶響應(yīng)。代價(jià)就是分布式各節(jié)點(diǎn)的數(shù)據(jù)副本有可能不一致，但這個(gè)問題不是此類系統(tǒng)業(yè)務(wù)最在乎的事情，往往系統(tǒng)的高性能，并能為客戶端提供快速響應(yīng)力才是關(guān)鍵目標(biāo)，MySQL的默認(rèn)主從復(fù)制如此，有些NoSQL亦如此。

傳世的關(guān)系模型

首先從數(shù)據(jù)庫的表達(dá)力來講，并不是NoSQL要強(qiáng)于關(guān)系模型，事實(shí)上SQL的表達(dá)力是無出其右的，否則就不會(huì)興盛四十年而不衰，就不會(huì)有Hive SQL、Spark SQL、Presto、Impala這些以支持SQL交互為起點(diǎn)的NoSQL上層框架存在的必須性。

看吧，還沒到NewSQL這一代的時(shí)候，返祖的現(xiàn)象就已經(jīng)出現(xiàn)了！

1、我們?cè)贉毓手乱幌率裁词顷P(guān)系模型：

關(guān)系型模型之父Edgar F. Codd，在1970年Communications of ACM 上發(fā)表了《大型共享數(shù)據(jù)庫數(shù)據(jù)的關(guān)系模型》這就是永恒的經(jīng)典，關(guān)系模型的語義設(shè)計(jì)達(dá)到了40年來普世的易于理解，語法的嵌套，閉環(huán)，完整。

關(guān)系型模型之父Edgar F. Codd

原始的關(guān)系模型：

• 結(jié)構(gòu)（structure）結(jié)構(gòu)的主要特征就是關(guān)系（relation），表格就是實(shí)現(xiàn)形式關(guān)系定義在類型（type or domain）的基礎(chǔ)上，屬性（attribute）就是類型的實(shí)際值，N個(gè)屬性就是描述了N元關(guān)系每個(gè)關(guān)系都至少有一個(gè)候選鍵（唯一標(biāo)識(shí)符），它是屬性的組合，通常只有一個(gè)屬性。元組（tuple）就是屬性的集合

• 完整性（integrity）實(shí)體完整性規(guī)則：主鍵屬性不允許null，不能存在任何不匹配的外鍵取值。

• 操作（manipulation）關(guān)系的運(yùn)算符集合（限制、投影、積、交、并、差、連接），關(guān)系表達(dá)式賦值關(guān)系（例如：關(guān)系1 并 關(guān)系2賦值給關(guān)系3），操作的輸入關(guān)系和輸出關(guān)系，形成了閉包（closure）性質(zhì)，就可以寫出嵌套表達(dá)式

原始理論具體到實(shí)現(xiàn)再翻譯成我們好理解的描述：結(jié)構(gòu)、完整性、操作就構(gòu)成了現(xiàn)在傳統(tǒng)數(shù)據(jù)庫的關(guān)系模型。

結(jié)構(gòu)：就是我們經(jīng)常要先對(duì)數(shù)據(jù)庫預(yù)先定義的表名和字段（名稱、類型）

完整性：就是表的主鍵不能為空，表與表之間的主外鍵關(guān)聯(lián)必須保證是完整的，外鍵一定是能找到主鍵的。

操作：那就是SQL表達(dá)式啦，SQL的子查詢就是典型的閉包（Closure），可以形成嵌套表達(dá)式。

2、雖然NoSQL很火，但我們這個(gè)世界沒法 NO SQL

HBase/Bigtable可以認(rèn)為是NoSQL的典型代表

恰恰NoSQL發(fā)展至今，出現(xiàn)了Hive SQL，Spark SQL，Presto，Impala，直到基于Google Spanner論文的TIDB，CockroachDB等NewSQL的不斷涌現(xiàn)，才讓我們用實(shí)踐證明，無論是NoSQL也好，NewSQL也罷，它們的查詢語言客戶端又回到了SQL。

我們只是在大數(shù)據(jù)領(lǐng)域需要替換關(guān)系型數(shù)據(jù)庫的存儲(chǔ)邏輯，使得數(shù)據(jù)庫更分布式化，更容易實(shí)現(xiàn)擴(kuò)展。這是符合單機(jī)性能到了天花板后，必須橫向擴(kuò)展的硬需求，但這也并不是說關(guān)系模型就過時(shí)了！

像HBase/Bigtable這樣的NoSQL，大多數(shù)采用了LSM-Tree的索引機(jī)制，來替換RDBMS的B-Tree機(jī)制，這么做都是為了能實(shí)現(xiàn)內(nèi)存與磁盤，寫入與查找的更平衡利用。

它們又用數(shù)據(jù)分片的水平切分替換RDBMS的分庫分表的垂直切分，讓節(jié)點(diǎn)與集群的水平伸縮性更為自動(dòng)化，而不是像分庫分表那樣進(jìn)行人工復(fù)雜的介入。

TiDB這些NewSQL的出現(xiàn)恰恰是在縫合關(guān)系模型和分布式存儲(chǔ)之間的裂縫，面向客戶端依然是關(guān)系模型，強(qiáng)化分布式業(yè)務(wù)更新的強(qiáng)一致性(分布式事務(wù)，這是最難的最復(fù)雜的地方)，面向存儲(chǔ)則堅(jiān)定的選擇K-V模型。

例如TIDB的TIKV集群采用的就是rocksdb，rocksdb的底層索引機(jī)制又和HBase/Bigtable采用相同設(shè)計(jì)機(jī)制的又一個(gè)nosql成員。

因此并不是Google的Spanner論文以及F1,TiDB這些實(shí)現(xiàn)技術(shù)開了歷史的倒車，恰恰是對(duì)狂熱的nosql運(yùn)動(dòng)的一種反思，對(duì)成為經(jīng)典的SQL關(guān)系模型理論的一種認(rèn)真思考和融合。

任何新技術(shù)都是站在前輩的基礎(chǔ)上開啟的，我們總要回頭望望，反思新技術(shù)的運(yùn)用到底我們得到了什么，又失去了什么！

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