HBase原理總結

HBase分布式數據庫，面向列存儲(准確的說是面向列族)，支持實時、隨機讀寫。HDFS 為 Hbase 提供可靠的底層數據存儲服務，MapReduce 為 Hbase 提供高性能的計算能力，Zookeeper 為 Hbase 提供
穩定服務和Failover機制，因此，Hbase 是一個通過大量廉價的機器解決海量數據的高速存儲和讀取的分布式數據庫解決方案。
列式存儲的好處：由於查詢中的選擇規則是通過列來定義的，因此整個數據庫是自動索引化的。

1 基礎概念

1.1 Column Family 列族

Hbase根據列族來存儲數據的，每個列族可以包含任意多的列，列族在創建表的時候就必須指定。像關系型數據庫創建的時候必須指定具體的列是一樣的。Hbase 的列族不是越多越好，官方推薦列族最好小於或者等於 3。我們使用的場景一般是1個列族

1.2 Rowkey

Rowkey類似mysql中的主鍵，Hbase使用Rowkey來唯一的區分某一行的數據。
完全是由用戶指定的一串不重復的字符串；HBase中的數據永遠是根據Rowkey的字典排序來排序的。
Hbase只支持3中查詢方式：基於Rowkey的單行查詢，基於Rowkey的范圍掃描，全表掃描。
RowKey的作用：
讀寫數據時通過RowKey找到對應的Region；
MemStore中的數據按RowKey字典順序排序；
HFile中的數據按RowKey字典順序排序。
Rowkey對Region划分影響:
HBase 表的數據是按照 Rowkey 來分散到不同 Region，不合理的 Rowkey 設計會導致熱點問題。熱點問題是大量的 Client 直接訪問集群的一個或極少數個節點，而集群中的其他節點卻處於相對空閑狀態。
Rowkey設計規則：
1）rowkey 長度原則
2）rowkey 散列原則
3）rowkey 唯一原則
Rowkey設計技巧：
1）生成隨機數、hash、散列值
2）字符串反轉
如何避免上面說到的熱點問題呢？
避免熱點的方法 - Salting
避免熱點的方法 - Hashing
避免熱點的方法 - Reversing
RowKey的長度
RowKey 可以是任意的字符串，最大長度64KB（因為 Rowlength 占2字節）。建議越短越好，原因如下：
數據的持久化文件HFile中是按照KeyValue存儲的，如果rowkey過長，比如超過100字節，1000w行數據，光rowkey就要占用100*1000w=10億個字節，將近1G數據，這樣會極大影響HFile的存儲效率；
MemStore將緩存部分數據到內存，如果rowkey字段過長，內存的有效利用率就會降低，系統不能緩存更多的數據，這樣會降低檢索效率；
目前操作系統都是64位系統，內存8字節對齊，控制在16個字節，8字節的整數倍利用了操作系統的最佳特性。
HBase Rowkey設計指南

1.3 Region 分區

Region類似關系型數據庫的分區或者分片。Hbase將一個大表的數據基於Rowkey的不同范圍分配到不同的Region中，每個Region負責一定范圍的數據訪問和存儲。一張巨大的表，由於被切割到不通的region，訪問起來時延也很低。

1.4 TimeStamp 多版本

TimeStamp是實現Hbase多版本的關鍵。在Hbase中使用不同的timestame來標識相同rowkey行對應的不通版本的數據。在寫入數據的時候，如果用戶沒有指定對應的timestamp，Hbase會自動添加一個timestamp，timestamp 和服務器時間保持一致。在Hbase中，相同rowkey的數據按照timestamp倒序排列。默認查詢的是最新的版本，用戶可指定timestamp的值來讀取舊版本的數據。
注意：HBase中存儲的數據都是字符串，沒有數據類型；HBase可以保留多個版本是因為，HBase存儲底層依賴於HDFS，HDFS只允許追加數據，不允許對數據進行部分修改。

2 Hbase 核心架構

Hbase由Client、Zookeeper、Master、HRegionServer、HDFS等組件組成。

2.1 Client

Client包含了訪問Hbase的接口，同時在cache緩存中維護着已經訪問過的Region位置信息，用來加快后續數據訪問過程，比如cache的.META.元數據的信息。

2.2 Zookeeper

Hbase通過Zookeeper來做master的高可用、RegionServer 的監控、元數據的入口以及集群配置的維護等工作。具體工作如下：

1. 通過Zoopkeeper來保證集群中在任何時刻總有唯一1個master在運行，如果master異常，會通過競爭機制產生新的master提供服務，避免了master的"單點失效"問題
2. 通過Zoopkeeper來監控RegionServer 的狀態，當RegionSevrer有異常的時候，通過回調的形式通知Master RegionServer上下限的信息
3. 通過Zoopkeeper存儲元數據的統一入口地址。

2.3 Hmaster

主服務器master主要負責表和Region的管理工作：

1. 管理用戶對表的增加 刪除 修改和查詢等操作
2. 在Region分裂或合並后，負責重新調整Region的分布，即為RegionServer分配Region
3. 實現不同Region服務器之間的負載均衡
4. 維護集群的元數據信息發現失效的Region，並將失效的Region分配到正常RegionServer上當RegionSever失效的時候，協調對應Hlog的拆分，即對發生故障失效的Region服務器上的Region進行遷移

2.4 HregionServer

HregionServer是HBase最核心的模塊，負責維護分配給自己的Region，並直接響應用戶的讀寫請求，是真正的“干活”的節點。它的功能概括如下：

1. 管理master為其分配的Region
2. 處理來自客戶端的讀寫請求
3. 負責和底層HDFS的交互，存儲數據到HDFS
4. 負責Region變大以后的拆分
5. 負責Storefile的合並工作
   注：每台region服務器可以存儲10-1000個region，region是指具體用戶數據，這10-1000個region共用一個公共的HLog日志，即每台region服務器中的若干region共用一個HLog，每一個region在寫數據時會對它的列族進行切分，因為HBase存儲是以列族為單位的，一個列族一個列族進行存儲，因此每個列族單獨構成一個Store,一個Store就代表一個列族，但是Store中的數據並不是直接寫到底層，而是先寫到緩存MemStore中，當緩存滿了以后再刷寫到StoreFile磁盤文件中，隨着數據越來越多，會生成若干StoreFile文件，StoreFile是HBase中的表示形式，其底層借助於HDFS中的HFile來存儲。

2.5 Region 尋址方式（通過 zookeeper .META）

第 1 步：Client請求ZK獲取.META.所在的RegionServer的地址。
第 2 步：Client請求.META.所在的RegionServer獲取訪問數據所在的RegionServer地址，client會將.META.的相關信息cache下來，以便下一次快速訪問。
第 3 步：Client請求數據所在的RegionServer，獲取所需要的數據。

2.6 HDFS

HDFS為Hbase提供最終的底層數據存儲服務，同時為Hbase提供高可用（Hlog存儲在HDFS）的支持。

3 Hbase的寫邏輯

3.1 Hbase 的寫入流程

獲取 RegionServer
第 1 步：Client 獲取數據寫入的 Region 所在的 RegionServer
請求寫 Hlog
第 2 步：請求寫 Hlog, Hlog 存儲在 HDFS，當 RegionServer 出現異常，需要使用 Hlog 來
恢復數據。
請求寫 MemStore
第 3 步：請求寫 MemStore,只有當寫 Hlog 和寫 MemStore 都成功了才算請求寫入完成。
MemStore 后續會逐漸刷到 HDFS 中。

3.2 MemStore 刷盤

為了提高 Hbase 的寫入性能，當寫請求寫入 MemStore 后，不會立即刷盤。而是會等到一定的時候進行刷盤的操作。具體是哪些場景會觸發刷盤的操作呢？總結成如下的幾個場景：
全局內存控制

1. 這個全局的參數是控制內存整體的使用情況，當所有 memstore 占整個 heap 的最大比例的時候，會觸發刷盤的操作。這個參數是hbase.regionserver.global.memstore.upperLimit，默認為整個 heap 內存的 40%。但這並不意味着全局內存觸發的刷盤操作會將所有的 MemStore 都進行輸盤，而是通過另外一個參數 hbase.regionserver.global.memstore.lowerLimit 來控制，默認是整個
   heap 內存的 35%。當 flush 到所有 memstore 占整個 heap 內存的比率為 35%的時候，就停止刷盤。這么做主要是為了減少刷盤對業務帶來的影響，實現平滑系統負載的目的。

MemStore 達到上限
2. 當 MemStore 的大小達到 hbase.hregion.memstore.flush.size 大小的時候會觸發刷盤，默認 128M 大小

RegionServer 的 Hlog 數量達到上限
3. 前面說到 Hlog 為了保證 Hbase 數據的一致性，那么如果 Hlog 太多的話，會導致故障恢復的時間太長，因此 Hbase 會對 Hlog 的最大個數做限制。當達到 Hlog 的最大個數的時候，會強制刷盤。這個參數是 hase.regionserver.max.logs，默認是 32 個。

手工觸發
4. 可以通過 hbase shell 或者 java api 手工觸發 flush 的操作。

關閉 RegionServer 觸發
5. 在正常關閉 RegionServer 會觸發刷盤的操作，全部數據刷盤后就不需要再使用 Hlog 恢復數據。

Region 使用 HLOG 恢復完數據后觸發
6. 當 RegionServer 出現故障的時候，其上面的 Region 會遷移到其他正常的RegionServer 上，在恢復完 Region 的數據后，會觸發刷盤，當刷盤完成后才會提供給業務訪問。