這篇文章主要為大家展示了“HBase中數(shù)據(jù)分布模型是怎么樣的”，內(nèi)容簡(jiǎn)而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領(lǐng)大家一起研究并學(xué)習(xí)一下“HBase中數(shù)據(jù)分布模型是怎么樣的”這篇文章吧。

創(chuàng)新互聯(lián)建站長(zhǎng)期為上1000+客戶提供的網(wǎng)站建設(shè)服務(wù)，團(tuán)隊(duì)從業(yè)經(jīng)驗(yàn)10年，關(guān)注不同地域、不同群體，并針對(duì)不同對(duì)象提供差異化的產(chǎn)品和服務(wù)；打造開放共贏平臺(tái)，與合作伙伴共同營(yíng)造健康的互聯(lián)網(wǎng)生態(tài)環(huán)境。為德陽(yáng)企業(yè)提供專業(yè)的網(wǎng)站設(shè)計(jì)、成都網(wǎng)站制作，德陽(yáng)網(wǎng)站改版等技術(shù)服務(wù)。擁有十多年豐富建站經(jīng)驗(yàn)和眾多成功案例,為您定制開發(fā)。

數(shù)據(jù)分布問題簡(jiǎn)述

分布式產(chǎn)生的根源是“規(guī)?！保?guī)?？衫斫鉃橛?jì)算和存儲(chǔ)的需求。當(dāng)單機(jī)能力無法承載日益增長(zhǎng)的計(jì)算存儲(chǔ)需求時(shí)，就要尋求對(duì)系統(tǒng)的擴(kuò)展方法。通常有兩種擴(kuò)展方式：提升單機(jī)能力(scale up)，增加機(jī)器(scale out，水平擴(kuò)展)。限于硬件技術(shù)，單機(jī)能力的提升在一個(gè)階段內(nèi)是有上限的;而水平擴(kuò)展在理論上可以是無限的，同時(shí)，也更廉價(jià)、更容易落地。水平擴(kuò)展可以通過快速、簡(jiǎn)單的“加機(jī)器”，有效解決業(yè)務(wù)快速增長(zhǎng)的問題，這幾乎是現(xiàn)代分布式系統(tǒng)必備的能力。對(duì)于爆發(fā)式增長(zhǎng)的業(yè)務(wù)，水平擴(kuò)展似乎是唯一可選擇的方案。

對(duì)于存儲(chǔ)系統(tǒng)而言，原本存儲(chǔ)在一臺(tái)機(jī)器上的數(shù)據(jù)，現(xiàn)在要存放在多臺(tái)機(jī)器上。此時(shí)必須解決兩個(gè)問題：分片，復(fù)制。

• 數(shù)據(jù)分片(sharding)，又稱分區(qū)(partition)，將數(shù)據(jù)集“合理的”拆分成多個(gè)分片，每臺(tái)機(jī)器負(fù)責(zé)其中若干個(gè)分片。以此來突破單機(jī)容量的限制，同時(shí)也提升了整體的訪問能力。另外，分片也降低了單個(gè)分片故障的影響范圍。

• 數(shù)據(jù)復(fù)制(replica)，也叫“副本”。分片無法解決單機(jī)故障丟數(shù)據(jù)的問題，所以，必然要通過冗余來解決系統(tǒng)高可用的問題。同時(shí)，副本機(jī)制也是提升系統(tǒng)吞吐、解決熱點(diǎn)問題的重要手段。

分片和副本是正交的，這意味著我們可以只使用其中一種或都使用，但通常都是同時(shí)使用的。因?yàn)榉制鉀Q的是規(guī)模和擴(kuò)展性的問題，副本解決可靠、可用性的問題。對(duì)于一個(gè)生產(chǎn)可用的系統(tǒng)，二者必須同時(shí)具備。

從使用者/客戶端的角度看，分片和副本可以歸結(jié)為同一個(gè)問題：請(qǐng)求路由，即請(qǐng)求應(yīng)該發(fā)送給哪臺(tái)機(jī)器來處理。

• 讀數(shù)據(jù)時(shí)，能通過某種機(jī)制來確保有一個(gè)合適的分片/副本來提供服務(wù)

• 寫數(shù)據(jù)時(shí)，能通過同樣的機(jī)制來確保寫到一個(gè)合適的地方，并確保副本的一致性

無論客戶端的請(qǐng)求是直達(dá)服務(wù)端(如HBase/cassandra)，還是通過代理(如公有云上的基于gateway的訪問方式)，請(qǐng)求路由都是分布式系統(tǒng)必須解決的問題。

無論是分片還是副本，本質(zhì)上都是數(shù)據(jù)分布的體現(xiàn)。下面我們來看HBase的數(shù)據(jù)分布模型。

HBase的數(shù)據(jù)分布模型

HBase的數(shù)據(jù)分片按表進(jìn)行，以行為粒度，基于rowkey范圍進(jìn)行拆分，每個(gè)分片稱為一個(gè)region。一個(gè)集群有多張表，每張表劃分為多個(gè)region，每臺(tái)服務(wù)器服務(wù)很多region。所以，HBase的服務(wù)器稱為RegionServer，簡(jiǎn)稱RS。RS與表是正交的，即一張表的region會(huì)分布到多臺(tái)RS上，一臺(tái)RS也會(huì)調(diào)度多張表的region。如下圖所示：

“以行為粒度”，意思是行是region劃分的最小單位，即一行數(shù)據(jù)要么屬于A region，要么屬于Bregion，不會(huì)被拆到兩個(gè)region中去。(對(duì)行進(jìn)行拆分的方式是“垂直分庫(kù)”，通常只能在業(yè)務(wù)層面進(jìn)行，HBase是水平拆分)

HBase的副本機(jī)制是通過通過底層的HDFS實(shí)現(xiàn)的。所以，HBase的副本與分片是解耦的，是存儲(chǔ)計(jì)算分離的。這使得region可以在RS之間靈活的移動(dòng)，而不需要進(jìn)行數(shù)據(jù)遷移，這賦予了HBase秒級(jí)擴(kuò)容的能力和極大的靈活性。

對(duì)于單個(gè)表而言，一個(gè)“好”的數(shù)據(jù)分布，應(yīng)該是每個(gè)region的數(shù)據(jù)量大小相近，請(qǐng)求量(吞吐)接近，每臺(tái)機(jī)器調(diào)度的region數(shù)量大致相同。這樣，這張表的數(shù)據(jù)和訪問能夠均勻的分布在整個(gè)集群中，從而得到最好的資源利用率和服務(wù)質(zhì)量，即達(dá)到負(fù)載均衡。當(dāng)集群進(jìn)行擴(kuò)容、縮容時(shí)，我們希望這種“均衡”能夠自動(dòng)保持。如果數(shù)據(jù)分布未能實(shí)現(xiàn)負(fù)載均衡，則負(fù)載較高的機(jī)器很容易稱為整個(gè)系統(tǒng)的瓶頸，這臺(tái)機(jī)器的響應(yīng)慢，可能導(dǎo)致客戶端的大部分線程都在等待這臺(tái)機(jī)器返回，從而影響整體吞吐。所以，負(fù)載均衡是region劃分和調(diào)度的重要目標(biāo)。

這里涉及到3層面的負(fù)載均衡問題：

• 數(shù)據(jù)的邏輯分布：即region劃分/分布，是rowkey到region的映射問題

• 數(shù)據(jù)的物理分布：即region在RS上的調(diào)度問題

• 訪問的分布：即系統(tǒng)吞吐(請(qǐng)求)在各個(gè)RS上的分布問題，涉及數(shù)據(jù)量和訪問量之間的關(guān)系，訪問熱點(diǎn)等。

可見，一行數(shù)據(jù)的分布(找到一行數(shù)據(jù)所在的RS)，存在2個(gè)層級(jí)的路由：一是rowkey到region的路由，二是region到RS的路由。這一點(diǎn)是HBase能夠?qū)崿F(xiàn)靈活調(diào)度、秒級(jí)擴(kuò)容的關(guān)鍵。后面我們會(huì)詳細(xì)討論。本文僅討論前面兩個(gè)問題，第三個(gè)問題放在后續(xù)的文章中討論。

基于rowkey范圍的region劃分

首先，我們來看數(shù)據(jù)的邏輯分布，即一張表如何劃分成多個(gè)region。

region劃分的粒度是行，region就是這個(gè)表中多個(gè)連續(xù)的行構(gòu)成的集合。行的唯一標(biāo)識(shí)符是rowkey，所以，可以將region理解為一段連續(xù)分布的rowkey的集合。所以，稱這種方式為基于rowkey范圍的劃分。

一個(gè)region負(fù)責(zé)的rowkey范圍是一個(gè)左閉右開區(qū)間，所以，后一個(gè)region的start key是前一個(gè)region的end key。注意，第一個(gè)region是沒有start key的，最后一個(gè)region是沒有end key的。這樣，這個(gè)表的所有region加在一起就能覆蓋任意的rowkey值域。如下圖所示：

上圖中，region1是第一個(gè)region，沒有startKey，region3是最后一個(gè)region，沒有endKey。圖中的region分布是比較均勻的，即每個(gè)region的行數(shù)是相當(dāng)?shù)?，那么，這個(gè)分布是怎么得到的呢?或者說，region的邊界是如何確定的?

一般來說，region的生成有3種方式：

• 建表時(shí)進(jìn)行預(yù)分區(qū)：通過對(duì)rowkey進(jìn)行預(yù)估，預(yù)先劃分好region

• region分裂：手工分裂，或達(dá)到一定條件時(shí)自動(dòng)分裂(如region大小超過一個(gè)閾值)

• region合并：手工合并

建表時(shí)如果未顯式指定region分布，HBase就會(huì)只創(chuàng)建一個(gè)region，這個(gè)region自然也只能由一臺(tái)機(jī)器進(jìn)行調(diào)度(后面會(huì)討論一個(gè)region由多個(gè)RS調(diào)度的情況)。那這個(gè)region的吞吐上限就是單機(jī)的吞吐上限。如果通過合理的預(yù)分區(qū)將表分成8個(gè)region，分布在8臺(tái)RS上，那整表的吞吐上限就是8臺(tái)機(jī)器的吞吐上限。

所以，為了使表從一開始就具備良好的吞吐和性能，實(shí)際生產(chǎn)環(huán)境中建表通常都需要進(jìn)行預(yù)分區(qū)。但也有一些例外，比如無法預(yù)先對(duì)rowkey范圍進(jìn)行預(yù)估，或者，不容易對(duì)rowkey范圍進(jìn)行均勻的拆分，此時(shí)，也可以創(chuàng)建只有一個(gè)region的表，由系統(tǒng)自己分裂，從而逐漸形成一個(gè)“均勻的”region分布。

比如一張存儲(chǔ)多個(gè)公司的員工信息的表，rowkey組成是orgId + userid，其中orgId是公司的id。由于每個(gè)公司的人數(shù)是不確定的，同時(shí)也可能是差別很大的，所以，很難確定一個(gè)region中包含幾個(gè)orgId是合適的。此時(shí)，可以為其創(chuàng)建單region的表，然后導(dǎo)入初始數(shù)據(jù)，隨著數(shù)據(jù)的導(dǎo)入進(jìn)行region的自動(dòng)分裂，通常都能得到比較理想的region分布。如果后續(xù)公司人員發(fā)生較大的變化，也可以隨時(shí)進(jìn)行region的分裂與合并，來獲得最佳分布。

字典序與rowkey比較

上一節(jié)我們提到region的rowkey范圍是一個(gè)左閉右開區(qū)間，所有落在這個(gè)范圍的rowkey都屬于這個(gè)region。為了進(jìn)行這個(gè)判斷，必須將其與這個(gè)region的起止rowkey進(jìn)行比較。除了region歸屬的判斷，在region內(nèi)部，也需要依賴rowkey的比較規(guī)則來對(duì)rowkey進(jìn)行排序。

很多人都會(huì)認(rèn)為rowkey的比較非常簡(jiǎn)單，沒有什么討論的必要。但正是因?yàn)楹?jiǎn)單，它的使用才能靈活多樣，使得HBase具備無限的可能性。可以說，rowkey的比較規(guī)則是整個(gè)HBase數(shù)據(jù)模型的核心，直接影響了整個(gè)請(qǐng)求路由體系的設(shè)計(jì)、讀寫鏈路、rowkey設(shè)計(jì)、scan的使用等，貫穿整個(gè)HBase。對(duì)于用戶而言，深入理解這個(gè)規(guī)則及其應(yīng)用有助于做出良好的表設(shè)計(jì)，寫出精準(zhǔn)、高效的scan。

HBase的rowkey是一串二進(jìn)制數(shù)據(jù)，在Java中就是一個(gè)byte[]，是一行數(shù)據(jù)的唯一標(biāo)識(shí)符。而業(yè)務(wù)的主鍵可能是有各種數(shù)據(jù)類型的，所以，這里要解決2個(gè)問題：

• 將各種實(shí)際使用的數(shù)據(jù)類型與byte[]進(jìn)行相互轉(zhuǎn)換

• 保序：byte[]形式的rowkey的排序結(jié)果與原始數(shù)據(jù)的排序結(jié)果一致

rowkey的比較就是byte[]的比較，按字典序進(jìn)行比較(二進(jìn)制排序)，簡(jiǎn)單說，就是c語言中memcmp函數(shù)。通過下面的示例，我們通過排序結(jié)果來對(duì)這一比較規(guī)則以及數(shù)據(jù)類型轉(zhuǎn)換進(jìn)行理解。

(1)ascii碼的大小比較1234 -> 0x31 32 33 345 -> 0x35從ascii碼表示的數(shù)字來看，1234 > 5， 但從字典序來看，1234 < 5

(2)具有相同前綴的ascii碼比較1234 -> 0x31 32 33 3412340 -> 0x31 32 33 34 00在C語言中，字符串一般是以0自己結(jié)尾的。本例的兩個(gè)字符串雖然前綴相同，但第二個(gè)末尾多了0字節(jié)，則第二個(gè)“較大”。

(3)正數(shù)與負(fù)數(shù)的比較int類型的100 -> 0x00 00 00 64int類型的-100 -> 0xFF FF FF 9C100 > -100，但其二進(jìn)制表達(dá)中，100 < -100

我們可以將這個(gè)比較規(guī)則總結(jié)如下：

從左到右逐個(gè)字節(jié)進(jìn)行比較，以第一個(gè)不同字節(jié)的比較結(jié)果作為兩個(gè)byte[]的比較結(jié)果

字節(jié)的比較是按無符號(hào)數(shù)方式進(jìn)行的

“不存在”比“存在”小

常見的rowkey編碼問題：

有符號(hào)數(shù)：二進(jìn)制表示中，有符號(hào)數(shù)的首bit是1，在字典序規(guī)則下，負(fù)數(shù)比正數(shù)大，所以，當(dāng)rowkey的值域同時(shí)包含正數(shù)和負(fù)數(shù)時(shí)，需要對(duì)符號(hào)位進(jìn)行反轉(zhuǎn)，以確保正數(shù)比負(fù)數(shù)大

倒序：通常用long來描述時(shí)間，一般都是倒排的，假設(shè)原始值是v，則v的倒序編碼是Long#MAX_VALUE - v。

下面通過一個(gè)前綴掃描的案例來體會(huì)一下這個(gè)比較規(guī)則的應(yīng)用。

示例：前綴掃描

Hbase的rowkey可以理解為單一主鍵列。如果業(yè)務(wù)場(chǎng)景需要多列一起構(gòu)成聯(lián)合主鍵(也叫多列主鍵，組合主鍵，復(fù)合主鍵等等)，就需要將多列拼接為一列。一般來說，直接將二進(jìn)制拼接在一起即可。例如：

rowkey組成：userId + ts

為了簡(jiǎn)單，假設(shè)userid和ts都是定長(zhǎng)的，且只有1個(gè)字節(jié)。例如：

現(xiàn)在，我們要做的事情是，查找某個(gè)userid = 2的所有數(shù)據(jù)。這是一個(gè)典型的前綴掃描場(chǎng)景，我們需要構(gòu)造一個(gè)Scan操作來完成：設(shè)置正確掃描范圍[startRow, stopRow)，與region的邊界一樣，scan的范圍也是一個(gè)左閉右開區(qū)間。

一個(gè)直接的思路是找到最小和最大的ts，與userid = 2拼接，作為查詢范圍，即[0x02 00, 0x02 FF)。由于scan是左臂右開區(qū)間，則0x02 FF不會(huì)被作為結(jié)果返回。所以，這個(gè)方案不可行。

正確的scan范圍必須滿足：

startRow：必須必任何userId = 2的rowkey都小，且比任何userId = 1的rowkey都大

stopRow：必須必任何userId = 2的rowkey都大，且比任何userId = 3的rowkey都小

那如何利用rowkey的排序規(guī)則來“找到”這樣一個(gè)掃描范圍呢?

　　正確的掃描范圍是[0x02, 0x03)。

0x02比任何userid = 2的行都小。因?yàn)閠s這一列是缺失的。同理，0x03比任何userid = 2的行都大，又比任何userId = 3的行都小。可見，要實(shí)現(xiàn)前綴掃描，只根據(jù)前綴的值就可以得到所需的startRow和stopRow，而不需要知道后面的列及其含義。

請(qǐng)讀者仔細(xì)體會(huì)這個(gè)例子，然后思考下面幾個(gè)場(chǎng)景該如何構(gòu)造startRow和stopRow(答案見文末)。

where userid = 2 and ts >= 5 and ts < 20

where userid = 2 and ts > 5 and ts < 20

where userid = 2 and ts > 5 and ts <= 20

where userid > 2 and userid < 4

還有下面這些組合場(chǎng)景：

where userid in (3, 5, 7, 9)

where userid = 2 and ts in (10, 20, 30)

現(xiàn)在，已經(jīng)可以感受到使用scan的難點(diǎn)和痛點(diǎn)所在了。在上面的例子中，只有兩個(gè)定長(zhǎng)的列，但在實(shí)際業(yè)務(wù)中，列可能是變長(zhǎng)的，有各種各樣的數(shù)據(jù)類型，各種豐富的查詢模式。此時(shí)，構(gòu)造一個(gè)正確、高效的scan是有難度的。那為什么會(huì)有這些問題呢?有沒有系統(tǒng)性的解決方案呢?

從形式是看，這是一個(gè)“如何將業(yè)務(wù)查詢邏輯轉(zhuǎn)換為HBase的查詢邏輯”的問題，本質(zhì)上是關(guān)系表模型到KV模型的映射問題。HBase僅提供了KV層的API，使得用戶不得不自己實(shí)現(xiàn)這兩個(gè)模型之間的轉(zhuǎn)換。所以，才會(huì)有上面這么多的難點(diǎn)問題。不僅是HBase，所有的KV存儲(chǔ)系統(tǒng)在面臨復(fù)雜的業(yè)務(wù)模型時(shí)，都面臨相同的困境。

這個(gè)問題的解法是SQL on NOSQL，業(yè)界這類方案有很多(如Hive，presto等)，HBase之上的方案就是Phoenix。此類方案通過引入SQL來解決NoSQL的易用性問題。對(duì)于傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)，雖然有強(qiáng)大的SQL和事務(wù)支持，但擴(kuò)展性和性能受限，為了解決性能問題，MySQL提供了基于Memcached的KV訪問方式;為了解決擴(kuò)展性問題，有了各種NewSQL的產(chǎn)品，如Spanner/F1，TiDB，CockroachDB等。NoSQL在做SQL，支持SQL的在做KV，我們可以想象一下未來的存儲(chǔ)、數(shù)據(jù)庫(kù)系統(tǒng)會(huì)是什么樣子。這個(gè)話題很大，不在本文的討論范圍內(nèi)，這里就不展開了。

region的元數(shù)據(jù)管理與路由

前面我們討論了將一張表的行通過合理的region劃分，可以得到數(shù)據(jù)量大致接近的region分布。通過合理的運(yùn)維手段(region的分裂與合并)，我們可以通保證在系統(tǒng)持續(xù)運(yùn)行期間的region分布均勻。此時(shí)，數(shù)據(jù)在邏輯上的拆分已經(jīng)可以實(shí)現(xiàn)均勻。本節(jié)中我們看一下region如何分布在RS上，以及客戶端如何定位region。

因?yàn)閞egion的rowkey范圍本身的不確定性或者主觀性(人為拆分)，無法通過一個(gè)數(shù)學(xué)公式來計(jì)算rowkey屬于哪個(gè)region(對(duì)比一致性hash的分片方式)。因此，基于范圍進(jìn)行的分片方式，需要一個(gè)元數(shù)據(jù)表來記錄一個(gè)表被劃分為哪些region，每個(gè)region的起止rowkey是什么。這個(gè)元數(shù)據(jù)表就是meta表，在HBase1.x版本中表名是“hbase:meta”(在094或更老的版本中，是-ROOT-和.META.兩個(gè)元數(shù)據(jù)表)。

我們從Put操作來簡(jiǎn)要的了解region的定位過程。

ZK上找meta表所在的RS(緩存)

到meta表上找rowkey所在的region及這個(gè)region所在的RS(緩存)

發(fā)Put請(qǐng)求給這個(gè)RS，RS根據(jù)region名字來執(zhí)行寫操作

如果RS發(fā)現(xiàn)這個(gè)region不在自己這里，拋異常，客戶端重新路由

無論讀還是寫，其定位region的邏輯都是如此。為了降低客戶端對(duì)meta表的訪問，客戶端會(huì)緩存region location信息，當(dāng)且僅當(dāng)緩存不正確時(shí)，才需要訪問meta表來獲取最新的信息。所以，HBase的請(qǐng)求路由是一種基于路由表的解決方案。相對(duì)應(yīng)的，基于一致性Hash的分片方式，則是通過計(jì)算來得到分布信息的。

這種基于路由表的方式

優(yōu)點(diǎn)：region的歸屬RS可以任意更換，或者說，region在RS上的調(diào)度是靈活的、可人工干預(yù)的。

缺點(diǎn)：meta表是一個(gè)單點(diǎn)，其有限的吞吐限制了集群的規(guī)模和客戶端數(shù)量

region的靈活調(diào)度，結(jié)合存儲(chǔ)計(jì)算分離的架構(gòu)，賦予了HBase極其強(qiáng)大的能力。

秒級(jí)擴(kuò)容：新加入的RS只需要移動(dòng)region即可立即投產(chǎn)，不依賴數(shù)據(jù)的遷移(后續(xù)慢慢遷)

人工隔離：對(duì)于有問題的region(如熱點(diǎn)，有異常請(qǐng)求)，可以手工移動(dòng)到一臺(tái)單獨(dú)的RS上，進(jìn)行故障域的快速隔離。

這兩點(diǎn)，是眾多基于一致性hash的分片方案無法做到的。當(dāng)然，為了獲得這種靈活性，HBase所付出的代價(jià)就是復(fù)雜的meta表管理機(jī)制。其中比較關(guān)鍵的問題就是meta表的單點(diǎn)問題。例如：大量的客戶端都會(huì)請(qǐng)求meta表來獲取region location，meta表的負(fù)載較高，會(huì)限制獲取location的整體吞吐，從而限制集群的規(guī)模和客戶端規(guī)模。

對(duì)于一個(gè)擁有數(shù)百臺(tái)機(jī)器，數(shù)十萬region的集群來說，這套機(jī)制可以很好的工作。但當(dāng)集群規(guī)模進(jìn)一步擴(kuò)展，觸及到meta表的訪問上限時(shí)，就會(huì)因meta表的訪問阻塞而影響服務(wù)。當(dāng)然，絕大多數(shù)的業(yè)務(wù)場(chǎng)景都是無法觸達(dá)這個(gè)臨界規(guī)模的。

meta表的問題可以有很多種解決思路，最簡(jiǎn)單的方式就是副本。例如TiDB的PD服務(wù)，獲取location的請(qǐng)求可以發(fā)送給任何一臺(tái)PD服務(wù)器。

region的調(diào)度

下面我們討論region調(diào)度問題：

region在RS之間的負(fù)載均衡

同一個(gè)region在多個(gè)RS上調(diào)度

對(duì)于第一個(gè)問題，HBase的默認(rèn)均衡策略是：以表為單位，每個(gè)RS上調(diào)度盡可能相同數(shù)量的region。

這個(gè)策略假設(shè)各個(gè)region的數(shù)據(jù)量分布相對(duì)均勻，每個(gè)region的請(qǐng)求相對(duì)均勻。此時(shí)，該策略非常有效。這也是目前使用最多的一種。同時(shí)，HBase也提供了基于負(fù)載的調(diào)度(StochasticLoadBalancer)，會(huì)綜合考慮多種因素來進(jìn)行調(diào)度決策，不過，暫時(shí)缺少生產(chǎn)環(huán)境使用的案例和數(shù)據(jù)。

對(duì)于第二個(gè)問題，region同一時(shí)間只在一臺(tái)RS上調(diào)度，使得HBase在請(qǐng)求成功的情況下提供了強(qiáng)一致的語義，即寫成功的數(shù)據(jù)可以立即被讀到。其代價(jià)是region的單點(diǎn)調(diào)度，即region所在的服務(wù)器因?yàn)楦鞣N原因產(chǎn)生抖動(dòng)，都會(huì)影響這個(gè)region的服務(wù)質(zhì)量。我們可將影響region服務(wù)的問題分為兩類：

不可預(yù)期的：宕機(jī)恢復(fù)，GC，網(wǎng)絡(luò)問題，磁盤抖動(dòng)，硬件問題等等

可預(yù)期的(或人為的)：擴(kuò)容/縮容導(dǎo)致的region移動(dòng)，region split/merge等。

這些事件發(fā)生時(shí)，會(huì)對(duì)這個(gè)region的服務(wù)或多或少產(chǎn)生一些影響。尤其在宕機(jī)場(chǎng)景，從ZK發(fā)現(xiàn)節(jié)點(diǎn)宕機(jī)到region的re-assign，split log，log replay，一些列步驟執(zhí)行完，一般都需要1分鐘以上的時(shí)間。對(duì)于宕機(jī)節(jié)點(diǎn)上的region，意味著這段時(shí)間這些region都無法服務(wù)。

解決方案依然是副本方案，讓region在多個(gè)RS上調(diào)度，客戶端選擇其中一個(gè)進(jìn)行訪問，這個(gè)特性叫“region replia”。引入副本必然帶來額外的成本和一致性問題。目前這個(gè)特性的實(shí)現(xiàn)并未降低MTTR時(shí)間，內(nèi)存水位的控制、臟讀，使得這個(gè)特性仍未在生產(chǎn)中大規(guī)模使用。

以上是“HBase中數(shù)據(jù)分布模型是怎么樣的”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對(duì)大家有所幫助，如果還想學(xué)習(xí)更多知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

當(dāng)前文章：HBase中數(shù)據(jù)分布模型是怎么樣的
文章網(wǎng)址：http://chinadenli.net/article30/gdocso.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供做網(wǎng)站、網(wǎng)站策劃、網(wǎng)頁(yè)設(shè)計(jì)公司、網(wǎng)站排名、自適應(yīng)網(wǎng)站、App設(shè)計(jì)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)