HBase 系統架構及數據結構
一、基本概念
一個典型的Hbase Table 表如下:
1.1 Row Key (行鍵)
Row Key
是用來檢索記錄的主鍵。想要訪問HBase Table中的數據,只有以下三種方式:
- 通過指定的
Row Key
進行訪問; - 通過Row Key的range進行訪問,即訪問指定範圍內的行;
- 進行全表掃描。
Row Key
可以是任意字符串,存儲時數據按照Row Key
的字典序進行排序。這裏需要注意以下兩點:
- 因為字典序對Int排序的結果是1,10,100,11,12,13,14,15,16,17,18,19,2,20,21,…,9,91,92,93,94,95,96,97,98,99。如果你使用整型的字符串作為行鍵,那麼為了保持整型的自然序,行鍵必須用0作左填充。
- 行的一次讀寫操作時原子性的 (不論一次讀寫多少列)。
1.2 Column Family(列族)
HBase表中的每個列,都歸屬於某個列族。列族是表的Schema的一部分,所以列族需要在創建表時進行定義。列族的所有列都以列族名作為前綴,例如courses:history
,courses:math
都屬於courses
這個列族。
1.3 Column Qualifier (列限定符)
列限定符,你可以理解為是具體的列名,例如courses:history
,courses:math
都屬於courses
這個列族,它們的列限定符分別是history
和math
。需要注意的是列限定符不是表Schema的一部分,你可以在插入數據的過程中動態創建列。
1.4 Column(列)
HBase中的列由列族和列限定符組成,它們由:
(冒號)進行分隔,即一個完整的列名應該表述為列族名 :列限定符
。
1.5 Cell
Cell
是行,列族和列限定符的組合,並包含值和時間戳。你可以等價理解為關係型數據庫中由指定行和指定列確定的一個單元格,但不同的是HBase中的一個單元格是由多個版本的數據組成的,每個版本的數據用時間戳進行區分。
1.6 Timestamp(時間戳)
HBase 中通過row key
和column
確定的為一個存儲單元稱為Cell
。每個Cell
都保存着同一份數據的多個版本。版本通過時間戳來索引,時間戳的類型是 64位整型,時間戳可以由HBase在數據寫入時自動賦值,也可以由客戶顯式指定。每個Cell
中,不同版本的數據按照時間戳倒序排列,即最新的數據排在最前面。
二、存儲結構
2.1 Regions
HBase Table中的所有行按照Row Key
的字典序排列。HBase Tables 通過行鍵的範圍(row key range)被水平切分成多個Region
, 一個Region
包含了在start key 和 end key之間的所有行。
每個表一開始只有一個Region
,隨着數據不斷增加,Region
會不斷增大,當增大到一個閥值的時候,Region
就會等分為兩個新的Region
。當Table中的行不斷增多,就會有越來越多的Region
。
Region
是HBase中分佈式存儲和負載均衡的最小單元。這意味着不同的Region
可以分佈在不同的Region Server
上。但一個Region
是不會拆分到多個Server上的。
2.2 Region Server
Region Server
運行在HDFS的DataNode上。它具有以下組件:
- WAL(Write Ahead Log,預寫日誌):用於存儲尚未進持久化存儲的數據記錄,以便在發生故障時進行恢復。
- BlockCache:讀緩存。它將頻繁讀取的數據存儲在內存中,如果存儲不足,它將按照
最近最少使用原則
清除多餘的數據。 - MemStore:寫緩存。它存儲尚未寫入磁盤的新數據,並會在數據寫入磁盤之前對其進行排序。每個Region上的每個列族都有一個MemStore。
- HFile :將行數據按照Key\Values的形式存儲在文件系統上。
Region Server存取一個子表時,會創建一個Region對象,然後對錶的每個列族創建一個Store
實例,每個Store
會有 0 個或多個StoreFile
與之對應,每個StoreFile
則對應一個HFile
,HFile 就是實際存儲在HDFS上的文件。
三、Hbase系統架構
3.1 系統架構
HBase系統遵循Master/Salve架構,由三種不同類型的組件組成:
Zookeeper
- 保證任何時候,集群中只有一個Master;
- 存貯所有Region的尋址入口;
- 實時監控Region Server的狀態,將Region Server的上線和下線信息實時通知給Master;
- 存儲HBase的Schema,包括有哪些Table,每個Table有哪些Column Family等信息。
Master
- 為Region Server分配Region ;
- 負責Region Server的負載均衡 ;
- 發現失效的Region Server並重新分配其上的Region;
- GFS上的垃圾文件回收;
- 處理Schema的更新請求。
Region Server
- Region Server負責維護Master分配給它的Region ,並處理髮送到Region上的IO請求;
- Region Server負責切分在運行過程中變得過大的Region。
3.2 組件間的協作
HBase使用ZooKeeper作為分佈式協調服務來維護集群中的服務器狀態。 Zookeeper負責維護可用服務列表,並提供服務故障通知等服務:
- 每個Region Server都會在ZooKeeper上創建一個臨時節點,Master通過Zookeeper的Watcher機制對節點進行監控,從而可以發現新加入的Region Server或故障退出的Region Server;
- 所有Masters會競爭性地在Zookeeper上創建同一個臨時節點,由於Zookeeper只能有一個同名節點,所以必然只有一個Master能夠創建成功,此時該Master就是主Master,主Master會定期向Zookeeper發送心跳。備用Masters則通過Watcher機制對主HMaster所在節點進行監聽;
- 如果主Master未能定時發送心跳,則其持有的Zookeeper會話會過期,相應的臨時節點也會被刪除,這會觸發定義在該節點上的Watcher事件,使得備用的Master Servers得到通知。所有備用的Master Servers在接到通知后,會再次去競爭性地創建臨時節點,完成主Master的選舉。
四、數據的讀寫流程簡述
4.1 寫入數據的流程
- Client向Region Server提交寫請求;
- Region Server找到目標Region;
- Region檢查數據是否與Schema一致;
- 如果客戶端沒有指定版本,則獲取當前系統時間作為數據版本;
- 將更新寫入WAL Log;
- 將更新寫入Memstore;
- 判斷Memstore存儲是否已滿,如果存儲已滿則需要flush為Store Hfile文件。
更為詳細寫入流程可以參考:HBase - 數據寫入流程解析
4.2 讀取數據的流程
以下是客戶端首次讀寫HBase上數據的流程:
- 客戶端從Zookeeper獲取
META
表所在的Region Server; - 客戶端訪問
META
表所在的Region Server,從META
表中查詢到訪問行鍵所在的Region Server,之後客戶端將緩存這些信息以及META
表的位置; - 客戶端從行鍵所在的Region Server上獲取數據。
如果再次讀取,客戶端將從緩存中獲取行鍵所在的Region Server。這樣客戶端就不需要再次查詢META
表,除非Region移動導致緩存失效,這樣的話,則將會重新查詢並更新緩存。
注:META
表是HBase中一張特殊的表,它保存了所有Region的位置信息,META表自己的位置信息則存儲在ZooKeeper上。
更為詳細讀取數據流程參考:
HBase原理-數據讀取流程解析
HBase原理-遲到的‘數據讀取流程部分細節
參考資料
本篇文章內容主要參考自官方文檔和以下兩篇博客,圖片也主要引用自以下兩篇博客:
- HBase Architectural Components
- Hbase系統架構及數據結構
官方文檔:
- Apache HBase ™ Reference Guide
更多大數據系列文章可以參見個人 GitHub 開源項目: 大數據入門指南
【精選推薦文章】
如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站,提高曝光率!!
想要讓你的商品在網路上成為最夯、最多人討論的話題?
網頁設計公司推薦更多不同的設計風格,搶佔消費者視覺第一線
不管是台北網頁設計公司、台中網頁設計公司,全省皆有專員為您服務
想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師"嚨底家"!!