HBASE學習筆記--概述

定義：

HBase是一個分佈式的、面向列的開源數據庫,HBase是Google Bigtable的開源實現，它利用Hadoop HDFS做爲其文件存儲系統，利用Hadoop MapReduce來處理HBase中的海量數據，利用Zookeeper做爲協同服務。

 

 邏輯視圖：

　用戶對hbase中的數據在邏輯上經過rowkey,column family, cell ,timestamp進行管理

• Row Key

與nosql數據庫們同樣,row key是用來檢索記錄的主鍵。訪問hbase table中的行，只有三種方式：

 經過單個row key訪問

 經過row key的range

 全表掃描

 

存儲時，數據按照Row key的字典序(byte order)排序存儲。

 

• 列族 column family

hbase表中的每一個列，都歸屬與某個列族。列族是表的chema的一部分(而列不是)，必須在使用表以前定義。列名都以列族做爲前綴。例如courses:history ， courses:math 都屬於 courses 這個列族。

訪問控制、磁盤和內存的使用統計都是在列族層面進行的。

• 單元 Cell

HBase中經過row和columns肯定的爲一個存貯單元稱爲cell。由{row key, column( =<family> + <label>), version} 惟一肯定的單元。cell中的數據是沒有類型的，所有是字節碼形式存貯。時間戳能夠由hbase(在數據寫入時自動 )賦值，此時時間戳是精確到毫秒的當前系統時間。時間戳也能夠由客戶顯式賦值。若是應用程序要避免數據版本衝突，就必須本身生成具備惟一性的時間戳。每一個cell中，不一樣版本的數據按照時間倒序排序，即最新的數據排在最前面。

 

爲了不數據存在過多版本形成的的管理 (包括存貯和索引)負擔，hbase提供了兩種數據版本回收方式。一是保存數據的最後n個版本，二是保存最近一段時間內的版本（好比最近七天）。用戶能夠針對每一個列族進行設置。

 

• 時間戳 timestamp

每一個cell都保存着同一份數據的多個版本。版本經過時間戳來索引。時間戳的類型是 64位整型

 

物理存儲：

• 結構圖

 

 

 

• Regin:

HBase擴展和負載均衡的基本單位是Region。Region從本質上說是行的集合。當Region的大小達到必定的閾值，該Region會自動分裂(split)，固然也多是合併(merge)，合併能夠減小Region和相應存儲文件的數量

 

對於一張表(HTable)而言，初始時只會有一個Region。表的數據量不斷增長，系統會監控此表以確保數據量不會超過一個配置的閾值。若是系統發現表容量超過了限制，該Region會被一分爲二。分裂主要看行鍵(row key)，從Region正中的鍵開始分裂，並建立容量大體相等的兩個Region。

 

Region和Region Server的關係是多對一。一個Region只能位於一臺Region Server之上，而一臺Region Server能夠服務多個Region。

 

分裂和服務這些Region能夠視爲自動分片。HBase的設計考慮到Region的快速恢復和細粒度的負載均衡問題。當服務於某些Region的Region Server壓力過大、退役(decommission，這個概念以後會詳細闡述)或者乾脆出問題時，這些Region會被移動到其餘的Server上。

 

Region雖然是分佈式存儲的最小單元，但並非存儲的最小單元。

事實上，HRegion由一個或者多個Store組成，每一個store保存一個columns family。

每一個Strore由一個memStore和0至多個StoreFile組成。

 

 

 

• storeFile

StoreFile以HFile格式保存在HDFS上。

 

 

 

• Trailer部分的格式:

 

 

 

• HFile分爲六個部分：

Data Block 段–保存表中的數據，這部分能夠被壓縮
Meta Block 段 (可選的)–保存用戶自定義的kv對，能夠被壓縮。
File Info 段–Hfile的元信息，不被壓縮，用戶也能夠在這一部分添加本身的元信息。
Data Block Index 段–Data Block的索引。每條索引的key是被索引的block的第一條記錄的key。
Meta Block Index段 (可選的)–Meta Block的索引。
Trailer–這一段是定長的。保存了每一段的偏移量，讀取一個HFile時，會首先 讀取Trailer，Trailer保存了每一個段的起始位置(段的Magic Number用來作安全check)，而後，DataBlock Index會被讀取到內存中，這樣，當檢索某個key時，不須要掃描整個HFile，而只需從內存中找到key所在的block，經過一次磁盤io將整個 block讀取到內存中，再找到須要的key。DataBlock Index採用LRU機制淘汰。
HFile的Data Block，Meta Block一般採用壓縮方式存儲，壓縮以後能夠大大減小網絡IO和磁盤IO，隨之而來的開銷固然是須要花費cpu進行壓縮和解壓縮。
目標Hfile的壓縮支持兩種方式：Gzip，Lzo。

 

• HLog(WAL log)

WAL 意爲Write ahead log(http://en.wikipedia.org/wiki/Write-ahead_logging)，相似mysql中的binlog,用來 作災難恢復只用，Hlog記錄數據的全部變動,一旦數據修改，就能夠從log中進行恢復。
每一個Region Server維護一個Hlog,而不是每一個Region一個。這樣不一樣region(來自不一樣table)的日誌會混在一塊兒，這樣作的目的是不斷追加單個 文件相對於同時寫多個文件而言，能夠減小磁盤尋址次數，所以能夠提升對table的寫性能。帶來的麻煩是，若是一臺region server下線，爲了恢復其上的region，須要將region server上的log進行拆分，而後分發到其它region server上進行恢復。
HLog文件就是一個普通的Hadoop Sequence File，Sequence File 的Key是HLogKey對象，HLogKey中記錄了寫入數據的歸屬信息，除了table和region名字外，同時還包括 sequence number和timestamp，timestamp是」寫入時間」，sequence number的起始值爲0，或者是最近一次存入文件系統中sequence number。HLog Sequece File的Value是HBase的KeyValue對象，即對應HFile中的KeyValue

 

系統架構

• 架構圖

 

 

• Client

包含訪問hbase的接口，client維護着一些cache來加快對hbase的訪問，好比region的位置信息。

• Zookeeper

1 保證任什麼時候候，集羣中只有一個master
2 存貯全部Region的尋址入口。
3 實時監控Region Server的狀態，將Region server的上線和下線信息實時通知給Master
4 存儲Hbase的schema,包括有哪些table，每一個table有哪些column family

• Master

1 爲Region server分配region
2 負責region server的負載均衡
3 發現失效的region server並從新分配其上的region
4 GFS上的垃圾文件回收
5 處理schema更新請求

• Region Server

1 Region server維護Master分配給它的region，處理對這些region的IO請求
2 Region server負責切分在運行過程當中變得過大的region
能夠看到，client訪問hbase上數據的過程並不須要master參與（尋址訪問zookeeper和region server，數據讀寫訪問region server），master僅僅維護者table和region的元數據信息，負載很低。

 

region定位

 

系統如何找到某個row key (或者某個 row key range)所在的region
bigtable 使用三層相似B+樹的結構來保存region位置。
第一層是保存zookeeper裏面的文件，它持有root region的位置。
第二層root region是.META.表的第一個region其中保存了.META.表其它region的位置。經過root region，咱們就能夠訪問.META.表的數據。
.META是第三層，它是一個特殊的表，保存了hbase中全部數據表的region 位置信息。

說明：
1 root region永遠不會被split，保證了最須要三次跳轉，就能定位到任意region 。
2 .META.表每行保存一個region的位置信息，row key 採用表名+表的最後同樣編碼而成。
3 爲了加快訪問，.META.表的所有region都保存在內存中。
假設，.META.表的一行在內存中大約佔用1KB。而且每一個region限制爲128MB。
那麼上面的三層結構能夠保存的region數目爲：(128MB/1KB) * (128MB/1KB) = = 2(34)個region
4 client會將查詢過的位置信息保存緩存起來，緩存不會主動失效，所以若是client上的緩存所有失效，則須要進行6次網絡來回，才能定位到正確的region(其中三次用來發現緩存失效，另外三次用來獲取位置信息)。

 

讀寫過程

 

hbase使用MemStore和StoreFile存儲對錶的更新。
數據在更新時首先寫入Log(WAL log)和內存(MemStore)中，MemStore中的數據是排序的，當MemStore累計到必定閾值時，就會建立一個新的MemStore，並 且將老的MemStore添加到flush隊列，由單獨的線程flush到磁盤上，成爲一個StoreFile。於此同時，系統會在zookeeper中 記錄一個redo point，表示這個時刻以前的變動已經持久化了。(minor compact)
當系統出現意外時，可能致使內存(MemStore)中的數據丟失，此時使用Log(WAL log)來恢復checkpoint以後的數據。
前面提到過StoreFile是隻讀的，一旦建立後就不能夠再修改。所以Hbase的更 新實際上是不斷追加的操做。當一個Store中的StoreFile達到必定的閾值後，就會進行一次合併(major compact),將對同一個key的修改合併到一塊兒，造成一個大的StoreFile，當StoreFile的大小達到必定閾值後，又會對 StoreFile進行split，等分爲兩個StoreFile。
因爲對錶的更新是不斷追加的，處理讀請求時，須要訪問Store中所有的 StoreFile和MemStore，將他們的按照row key進行合併，因爲StoreFile和MemStore都是通過排序的，而且StoreFile帶有內存中索引，合併的過程仍是比較快。

 

• 寫請求處理過程

 

 

1 client向region server提交寫請求
2 region server找到目標region
3 region檢查數據是否與schema一致
4 若是客戶端沒有指定版本，則獲取當前系統時間做爲數據版本
5 將更新寫入WAL log
6 將更新寫入Memstore
7 判斷Memstore的是否須要flush爲Store文件。

 

server,master上下線及regin分配流程

• region分配

任什麼時候刻，一個region只能分配給一個region server。master記錄了當前有哪些可用的region server。以及當前哪些region分配給了哪些region server，哪些region尚未分配。當存在未分配的region，而且有一個region server上有可用空間時，master就給這個region server發送一個裝載請求，把region分配給這個region server。region server獲得請求後，就開始對此region提供服務。

• region server上線

master使用zookeeper來跟蹤region server狀態。當某個region server啓動時，會首先在zookeeper上的server目錄下創建表明本身的文件，並得到該文件的獨佔鎖。因爲master訂閱了server 目錄上的變動消息，當server目錄下的文件出現新增或刪除操做時，master能夠獲得來自zookeeper的實時通知。所以一旦region server上線，master能立刻獲得消息。

• region server下線

當region server下線時，它和zookeeper的會話斷開，zookeeper而自動釋放表明這臺server的文件上的獨佔鎖。而master不斷輪詢 server目錄下文件的鎖狀態。若是master發現某個region server丟失了它本身的獨佔鎖，(或者master連續幾回和region server通訊都沒法成功),master就是嘗試去獲取表明這個region server的讀寫鎖，一旦獲取成功，就能夠肯定：
1 region server和zookeeper之間的網絡斷開了。
2 region server掛了。
的其中一種狀況發生了，不管哪一種狀況，region server都沒法繼續爲它的region提供服務了，此時master會刪除server目錄下表明這臺region server的文件，並將這臺region server的region分配給其它還活着的同志。
若是網絡短暫出現問題致使region server丟失了它的鎖，那麼region server從新鏈接到zookeeper以後，只要表明它的文件還在，它就會不斷嘗試獲取這個文件上的鎖，一旦獲取到了，就能夠繼續提供服務。

• master上線

master啓動進行如下步驟:
1 從zookeeper上獲取惟一一個代碼master的鎖，用來阻止其它master成爲master。
2 掃描zookeeper上的server目錄，得到當前可用的region server列表。
3 和2中的每一個region server通訊，得到當前已分配的region和region server的對應關係。
4 掃描.META.region的集合，計算獲得當前還未分配的region，將他們放入待分配region列表。

• master下線

因爲master只維護表和region的元數據，而不參與表數據IO的過 程，master下線僅致使全部元數據的修改被凍結(沒法建立刪除表，沒法修改表的schema，沒法進行region的負載均衡，沒法處理region 上下線，沒法進行region的合併，惟一例外的是region的split能夠正常進行，由於只有region server參與)，表的數據讀寫還能夠正常進行。所以master下線短期內對整個hbase集羣沒有影響。從上線過程能夠看到，master保存的 信息全是能夠冗餘信息（均可以從系統其它地方收集到或者計算出來），所以，通常hbase集羣中老是有一個master在提供服務，還有一個以上 的’master’在等待時機搶佔它的位置。

 

參考資料

http://jiajun.iteye.com/blog/899632