在Hbase中,大部分的操作都是在RegionServer完成的,Client進行插入,刪除,查詢數據都需要先找到相應的RegionServer。什麼叫相應的RegionServer?就是管理你要操作的那個Region的RegionServer。Client本身並不知道哪個RegionServer管理哪個Region,那麼它是如何找到相應的RegionServer的?
如上圖所示爲HBase的存儲架構,直觀呈現了HBase的存儲,在此基礎上我們引入兩個特殊的概念:-ROOT-和.META.。這是什麼?它們是HBase的兩張內置表,從存儲結構和操作方法的角度來說,它們和其他HBase的表沒有任何區別,你可以認爲這就是兩張普通的表,對於普通表的操作對它們都適用。它們與衆不同的地方是HBase用它們來存貯一個重要的系統信息——Region的分佈情況以及每個Region的詳細信息。
好了,既然我們前面說到-ROOT-和.META.可以被看作是兩張普通的表,那麼它們和其他表一樣就應該有自己的表結構。沒錯,它們有自己的表結構,並且這兩張表的表結構是相同的,在分析源碼之後我將這個表結構大致的畫了出來:
-ROOT-和.META.表結構
我們來仔細分析一下這個結構,每條Row記錄了一個Region的信息。
首先是RowKey,RowKey由三部分組成:TableName, StartKey 和 TimeStamp。RowKey存儲的內容我們又稱之爲Region的Name。用來存放Region的文件夾的名字是RegionName的Hash值,因爲RegionName可能包含某些非法字符。現在你應該知道爲什麼RegionName會包含非法字符了吧,因爲StartKey是被允許包含任何值的。將組成RowKey的三個部分用逗號連接就構成了整個RowKey,這裏TimeStamp使用十進制的數字字符串來表示的。這裏有一個RowKey的例子:
Table1,RK10000,12345678
然後是表中最主要的Family:info,info裏面包含三個Column:regioninfo, server, serverstartcode。其中regioninfo就是Region的詳細信息,包括StartKey, EndKey 以及每個Family的信息等等。server存儲的就是管理這個Region的RegionServer的地址。所以當Region被拆分、合併或者重新分配的時候,都需要來修改這張表的內容。
到目前爲止我們已經學習了必須的背景知識,下面我們要正式開始介紹Client端尋找RegionServer的整個過程。我打算用一個假想的例子來學習這個過程,因此我先構建了假想的-ROOT-表和.META.表。
我們先來看.META.表,假設HBase中只有兩張用戶表:Table1和Table2,Table1非常大,被劃分成了很多Region,因此在.META.表中有很多條Row用來記錄這些Region。而Table2很小,只是被劃分成了兩個Region,因此在.META.中只有兩條Row用來記錄。這個表的內容看上去是這個樣子的:
.META.行記錄結構
現在假設我們要從Table2裏面查詢一條RowKey是RK10000的數據。那麼我們應該遵循以下步驟:
從.META.表裏面查詢哪個Region包含這條數據。
獲取管理這個Region的RegionServer地址。
連接這個RegionServer, 查到這條數據。
好,我們先來第一步。問題是.META.也是一張普通的表,我們需要先知道哪個RegionServer管理了.META.表,怎麼辦?有一個方法,我們把管理.META.表的RegionServer的地址放到ZooKeeper上面不就行了,這樣大家都知道了誰在管理.META.。
貌似問題解決了,但對於這個例子我們遇到了一個新問題。因爲Table1實在太大了,它的Region實在太多了,.META.爲了存儲這些Region信息,花費了大量的空間,自己也需要劃分成多個Region。這就意味着可能有多個RegionServer在管理.META.。怎麼辦?在ZooKeeper裏面存儲所有管理.META.的RegionServer地址讓Client自己去遍歷?HBase並不是這麼做的。
HBase的做法是用另外一個表來記錄.META.的Region信息,就和.META.記錄用戶表的Region信息一模一樣。這個表就是-ROOT-表。這也解釋了爲什麼-ROOT-和.META.擁有相同的表結構,因爲他們的原理是一模一樣的。
假設.META.表被分成了兩個Region,那麼-ROOT-的內容看上去大概是這個樣子的:
-ROOT-行記錄結構:
這麼一來Client端就需要先去訪問-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。這個地址被存在ZooKeeper中。默認的路徑是:
/hbase/root-region-server
等等,如果-ROOT-表太大了,要被分成多個Region怎麼辦?嘿嘿,HBase認爲-ROOT-表不會大到那個程度,因此-ROOT-只會有一個Region,這個Region的信息也是被存在HBase內部的。
現在讓我們從頭來過,我們要查詢Table2中RowKey是RK10000的數據。整個路由過程的主要代碼在org.apache.Hadoop.hbase.client.HConnectionManager.TableServers中:
private HRegionLocation locateRegion(final byte[] tableName,
final byte[] row, boolean useCache) throws IOException {
if (tableName == null || tableName.length == 0) {
throw new IllegalArgumentException("table name cannot be null or zero length");
}
if (Bytes.equals(tableName, ROOT_TABLE_NAME)) {
synchronized (rootRegionLock) {
// This block guards against two threads trying to find the root
// region at the same time. One will go do the find while the
// second waits. The second thread will not do find.
if (!useCache || rootRegionLocation == null) {
this.rootRegionLocation = locateRootRegion();
}
return this.rootRegionLocation;
}
} else if (Bytes.equals(tableName, META_TABLE_NAME)) {
return locateRegionInMeta(ROOT_TABLE_NAME, tableName, row, useCache, metaRegionLock);
} else {
// Region not in the cache – have to go to the meta RS
return locateRegionInMeta(META_TABLE_NAME, tableName, row, useCache, userRegionLock);
}
}
這是一個遞歸調用的過程:
獲取Table2,RowKey爲RK10000的RegionServer
=> 獲取.META.,RowKey爲Table2,RK10000的RegionServer
=> 獲取-ROOT-,RowKey爲.META.,Table2,RK10000,的RegionServer
=> 獲取-ROOT-的RegionServer
=> 從ZooKeeper得到-ROOT-的RegionServer
=> 從-ROOT-表中查到RowKey最接近(小於) .META.,Table2,RK10000的一條Row,並得到.META.的RegionServer
=> 從.META.表中查到RowKey最接近(小於)Table2,RK10000的一條Row,並得到Table2的RegionServer
=> 從Table2中查到RK10000的Row
到此爲止Client完成了路由RegionServer的整個過程,最後要提醒大家注意兩件事情:
在整個路由過程中並沒有涉及到MasterServer,也就是說HBase日常的數據操作並不需要MasterServer,不會造成MasterServer的負擔。
Client端並不會每次數據操作都做這整個路由過程,很多數據都會被Cache起來。至於如何Cache,則不在本文的討論範圍之內。
HBase使用三層結構來定位region:
•1、通過zk裏的文件/hbase/rs得到-ROOT-表的位置,-ROOT-表只有一個region。
•2、通過-ROOT-表查找.META.表的第一個表中相應的region的位置。其實-ROOT-表是.META.表的第一個region;.META.表中的每一個region在-ROOT-表中都是一行記錄。
•3、通過.META.表找到所要的用戶表region的位置。用戶表中的每個region在.META.表中都是一行記錄。
-ROOT-表永遠不會被分隔爲多個region,保證了最多需要三次跳轉,就能定位到任意的region。client會講查詢的位置信息保存緩存起來,緩存不會主動失效,因此如果client上的緩存全部失效,則需要進行6次網絡來回,才能定位到正確的region,其中蠶絲用來發現緩存失效,另外三次用來獲取位置信息。