一、系統架構

客戶端連接hbase依賴於zookeeper，hbase存儲依賴於hadoop

client：

1、包含訪問 hbase 的接口， client 維護著一些 cache（緩存） 來加快對 hbase 的訪問，比如 region 的 位置信息。 （經常使用的表的位置信息）
zookeeper：

1、保證任何時候，集群中只有一個 master
2、存貯所有 Region 的尋址入口----root 表在哪臺服務器上。 -root-這張表的位置信息
3、實時監控 RegionServer 的狀態，將 RegionServer 的上線和下線信息實時通知給 Master
4、存儲 Hbase 的 schema（表的描述信息），包括有哪些 table，每個 table 有哪些 column family

master職責：

1、為 RegionServer 分配 region
2、負責 RegionServer 的負載均衡
3、發現失效的 RegionServer 並重新分配其上的 region
4、 HDFS 上的垃圾文件（ hbase）回收
5、處理 schema 更新請求（增加，刪除，修改）（ JDBC:crud）

RegionServer 職責
1、 RegionServer 維護 Master 分配給它的 region，處理對這些 region 的 IO 請求
2、 RegionServer 負責切分在運行過程中變得過大的 region

可以看到， client 訪問 hbase 上數據的過程並不需要 master 參與（尋址訪問 zookeeper 和 RegioneServer，數據讀寫訪問 RegioneServer）， master 僅僅維護者 table 和 region 的元數據 信息，負載很低。

.meta. 存的是所有的 region 的位置信息，那麽 RegioneServer 當中 region 在進行分裂之後 的新產生的 region，是由 master 來決定發到哪個 RegioneServer，這就意味著，只有 master 知道 new region 的位置信息，所以，由 master 來管理.meta.這個表當中的數據的 CRUD

（一張表數據大於10G時，會被分為兩個region）

二、物理存儲

1、整體物理結構

hfile 到達三個就會合並

（1）Table 中的所有行都按照 row key 的字典序排列。
（2） Table 在行的方向上分割為多個 Hregion。
（3） region 按大小分割的(默認 10G)，每個表一開始只有一個 region，隨著數據不斷插入表， region 不斷增大，當增大到一個閥值的時候， Hregion 就會等分會兩個新的 Hregion。當 table 中的行不斷增多，就會有越來越多的 Hregion。
（4） Hregion 是 Hbase 中分布式存儲和負載均衡的最小單元。最小單元就表示不同的 Hregion 可以分布在不同的 HRegion server 上。但一個 Hregion 是不會拆分到多個 server 上的。
（5） HRegion 雖然是負載均衡的最小單元，但並不是物理存儲的最小單元。事實上， HRegion 由一個或者多個 Store 組成， 每個 store 保存一個 column family。每個 Strore 又由一個 memStore 和 0 至多個 StoreFile 組成

2、MemStore 和 StoreFile

一個 region 由多個 store 組成，每個 store 包含一個列族的所有數據 Store 包括位於內存的 memstore 和位於硬盤的 storefile
寫操作先寫入 memstore,當 memstore 中的數據量達到某個閾值， HRegionServer 啟動flushcache 進程寫入 storefile， 每次寫入形成單獨一個 Hfile
當 storefile 大小超過一定閾值後，會把當前的 region 分割成兩個，並由 HMaster 分配給相應的 region 服務器，實現負載均衡

客戶端檢索數據時，先在 memstore 找，找不到再找 storefile

（memstore 存儲了一部分hfile數據，最新的）

3、storefile 和hfile結構

StoreFile 以 HFile 格式保存在 HDFS 上，請看下圖 Hfile 的數據組織格式：

4、Hlog(WAL) 增刪改一定被記錄下來

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：
（1）HLog Sequence File 的 Key 是 HLogKey 對象， HLogKey 中記錄了寫入數據的歸屬信息，除 了 table 和 region 名字外，同時還包括 sequence number 和 timestamp， timestamp 是”寫入 時間”， sequence number 的起始值為 0，或者是最近一次存入文件系統中 sequence number。
（2）HLog Sequece File 的 Value 是 HBase 的 KeyValue 對象，即對應 HFile 中的 KeyValue，可參見上文描述。

5、尋址機制

現在假設我們要從 user_info 裏面尋找一條 RowKey 是 rk0001 的數據。那麽我們應該遵循以 下步驟：
（1） 從.META.表裏面查詢哪個 Region 包含這條數據。
(2)獲取管理這個 Region 的 RegionServer 地址。
(3) 連接這個 RegionServer, 查到這條數據。

系統如何找到某個 RowKey (或者某個 RowKey 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 的位置信息， rowkey 采用表名+表的最後一行編碼而成。
(3) 為了加快訪問， .META.表的全部 region 都保存在內存中。
(4)client 會將查詢過的位置信息保存緩存起來，緩存不會主動失效，因此如果 client 上的緩存 全部失效，則需要進行最多 6 次網絡來回，才能定位到正確的 region(其中三次用來發現緩 存失效，另外三次用來獲取位置信息)。

三、讀寫過程

1、讀請求過程

（1）客戶端通過 zookeeper 以及 root 表和 meta 表找到目標數據所在的 regionserver(就是數據 所在的 region 的主機地址)
（2）聯系 regionserver 查詢目標數據
（3） regionserver 定位到目標數據所在的 region，發出查詢請求
（4）region 先在 memstore 中查找，命中則返回
（5） 如 果 在 memstore 中 找 不 到 ， 則 在 storefile 中 掃 描 （ 可 能 會 掃 描 到 很 多 的 storefile----bloomfilter）

（ bloomfilter，布隆過濾器：迅速判斷一個元素是不是在一個龐大的集合內，但是他有一個 弱點：它有一定的誤判率）
（誤判率：原本不存在與該集合的元素，布隆過濾器有可能會判斷說它存在，但是，如果布 隆過濾器，判斷說某一個元素不存在該集合，那麽該元素就一定不在該集合內）

2、寫請求過程

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

（先寫日誌文件，再寫memstore）

細節描述：
hbase 使用 MemStore 和 StoreFile 存儲對表的更新。
數據在更新時首先寫入 Log(WAL log)和內存(MemStore)中， MemStore 中的數據是排序的，當 MemStore 累計到一定閾值時，就會創建一個新的 MemStore，並 且將老的 MemStore 添加到 flush 隊列，由單獨的線程 flush 到磁盤上，成為一個 StoreFile。
於此同時，系統會在 zookeeper 中記錄一個 redo point，表示這個時刻之前的變更已經持久化了。當系統出現意外時，可能 導致內存(MemStore)中的數據丟失，此時使用 Log(WAL log)來恢復 checkpoint 之後的數據。

StoreFile 是只讀的，一旦創建後就不可以再修改。
因此 Hbase 的更新其實是不斷追加的操作。 當一個 Store 中的 StoreFile 達到一定的閾值後，就會進行一次合並 (minor_compact, major_compact),將對同一個 key 的修改合並到一起，形成一個大的 StoreFile，當 StoreFile 的 大小達到一定閾值後，又會對 StoreFile 進行 split，等分為兩個 StoreFile。 由於對表的更新 是不斷追加的， compact 時，需要訪問 Store 中全部的 StoreFile 和 MemStore，將他們按 row key 進行合並，由於 StoreFile 和 MemStore 都是經過排序的，並且 StoreFile 帶有內存中索引， 合並的過程還是比較快。
四、RegionServer 工作機制

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 目錄下建立代表自己的 znode。由於 master 訂閱了 server 目錄上的變 更消息，當 server 目錄下的文件出現新增或刪除操作時， master 可以得到來自 zookeeper 的
實時通知。因此一旦 region server 上線， master 能馬上得到消息。

3、 region server 下線
當 region server 下線時，它和 zookeeper 的會話斷開， zookeeper 而自動釋放代表這臺 server 的文件上的獨占鎖。 master 就可以確定：
（1）region server 和 zookeeper 之間的網絡斷開了。
（2）region server 掛了。

無論哪種情況，region server 都無法繼續為它的 region 提供服務了，此時 master 會刪除 server 目錄下代表這臺 region server 的 znode 數據，並將這臺 region server 的 region 分配給其它還 活著的同誌。

五、master工作機制

master 上線
master 啟動進行以下步驟:
（1） 從 zookeeper上獲取唯一一個代表 active master 的鎖，用來阻止其它 master 成為 master。
（2）掃描 zookeeper 上的 server 父節點，獲得當前可用的 region server 列表。
（3）和每個 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 在等 待時機搶占它的位置。

Hbase(五) hbase內部原理