1. 程式人生 > >淺談HBase的資料分佈

淺談HBase的資料分佈

資料分佈問題簡述

分散式產生的根源是“規模”,規模可理解為計算和儲存的需求。當單機能力無法承載日益增長的計算儲存需求時,就要尋求對系統的擴充套件方法。通常有兩種擴充套件方式:提升單機能力(scale up),增加機器(scale out,水平擴充套件)。限於硬體技術,單機能力的提升在一個階段內是有上限的;而水平擴充套件在理論上可以是無限的,同時,也更廉價、更容易落地。水平擴充套件可以通過快速、簡單的“加機器”,有效解決業務快速增長的問題,這幾乎是現代分散式系統必備的能力。對於爆發式增長的業務,水平擴充套件似乎是唯一可選擇的方案。

對於儲存系統而言,原本儲存在一臺機器上的資料,現在要存放在多臺機器上。此時必須解決兩個問題:分片,複製。

l  資料分片(sharding),又稱分割槽(partition),將資料集“合理的”拆分成多個分片,每臺機器負責其中若干個分片。以此來突破單機容量的限制,同時也提升了整體的訪問能力。另外,分片也降低了單個分片故障的影響範圍。

l  資料複製(replica),也叫“副本”。分片無法解決單機故障丟資料的問題,所以,必然要通過冗餘來解決系統高可用的問題。同時,副本機制也是提升系統吞吐、解決熱點問題的重要手段。

分片和副本是正交的,這意味著我們可以只使用其中一種或都使用,但通常都是同時使用的。因為分片解決的是規模和擴充套件性的問題,副本解決可靠、可用性的問題。對於一個生產可用的系統,二者必須同時具備。

從使用者/客戶端的角度看,分片和副本可以歸結為同一個問題:請求路由,即請求應該傳送給哪臺機器來處理。

l  讀資料時,能通過某種機制來確保有一個合適的分片/副本來提供服務

l  寫資料時,能通過同樣的機制來確保寫到一個合適的地方,並確保副本的一致性

無論客戶端的請求是直達服務端(如HBase/cassandra),還是通過代理(如公有云上的基於gateway的訪問方式),請求路由都是分散式系統必須解決的問題。

無論是分片還是副本,本質上都是資料分佈的體現。下面我們來看HBase的資料分佈模型。

HBase的資料分佈模型

HBase的資料分片按表進行,以行為粒度,基於rowkey範圍進行拆分,每個分片稱為一個region。一個叢集有多張表,每張表劃分為多個region,每臺伺服器服務很多region。所以,HBase的伺服器稱為RegionServer,簡稱RS。RS與表是正交的,即一張表的region會分佈到多臺RS上,一臺RS也會排程多張表的region。如下圖所示:

image.png

以行為粒度”,意思是行是region劃分的最小單位,即一行資料要麼屬於A region,要麼屬於Bregion,不會被拆到兩個region中去。(對行進行拆分的方式是“垂直分庫”,通常只能在業務層面進行,HBase是水平拆分)

HBase的副本機制是通過通過底層的HDFS實現的。所以,HBase的副本與分片是解耦的,是儲存計算分離的。這使得region可以在RS之間靈活的移動,而不需要進行資料遷移,這賦予了HBase秒級擴容的能力和極大的靈活性。

對於單個表而言,一個“好”的資料分佈,應該是每個region的資料量大小相近,請求量(吞吐)接近,每臺機器排程的region數量大致相同。這樣,這張表的資料和訪問能夠均勻的分佈在整個叢集中,從而得到最好的資源利用率和服務質量,即達到負載均衡。當叢集進行擴容、縮容時,我們希望這種“均衡”能夠自動保持。如果資料分佈未能實現負載均衡,則負載較高的機器很容易稱為整個系統的瓶頸,這臺機器的響應慢,可能導致客戶端的大部分執行緒都在等待這臺機器返回,從而影響整體吞吐。所以,負載均衡是region劃分和排程的重要目標。

這裡涉及到3層面的負載均衡問題:

l  資料的邏輯分佈:即region劃分/分佈,是rowkey到region的對映問題

l  資料的物理分佈:即region在RS上的排程問題

l  訪問的分佈:即系統吞吐(請求)在各個RS上的分佈問題,涉及資料量和訪問量之間的關係,訪問熱點等。

可見,一行資料的分佈(找到一行資料所在的RS),存在2個層級的路由:一是rowkey到region的路由,二是region到RS的路由。這一點是HBase能夠實現靈活排程、秒級擴容的關鍵。後面我們會詳細討論。本文僅討論前面兩個問題,第三個問題放在後續的文章中討論。

基於rowkey範圍的region劃分

首先,我們來看資料的邏輯分佈,即一張表如何劃分成多個region。

region劃分的粒度是行,region就是這個表中多個連續的行構成的集合。行的唯一識別符號是rowkey,所以,可以將region理解為一段連續分佈的rowkey的集合。所以,稱這種方式為基於rowkey範圍的劃分。

一個region負責的rowkey範圍是一個左閉右開區間,所以,後一個region的start key是前一個region的end key。注意,第一個region是沒有start key的,最後一個region是沒有end key的。這樣,這個表的所有region加在一起就能覆蓋任意的rowkey值域。如下圖所示:

image.png

上圖中,region1是第一個region,沒有startKey,region3是最後一個region,沒有endKey。圖中的region分佈是比較均勻的,即每個region的行數是相當的,那麼,這個分佈是怎麼得到的呢?或者說,region的邊界是如何確定的?

一般來說,region的生成有3種方式:

l  建表時進行預分割槽:通過對rowkey進行預估,預先劃分好region

l  region分裂:手工分裂,或達到一定條件時自動分裂(如region大小超過一個閾值)

l  region合併:手工合併

建表時如果未顯式指定region分佈,HBase就會只建立一個region,這個region自然也只能由一臺機器進行排程(後面會討論一個region由多個RS排程的情況)。那這個region的吞吐上限就是單機的吞吐上限。如果通過合理的預分割槽將表分成8個region,分佈在8臺RS上,那整表的吞吐上限就是8臺機器的吞吐上限。

所以,為了使表從一開始就具備良好的吞吐和效能,實際生產環境中建表通常都需要進行預分割槽。但也有一些例外,比如無法預先對rowkey範圍進行預估,或者,不容易對rowkey範圍進行均勻的拆分,此時,也可以建立只有一個region的表,由系統自己分裂,從而逐漸形成一個“均勻的”region分佈。

比如一張儲存多個公司的員工資訊的表,rowkey組成是orgId + userid,其中orgId是公司的id。由於每個公司的人數是不確定的,同時也可能是差別很大的,所以,很難確定一個region中包含幾個orgId是合適的。此時,可以為其建立單region的表,然後匯入初始資料,隨著資料的匯入進行region的自動分裂,通常都能得到比較理想的region分佈。如果後續公司人員發生較大的變化,也可以隨時進行region的分裂與合併,來獲得最佳分佈。

字典序與rowkey比較

上一節我們提到region的rowkey範圍是一個左閉右開區間,所有落在這個範圍的rowkey都屬於這個region。為了進行這個判斷,必須將其與這個region的起止rowkey進行比較。除了region歸屬的判斷,在region內部,也需要依賴rowkey的比較規則來對rowkey進行排序。

很多人都會認為rowkey的比較非常簡單,沒有什麼討論的必要。但正是因為簡單,它的使用才能靈活多樣,使得HBase具備無限的可能性。可以說,rowkey的比較規則是整個HBase資料模型的核心,直接影響了整個請求路由體系的設計、讀寫鏈路、rowkey設計、scan的使用等,貫穿整個HBase。對於使用者而言,深入理解這個規則及其應用有助於做出良好的表設計,寫出精準、高效的scan。

HBase的rowkey是一串二進位制資料,在Java中就是一個byte[],是一行資料的唯一識別符號。而業務的主鍵可能是有各種資料型別的,所以,這裡要解決2個問題:

l  將各種實際使用的資料型別與byte[]進行相互轉換

l  保序:byte[]形式的rowkey的排序結果與原始資料的排序結果一致

rowkey的比較就是byte[]的比較,按字典序進行比較(二進位制排序),簡單說,就是c語言中memcmp函式。通過下面的示例,我們通過排序結果來對這一比較規則以及資料型別轉換進行理解。

(1)ascii碼的大小比較
1234 -> 0x31 32 33 34
5 -> 0x35
從ascii碼錶示的數字來看,1234 > 5, 但從字典序來看,1234 < 5

(2)具有相同字首的ascii碼比較
1234     -> 0x31 32 33 34
12340 -> 0x31 32 33 34 00
在C語言中,字串一般是以0自己結尾的。本例的兩個字串雖然字首相同,但第二個末尾多了0位元組,則第二個“較大”。

(3)正數與負數的比較
int型別的100 -> 0x00 00 00 64
int型別的-100 -> 0xFF FF FF 9C
100 > -100,但其二進位制表達中,100 < -100

我們可以將這個比較規則總結如下:

l  從左到右逐個位元組進行比較,以第一個不同位元組的比較結果作為兩個byte[]的比較結果

l  位元組的比較是按無符號數方式進行的

l  不存在”比“存在”小

常見的rowkey編碼問題:

l  有符號數:二進位制表示中,有符號數的首bit是1,在字典序規則下,負數比正數大,所以,當rowkey的值域同時包含正數和負數時,需要對符號位進行反轉,以確保正數比負數大

l  倒序:通常用long來描述時間,一般都是倒排的,假設原始值是v,則v的倒序編碼是Long#MAX_VALUE - v。

下面通過一個字首掃描的案例來體會一下這個比較規則的應用。

示例:字首掃描

Hbase的rowkey可以理解為單一主鍵列。如果業務場景需要多列一起構成聯合主鍵(也叫多列主鍵,組合主鍵,複合主鍵等等),就需要將多列拼接為一列。一般來說,直接將二進位制拼接在一起即可。例如:

rowkey組成:userId + ts

為了簡單,假設userid和ts都是定長的,且只有1個位元組。例如:

image.png

現在,我們要做的事情是,查詢某個userid = 2的所有資料。這是一個典型的字首掃描場景,我們需要構造一個Scan操作來完成:設定正確掃描範圍[startRow, stopRow),與region的邊界一樣,scan的範圍也是一個左閉右開區間。

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

正確的scan範圍必須滿足:

l  startRow:必須必任何userId = 2的rowkey都小,且比任何userId = 1的rowkey都大

l  stopRow:必須必任何userId = 2的rowkey都大,且比任何userId = 3的rowkey都小

那如何利用rowkey的排序規則來“找到”這樣一個掃描範圍呢?

image.png

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

0x02比任何userid = 2的行都小。因為ts這一列是缺失的。同理,0x03比任何userid = 2的行都大,又比任何userId = 3的行都小。可見,要實現字首掃描,只根據字首的值就可以得到所需的startRow和stopRow,而不需要知道後面的列及其含義。

請讀者仔細體會這個例子,然後思考下面幾個場景該如何構造startRow和stopRow(答案見文末)。

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

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

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

l  where userid > 2 and userid < 4

還有下面這些組合場景:

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

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

現在,已經可以感受到使用scan的難點和痛點所在了。在上面的例子中,只有兩個定長的列,但在實際業務中,列可能是變長的,有各種各樣的資料型別,各種豐富的查詢模式。此時,構造一個正確、高效的scan是有難度的。那為什麼會有這些問題呢?有沒有系統性的解決方案呢?

從形式是看,這是一個“如何將業務查詢邏輯轉換為HBase的查詢邏輯”的問題,本質上是關係表模型到KV模型的對映問題。HBase僅提供了KV層的API,使得使用者不得不自己實現這兩個模型之間的轉換。所以,才會有上面這麼多的難點問題。不僅是HBase,所有的KV儲存系統在面臨複雜的業務模型時,都面臨相同的困境。

這個問題的解法是SQL on NoSQL,業界這類方案有很多(如Hive,presto等),HBase之上的方案就是Phoenix。此類方案通過引入SQL來解決NoSQL的易用性問題。對於傳統的關係型資料庫,雖然有強大的SQL和事務支援,但擴充套件性和效能受限,為了解決效能問題,MySQL提供了基於Memcached的KV訪問方式;為了解決擴充套件性問題,有了各種NewSQL的產品,如Spanner/F1,TiDB,CockroachDB等。NoSQL在做SQL,支援SQL的在做KV,我們可以想象一下未來的儲存、資料庫系統會是什麼樣子。這個話題很大,不在本文的討論範圍內,這裡就不展開了。

region的元資料管理與路由

前面我們討論了將一張表的行通過合理的region劃分,可以得到資料量大致接近的region分佈。通過合理的運維手段(region的分裂與合併),我們可以通保證在系統持續執行期間的region分佈均勻。此時,資料在邏輯上的拆分已經可以實現均勻。本節中我們看一下region如何分佈在RS上,以及客戶端如何定位region。

因為region的rowkey範圍本身的不確定性或者主觀性(人為拆分),無法通過一個數學公式來計算rowkey屬於哪個region(對比一致性hash的分片方式)。因此,基於範圍進行的分片方式,需要一個元資料表來記錄一個表被劃分為哪些region,每個region的起止rowkey是什麼。這個元資料表就是meta表,在HBase1.x版本中表名是“hbase:meta”(在094或更老的版本中,是-ROOT-和.META.兩個元資料表)。

我們從Put操作來簡要的瞭解region的定位過程。

l  ZK上找meta表所在的RS(快取)

l  到meta表上找rowkey所在的region及這個region所在的RS(快取)

l  發Put請求給這個RS,RS根據region名字來執行寫操作

l  如果RS發現這個region不在自己這裡,拋異常,客戶端重新路由

l    無論讀還是寫,其定位region的邏輯都是如此。為了降低客戶端對meta表的訪問,客戶端會快取region location資訊,當且僅當快取不正確時,才需要訪問meta表來獲取最新的資訊。所以,HBase的請求路由是一種基於路由表的解決方案。相對應的,基於一致性Hash的分片方式,則是通過計算來得到分佈資訊的。

這種基於路由表的方式

l  優點:region的歸屬RS可以任意更換,或者說,region在RS上的排程是靈活的、可人工干預的。

l  缺點:meta表是一個單點,其有限的吞吐限制了叢集的規模和客戶端數量

l  region的靈活排程,結合儲存計算分離的架構,賦予了HBase極其強大的能力。

l  秒級擴容:新加入的RS只需要移動region即可立即投產,不依賴資料的遷移(後續慢慢遷)

l  人工隔離:對於有問題的region(如熱點,有異常請求),可以手工移動到一臺單獨的RS上,進行故障域的快速隔離。

這兩點,是眾多基於一致性hash的分片方案無法做到的。當然,為了獲得這種靈活性,HBase所付出的代價就是複雜的meta表管理機制。其中比較關鍵的問題就是meta表的單點問題。例如:大量的客戶端都會請求meta表來獲取region location,meta表的負載較高,會限制獲取location的整體吞吐,從而限制叢集的規模和客戶端規模。

對於一個擁有數百臺機器,數十萬region的叢集來說,這套機制可以很好的工作。但當叢集規模進一步擴充套件,觸及到meta表的訪問上限時,就會因meta表的訪問阻塞而影響服務。當然,絕大多數的業務場景都是無法觸達這個臨界規模的。

meta表的問題可以有很多種解決思路,最簡單的方式就是副本。例如TiDB的PD服務,獲取location的請求可以傳送給任何一臺PD伺服器。

region的排程

下面我們討論region排程問題:

l  region在RS之間的負載均衡

l  同一個region在多個RS上排程

對於第一個問題,HBase的預設均衡策略是:以表為單位,每個RS上排程儘可能相同數量的region。

這個策略假設各個region的資料量分佈相對均勻,每個region的請求相對均勻。此時,該策略非常有效。這也是目前使用最多的一種。同時,HBase也提供了基於負載的排程(StochasticLoadBalancer),會綜合考慮多種因素來進行排程決策,不過,暫時缺少生產環境使用的案例和資料。

對於第二個問題,region同一時間只在一臺RS上排程,使得HBase在請求成功的情況下提供了強一致的語義,即寫成功的資料可以立即被讀到。其代價是region的單點排程,即region所在的伺服器因為各種原因產生抖動,都會影響這個region的服務質量。我們可將影響region服務的問題分為兩類:

l  不可預期的:宕機恢復,GC,網路問題,磁碟抖動,硬體問題等等

l  可預期的(或人為的):擴容/縮容導致的region移動,region split/merge等。

這些事件發生時,會對這個region的服務或多或少產生一些影響。尤其在宕機場景,從ZK發現節點宕機到region的re-assign,split log,log replay,一些列步驟執行完,一般都需要1分鐘以上的時間。對於宕機節點上的region,意味著這段時間這些region都無法服務。

解決方案依然是副本方案,讓region在多個RS上排程,客戶端選擇其中一個進行訪問,這個特性叫“region replia”。引入副本必然帶來額外的成本和一致性問題。目前這個特性的實現並未降低MTTR時間,記憶體水位的控制、髒讀,使得這個特性仍未在生產中大規模使用。

總結

Hbase的資料分佈與region排程問題,放大到整個分散式系統中,是任務的拆分與排程問題,這個話題的內涵大到足以寫幾本書。本文只是從HBase這個切面來對資料分片這個話題進行一些討論,希望能夠加深讀者對HBase rowkey和region概念的思考和理解,無論是資料庫的使用者還是開發,都能夠從這個討論中有所收穫。

附錄

正文中一些查詢場景所對應的scan range:

l  where userid = 2 and ts >= 5 and ts < 20: [0x02 05, 0x02 14)

l  where userid = 2 and ts > 5 and ts < 20: [0x02 06, 0x02 14)

l  where userid = 2 and ts > 5 and ts <= 20: [0x02 06, 0x02 15)

l  where userid > 2 and userid < 5: [0x03, 0x05)