hbase分布式存儲機制（工作原理詳解）

2019/2/20 星期三

參考鏈接
https://www.cnblogs.com/qingyunzong/p/8692430.html
hbase分布式存儲機制（工作原理詳解）
hbase系統架構圖

hbase集群中每個組件的作用
Client
//包含訪問hbase 的接口，client 維護著一些cache 來加快對hbase 的訪問，比如regione 的位置信息。
1、HBase 有兩張特殊表：
.META.：記錄了用戶所有表拆分出來的的 Region 映射信息，.META.可以有多個 Regoin
-ROOT-：記錄了.META.表的 Region 信息，-ROOT-只有一個 Region，無論如何不會分裂
2、Client 訪問用戶數據前需要首先訪問 ZooKeeper，找到-ROOT-表的 Region 所在的位置，然 后訪問-ROOT-表，接著訪問.META.表，最后才能找到用戶數據的位置去訪問，中間需要多次 網絡操作，不過 client 端會做 cache 緩存。
//客戶端直接與regionserver聯系的
備注：0.96 版本以后將-ROOT-表去掉了。至于為什么，請詳細見，hbase的尋址地址過程。
.META. -ROOT- 這2個表的信息都是通過zookeeper中的信息去找的，.META. -ROOT-這兩個表具體是在regionserver的服務器上

Hmaster ：
1 為Region server 分配region
2 負責region server 的負載均衡
3 發現失效的region server 并重新分配其上的region
4 GFS 上的垃圾文件回收
5 處理schema（模式） 更新請求 //可以通俗的理解為管理用戶對表的增刪改成操作

regionserver
1 Region server 維護Master 分配給它的region，處理對這些region 的IO 請求
2 Region server 負責切分在運行過程中變得過大的region //真正管理表實際數據的
3 regionsever 負責響應用戶的IO請求，并且向hdfs中讀寫數據
//可以看到，client 訪問hbase 上數據的過程并不需要master 參與
（尋址訪問zookeeper 和regionserver，數據讀寫訪問regione server），master 僅僅維護者table 和region 的元數據信息，所有負載很低。
提示：一般的regionserver和hdfs中的datanode并置，datanode存儲有regionserver正在管理的數據，hbase的數據最終都是存儲在hdfs上。

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

HRegion
table在行的方向上分隔為多個Region。Region是HBase中分布式存儲和負載均衡的最小單元，即不同的region可以分別在不同的Region Server上，但同一個Region是不會拆分到多個server上。Region按大小分隔，每個表一般是只有一個region。隨著數據不斷插入表，region不斷增大，當region的某個列族達到一個閾值時就會分成兩個新的region。每個region由以下信息標識：< 表名,startRowkey,創建時間> 由目錄表(-ROOT-和.META.)記錄該region的endRowkey

Memstore store 與storefile
一個region 由多個store 組成，每個store 包含一個列族的所有數據 Store 包括位于把內存的memstore 和位于硬盤的storefile
寫操作先寫入memstore,當memstore 中的數據量達到某個閾值，regionserver 啟動flashcache進程寫入storefile,每次寫入形成單獨一個storefile。
當storefile 大小超過一定閾值后，會把當前的region 分割成兩個，并由Hmaster 分配奧相應的region 服務器，實現負載均衡
客戶端檢索數據時，先在memstore 找，找不到再找storefile

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 進行拆分，然后分發到其它regionserver 上進行恢復
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，可參見上文描述。

HFile ：
HBase中KeyValue數據的存儲格式，HFile是Hadoop的 二進制格式文件，實際上StoreFile就是對Hfile做了輕量級包裝，即StoreFile底層就是HFile。
Trailer 部分的格式:
HFile 分為六個部分：
1、Data Block 段–保存表中的數據，這部分可以被壓縮
2、Meta Block 段(可選的)–保存用戶自定義的kv 對，可以被壓縮。
3、File Info 段–Hfile 的元信息，不被壓縮，用戶也可以在這一部分添加自己的元信息。
4、Data Block Index 段–Data Block 的索引。每條索引的key 是被索引的block 的第一條記錄的key。
5、Meta Block Index 段(可選的)–Meta Block 的索引。
6、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。

hbase分布式存儲機制詳解

1 已經提到過，Table 中的所有行都按照row key 的字典序排列。
2 Table 在行的方向上分割為多個region。
3 region 按大小分割的，每個表一開始只有一個region，隨著數據不斷插入表，region 不斷增大，當增大到一個閥值的時，region 就會等分會兩個新的region。當table 中的行不斷增多，就會有越來越多的region。
4 region 是Hbase 中分布式存儲和負載均衡的最小單元。最小單元就表示不同的region 可以分布在不同的HRegion server 上。但一個region 是不會拆分到多個server 上的。
5、當regionserver上的region的數據量增長到一個閾值的時候會分裂，然后繼續增長分裂。（推薦每一個regionserver管理1000個region）
再到細節中，一個region中的數據最終存儲到hdfs上去的時候，會采用什么樣子的機制呢？
6、Region 雖然是分布式存儲的最小單元，但并不是存儲的最小單元。事實上，Region 由一個或者多個Store 組成，每個store 保存一個columns family（列族）。每個Strore 又由一個memStore 和0 至多個StoreFile 組成。如圖：StoreFile 以HFile 格式保存在HDFS 上。
//region中的一個列族就是一個物理的存儲單位，所有2個不同的列族是絕對不可能存放在同一個文件中的。
7、每個Strore 又由一個memStore 和0 至多個StoreFile 組成。memstore是共享的，相當于整個store的內存緩存，如果客戶端去讀數據的時候，如果命中到哪里就會優先從memstore中拿或者寫數據。如果memstore中沒有我們要取的數據的話，接下來才會到storefile中去找。memstore可以理解為一個緩存的機制。如果是寫數據的時候，會先向memstore中去寫，然后過段時間才會把memstore刷成storefile（這其實就是region flush：寫數據的時候先寫到memstore中，過段時間再flush成storefile storefile會轉化成hfile 最終存儲到hdfs上）//StoreFile 以HFile 格式保存在HDFS 上。
8、當有多個storefile超過我們設定的閾值的時候，會出現compactition（壓縮）操作。將允許操作將所有的storefile文件作為一個storefile重新寫入（每次memstore刷新寫入一個storefile）你可以指定更大數量延壓縮，但壓縮將運行更長時間，在壓縮期間，更新將無法刷新到磁盤。長時間的壓縮需要足夠的內存，再以壓縮的持續時間內記錄所有更新，如太大，壓縮期間，客戶端會超時。
9、在hfile端也會出現壓縮的情況：hbase會自動拾取一些較小的hfile，并將它們寫入一些較大的hFile中，這個過程叫minor compacition ：minor compacatition通過重寫操作，利用合并排序將較小的文件轉化為較大數量卻數量較少的文件中。

提示：在有些資料中會單獨的提到blockcache是讀操作的緩存，他保存了內存中經常被讀的一些信息。memstore是寫操作的緩存，
我們把他們理解成一樣的，作用為緩存就可以了。不必深究。
如果要深入理解 memstore和blockcache的具體區別，請參考此文中的問題1 問題2 的解答
HBase原理－遲到的‘數據讀取流程’部分細節 http://hbasefly.com/2017/06/11/hbase-scan-2/
HBase BlockCache系列 – 走進BlockCache http://hbasefly.com/2016/04/08/hbase-blockcache-1/

1、BlockCache是Region Server級別的，
2、一個Region Server只有一個Block Cache，在Region Server啟動的時候完成Block Cache的初始化工作。
3、到目前為止，HBase先后實現了3種Block Cache方案，LRUBlockCache是最初的實現方案，也是默認的實現方案；HBase 0.92版本實現了第二種方案SlabCache，見HBASE-4027；HBase 0.96之后官方提供了另一種可選方案BucketCache，見HBASE-7404。

具體memstore 和blockcache的具體區別 請看后續的博客！

問題1：
常說HBase數據讀取要讀Memstore、HFile和Blockcache，為什么上面Scanner只有StoreFileScanner和MemstoreScanner兩種？沒有BlockcacheScanner?
答
1、HBase中數據僅僅獨立地存在于Memstore和StoreFile中
2、Blockcache中的數據只是StoreFile中的部分數據（熱點數據）即所有存在于Blockcache的數據必然存在于StoreFile中。
3、因此MemstoreScanner和StoreFileScanner就可以覆蓋到所有數據。
4、首先查數據的時候，先會從blockcache中找，如果存在直接取出；如果沒有再到storefile中查找。

問題2：
數據更新（寫）操作先將數據寫入Memstore，再落盤。落盤之后需不需要更新Blockcache中對應的kv？如果不更新，會不會讀到臟數據？
答：
1、不需要更新blockcache中的數據
2、不會讀到臟數據，因為數據寫到memstore中落盤形成新的文件。
3、memstore形成的新的文件和blockcache里面的數據是相互獨立的，以版本方式存在。

Region 管理機制
(1) region 分配
任何時刻，一個region 只能分配給一個region server。master 記錄了當前有哪些可用的region server。以及當前哪些region 分配給了哪些region server，哪些region 還沒有分配。當存在未分配的region，并且有一個region server上有可用空間時，master 就給這個region server 發送一個裝載請求，把region分配給這個region server。region server 得到請求后，就開始對此region
提供服務。
(2) region server 上線
master 使用zookeeper 來跟蹤region server 狀態。當某個region server 啟動時，會首先在zookeeper 上的server 目錄下建立代表自己的文件，并獲得該文件的獨占鎖。由于master 訂閱了server 目錄上的變更消息，當server 目錄下的文件出現新增或刪除操作時，master 可以得到來自zookeeper 的實時通知。因此一旦region server 上線，master 能馬上得到消息。
(3)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 之后，只要代表它的文件還在，它就會不斷嘗試獲取這個文件上的鎖，一旦獲取到了，就可以繼續提供服務。

HMaster 工作機制
（1）Hmaster 上線
master 啟動進行以下步驟:
1 從zookeeper 上獲取唯一一個代碼master 的鎖，用來阻止其它master 成為master。
2 掃描zookeeper 上的server 目錄，獲得當前可用的region server 列表。
3 和2 中的每個region server 通信，獲得當前已分配的region 和region server的對應關系。
4 掃描.META.region 的集合，計算得到當前還未分配的region，將他們放入待分配region 列表。
（2）master 下線
由于master 只維護表和region 的元數據，而不參與表數據IO 的過程，master下線僅導致所有元數據的修改被凍結(無法創建刪除表，無法修改表的schema（模式），無法進行region 的負載均衡，無法處理region 上下線，無法進行region 的合并，唯一例外的是region 的split 可以正常進行，因為只有region server 參與)，表的數據讀寫還可以正常進行。因此master 下線短時間內對整個hbase集群沒有影響。從上線過程可以看到，master 保存的信息全是可以冗余信息（都可以從系統其它地方收集到或者計算出來），因此，一般hbase 集群中總是有一個master 在提供服務，還有一個以上的’master’在等待時機搶占它的位置。