文章目錄
面向面試的博客，以問答式Q/A方式呈現。
Question1：簡要介紹一下 Hbase ？
Answer1：
Hbase 是一個通過大量廉價的機器解決海量數據的高速存儲和讀取的分佈式數據庫解決方案
Hbase 是分佈式、面向列的開源數據庫（其實準確的說是面向列族）。HDFS 爲 Hbase 提供可靠的底層數據存儲服務，MapReduce 爲 Hbase 提供高性能的計算能力，Zookeeper 爲 Hbase 提供穩定服務和 Failover 機制，因此我們說 Hbase 是一個通過大量廉價的機器解決海量數據的高速存儲和讀取的分佈式數據庫解決方案。
Hbase的列式存儲
Hbase採用列式存儲，列方式所帶來的重要好處之一就是，由於查詢中的選擇規則是通過列來定義的，因此整個數據庫是自動索引化的。
這裏的列式存儲其實說的是列族存儲，Hbase 是根據列族來存儲數據的。列族下面可以有非常多的列，列族在創建表的時候就必須指定。爲了加深對 Hbase 列族的理解，下面是一個簡單的關係型數據庫的表和 Hbase 數據庫的表：
Hbase的核心概念
1、Column Family 列族
Column Family 又叫列族，Hbase 通過列族劃分數據的存儲，列族下面可以包含任意多的列，實現靈活的數據存取。Hbase 表的創建的時候就必須指定列族。就像關係型數據庫創建的時候必須指定具體的列是一樣的。Hbase的列族不是越多越好，官方推薦的是列族最好小於或者等於3。我們使用的場景一般是 1 個列族。
2、Rowkey（ Rowkey 查詢，Rowkey 範圍掃描，全表掃描 ）
Rowkey 的概念和 mysql 中的主鍵是完全一樣的，Hbase 使用 Rowkey 來唯一的區分某一行的數據。Hbase 只支持 3 中查詢方式：基於 Rowkey 的單行查詢，基於 Rowkey 的範圍掃描，全表掃描。
3、Region 分區
Region：Region 的概念和關係型數據庫的分區或者分片差不多。Hbase 會將一個大表的數據基於 Rowkey 的不同範圍分配到不通的 Region 中，每個 Region 負責一定範圍的數據訪問和存儲。這樣即使是一張巨大的表，由於被切割到不通的 region，訪問起來的時延也很低。
4、TimeStamp 多版本
TimeStamp 是實現 Hbase 多版本的關鍵。在 Hbase 中使用不同的 timestame 來標識相同 rowkey 行對應的不通版本的數據。在寫入數據的時候，如果用戶沒有指定對應的timestamp，Hbase 會自動添加一個 timestamp，timestamp 和服務器時間保持一致。在
Hbase 中，相同 rowkey 的數據按照 timestamp 倒序排列。默認查詢的是最新的版本，用戶可同指定 timestamp 的值來讀取舊版本的數據。
Question2：談一談 Hbase 核心架構 ？
Answer2：
Hbase 是由 Client、Zookeeper、HMaster、HRegionServer、HDFS 等幾個組建組成。
Hbase 架構如下圖所示：
1、Hbase組件：Client
Client 包含了訪問 Hbase 的接口，另外 Client 還維護了對應的 cache 來加速 Hbase 的
訪問，比如 cache 的.META.元數據的信息。
2、Hbase組件：Zookeeper
Hbase 通過 Zookeeper 來做 master 的高可用、RegionServer 的監控、元數據的入口
以及集羣配置的維護等工作。具體工作如下：
- 通過 Zoopkeeper 來保證集羣中只有 1 個 master 在運行，如果 master 異
常，會通過競爭機制產生新的 master 提供服務 - 通過 Zoopkeeper 來監控 RegionServer 的狀態，當 RegionSevrer 有異常的
時候，通過回調的形式通知 Master RegionServer 上下限的信息 - 通過 Zoopkeeper 存儲元數據的統一入口地址。
3、Hbase組件：HMaster
HMaster 節點的主要職責如下：
- 爲 RegionServer 分配 Region
- 維護整個集羣的負載均衡
- 維護集羣的元數據信息發現失效的 Region，並將失效的 Region 分配到正常RegionServer 上當 RegionSever 失效的時候，協調對應 Hlog 的拆分。
4、Hbase組件：HRegionServer
HRegionServer 直接對接用戶的讀寫請求，是真正的“幹活”的節點。它的功能概括如下：
- 管理 master 爲其分配的 Region
- 處理來自客戶端的讀寫請求
- 負責和底層 HDFS 的交互，存儲數據到 HDFS
- 負責 Region 變大以後的拆分
- 負責 Storefile 的合併工作
5、Hbase組件：HDFS
HDFS 爲 Hbase 提供最終的底層數據存儲服務，同時爲 Hbase 提供高可用（Hlog 存儲在
HDFS）的支持。
6、Region 尋址方式（通過 zookeeper .META）
Region 尋址方式，如下圖所示：
第 1 步：Client 請求 ZK 獲取.META.所在的 RegionServer 的地址。
第 2 步：Client 請求.META.所在的 RegionServer 獲取訪問數據所在的 RegionServer 地
址，client 會將.META.的相關信息 cache 下來，以便下一次快速訪問。
第 3 步：Client 請求數據所在的 RegionServer，獲取所需要的數據。
Question3：介紹一下 Hbase 寫入流程？
Answer3：
Hbase 寫入流程，如下圖所示：
從上圖可以看出氛圍 3 步驟：
步驟1：獲取 RegionServer
Client 獲取數據寫入的 Region 所在的 RegionServer。
步驟2：請求寫 Hlog
請求寫 Hlog, Hlog 存儲在 HDFS，當 RegionServer 出現異常，需要使用 Hlog 來恢復數據。
步驟3：請求寫 MemStore
請求寫 MemStore,只有當寫 Hlog 和寫 MemStore 都成功了纔算請求寫入完成。MemStore 後續會逐漸刷到 HDFS 中。
Question4：介紹一下 Hbase 寫入時觸發MemStore 刷盤的場景 ？
Answer4：
爲了提高 Hbase 的寫入性能，當寫請求寫入 MemStore 後，不會立即刷盤。而是會等到一定的時候進行刷盤的操作，總結成如下的幾個場景：
1、全局內存控制
這個全局的參數是控制內存整體的使用情況，當所有 memstore 佔整個 heap 的最大比
例的時候，會觸發刷盤的操作。這個參數是hbase.regionserver.global.memstore.upperLimit，默認爲整個 heap 內存的 40%。但這並不意味着全局內存觸發的刷盤操作會將所有的 MemStore 都進行輸盤，而是通過另外一個參數 hbase.regionserver.global.memstore.lowerLimit 來控制，默認是整個heap 內存的 35%。當 flush 到所有 memstore 佔整個 heap 內存的比率爲 35%的時候，就停止刷盤。這麼做主要是爲了減少刷盤對業務帶來的影響，實現平滑系統負載的目的。
2、MemStore 達到上限
當 MemStore 的大小達到 hbase.hregion.memstore.flush.size 大小的時候會觸發刷
盤，默認 128M 大小。
3、RegionServer 的 Hlog 數量達到上限
前面說到 Hlog 爲了保證 Hbase 數據的一致性，那麼如果 Hlog 太多的話，會導致故障恢復的時間太長，因此 Hbase 會對 Hlog 的最大個數做限制。當達到 Hlog 的最大個數的時候，會強制刷盤。這個參數是 hase.regionserver.max.logs，默認是 32 個。
4、手工觸發
可以通過 hbase shell 或者 java api 手工觸發 flush 的操作。
5、關閉 RegionServer 觸發
在正常關閉 RegionServer 會觸發刷盤的操作，全部數據刷盤後就不需要再使用 Hlog 恢
複數據。
6、Region 使用 HLOG 恢復完數據後觸發
當 RegionServer 出現故障的時候，其上面的 Region 會遷移到其他正常的RegionServer 上，在恢復完 Region 的數據後，會觸發刷盤，當刷盤完成後纔會提供給業務訪問。
Question5：談一談 Hbase 與 Cassandra 區別？
Answer5：
一表小結（HBase vs Cassandra）：
| HBase | Cassandra | |
|---|---|---|
| 語言 | Java | Java |
| 出發點 | BigTable | BigTable and Dynamo |
| License | Apache | Apache |
| Protocol | HTTP/REST (also Thrift) | Custom, binary (Thrift) |
| 數據分佈 | 表劃分爲多個 region 存在不同 region server 上 | 改進的一致性哈希（虛擬節點） |
| 存儲目標 | 大文件 | 小文件 |
| 一致性 | 強一致性 | 最終一致性，Quorum NRW 策略 |
| 架構 | master/slave | p2p |
| 高可用性 | NameNode 是 HDFS 的單點故障點 | P2P 和去中心化設計，不會出現單點故障 |
| 伸縮性 | Region Server 擴容，通過將自身發佈到Master，Master 均勻分佈 Region | 擴容需在 Hash Ring 上多個節點間調整數據分佈 |
| 讀寫性能 | 數據讀寫定位可能要通過最多 6 次的網絡 RPC，性能較低。 | 數據讀寫定位非常快 |
| 數據衝突處理 | 樂觀併發控制（optimistic concurrencycontrol） | 向量時鐘 |
| 臨時故障處理 | Region Server 宕機，重做 HLog | 數據回傳機制：某節點宕機，hash 到該節點的新數據自動路由到下一節點做 hinted handoff，源節點恢復後，推送回源節點。 |
| 永久故障恢復 | Region Server 恢復，master 重新給其分配 region | Merkle 哈希樹，通過 Gossip 協議同步 Merkle Tree，維護集羣節點間的數據一致性 |
| 成員通信及錯誤檢測 | Zookeeper | 基於 Gossip |
| CAP | 1，強一致性，0 數據丟失。2，可用性低。3，擴容方便。 | 1，弱一致性，數據可能丟失。2，可用性高。3，擴容方便。 |
