Hbase原理詳解

各位看官，下面跟著小二一起開始hbase原理的冒險之旅吧，坐穩了，go~

先上一張官方

首先指出的乙個錯誤，hlog應該屬於hregionserver的，不應該在hregion中。

hbase基本元件說明：

client 包含訪問hbase的介面，並維護cache來加快對hbase的訪問，比如region的位置資訊

master 為region server分配region 負責region server的負載均衡 發現失效的region

server並重新分配其上的region 管理使用者對table的增刪改查操作

region server regionserver維護region，處理對這些region的io請求

regionserver負責切分在執行過程中變得過大的region

zookeeper作用 通過選舉，保證任何時候，集群中只有乙個master，master與regionservers

啟動時會向zookeeper註冊 存貯所有region的定址入口 實時監控region

server的上線和下線資訊。並實時通知給master 儲存hbase的schema和table元資料

zookeeper的引入使得master不再是單點故障

hlog

該機制用於資料的容錯和恢復：

每個hregionserver中都有乙個hlog物件，hlog是乙個實現write ahead log的類，在每次使用者操作寫入memstore的同時，也會寫乙份資料到hlog檔案中（hlog檔案格式見後續），hlog檔案定期會滾動出新的，並刪除舊的檔案（已持久化到storefile中的資料）。當hregionserver意外終止後，hmaster會通過zookeeper感知到，hmaster首先會處理遺留的 hlog檔案，將其中不同region的log資料進行拆分，分別放到相應region的目錄下，然後再將失效的region重新分配，領取 到這些region的hregionserver在load region的過程中，會發現有歷史hlog需要處理，因此會replay hlog中的資料到memstore中，然後flush到storefiles，完成資料恢復(region就是storefiles，storefiles裡由hfile構成，hfile裡由hbase的data塊構成，乙個data塊裡面又有很多keyvalue對，每個keyvalue裡存了我們需要的值。

client寫入 -> 存入memstore，一直到memstore滿 -> flush成乙個storefile，直至增長到一定閾值 ->

出發compact合併操作 -> 多個storefile合併成乙個storefile，同時進行版本合併和資料刪除 ->

當storefiles compact後，逐步形成越來越大的storefile ->

單個storefile大小超過一定閾值後，觸發split操作，把當前region

split成2個region，region會下線，新split出的2個孩子region會被hmaster分配到相應的hregionserver

上。hbase只是增加資料，有所得更新和刪除操作，都是在compact階段做的，所以，使用者寫操作只需要進入到記憶體即可立即返回，從而保證i/o高效能。

hbase為列式儲存，table中所有行按照rowkwy字典順序排列。table在行方向上分割成多個hregion,乙個hregion對應一到多行。不同region可以分到不同的regionserver上(regionserver對應著物理節點)，另外同乙個hregion不會拆分到不同的regionserver上。乙個hregion有一到多個store組成，每個store對應乙個columns

family。每乙個store有乙個memstore和0至多個storefile組成，storefile以hfile儲存到hdfs上

上圖中有個細節那就是hfile對應著hdfs client,換句話說hfile是通過hdfs client

寫到hdfs上的，滿足hdfs檔案的所有性質

圖1：

client -> zookeeper -> -root- -> .meta. -> 使用者資料表 hbase 的資料字典: -root-

.meta. 這倆表被hbase shell 的list 命令過濾掉，不顯示，但是他們跟普通的hbase table 是一樣的。

.meta. 　表包含所有的使用者空間region列表，同時，以及regionserver的伺服器位址，.meta.也可以有多個region

-root- 記錄.meta.表的region的路徑資訊，但是，-root-只有乙個region zookeeper儲存了-root-表的位址和hmaster的位址，hregionserver也會把自己以ephemeral方式註冊到zookeeper中，使得hmaster可以隨時感知到各個hregionserver的健康狀態(這也就是為什麼官方圖中zk會去連線hmaster)。

所以client先連線zk，找到-

root-表的位置（meta-region-server），然後去hbase中找到這張表根據tablename、startkey找到相應的regoninfo，從而找到相應的.meta.的region所在的regionserver，從而找到目標表的資訊，最後去訪問目標表

需要注意的是：整個過程中並沒有涉及到masterserver，也就是說hbase日常的資料操作並不需要masterserver，不會造成masterserver的負擔。

未啟動hbase

啟動hbase

圖二：

首先是rowkey，rowkey由三部分組成：tablename, startkey 和

timestamp。rowkey儲存的內容我們又稱之為region的name。

表中最主要的family：info，info裡面包含三個column：regioninfo, server,

serverstartcode。其中regioninfo就是region的詳細資訊，包括startkey, endkey

以及每個family的資訊等等。server儲存的就是管理這個region的regionserver的位址。

所以當region被拆分、合併或者重新分配的時候，都需要來修改這張表的內容。

深入HBASE原理詳解

hbase讀資料流程 hbase元資料資訊.首先從zk中找到meta表的region資訊，然後meta表中的資料，meta表中儲存了使用者的region資訊 根據要查詢的namespace 表名和rowkey資訊，找到對應的真正儲存要查詢的資料的region資訊 找到這個region對應的regio...

HBase原理總結

在總結spark讀寫hbase的同時，也順便回顧了一下hbase的原理，同樣做個簡單的記錄。事實上，相關的總結網上超級多，寫的已經很到位了。本文一些內容會直接摘取相關參考資料，對原文作者表示感謝。網際網路的面試一般問的都比較細，尤其是簡歷裡提到過的一些大資料元件，都會問問底層原理，體系結構，有什麼好...

Hbase 讀寫 原理

客戶端讀取資訊流程 1 client要讀取資訊，先查詢下client 端的cache中是否存在資料，如果存在，剛直接返回資料。如果不存在，則進入到zookeeper，查詢到裡面的相應資料存在的root表中的位址。2 blockcache 設計用於讀入記憶體頻繁訪問的資料，每個列族都有 3 通過資料存...