1. 什么是 Hbase ？

HBase 是一個(gè)高可靠性、高性能、面向列、可伸縮的分布式存儲(chǔ)系統(tǒng)，目標(biāo)是存儲(chǔ)并處理大型的數(shù)據(jù)。

HBase 是 Google Bigtable 的開源實(shí)現(xiàn)，不同之處在于：Google Bigtable 使用 GFS 作為其文件存儲(chǔ)系統(tǒng)， HBase 利用 Hadoop HDFS 作為其文件存儲(chǔ)系統(tǒng)；Google Bigtable 利用 Chubby 作為協(xié)同服務(wù)， HBASE 利用 Zookeeper 作為協(xié)同服務(wù)。

Hbase 是一個(gè)面向列存儲(chǔ)的分布式存儲(chǔ)系統(tǒng)，它的優(yōu)點(diǎn)在于可以實(shí)現(xiàn)高性能的并發(fā)讀寫操作，同時(shí) Hbase 還會(huì)對(duì)數(shù)據(jù)進(jìn)行透明的切分，這樣就使得存儲(chǔ)本身具有了水平伸縮性。

2. Hbase 的數(shù)據(jù)模型是什么樣的？

HBase 的數(shù)據(jù)存儲(chǔ)模型當(dāng)中包含以下幾個(gè)概念：

• row ：一行數(shù)據(jù)包含一個(gè)唯一標(biāo)識(shí) Row-Key 、多個(gè) column 以及對(duì)應(yīng)的值。在 HBase 中，一張表中所有 row 都按照 Row-Key 的字典序（二進(jìn)制位移計(jì)算）由小到大排序。
• column ：與關(guān)系型數(shù)據(jù)庫中的列不同， HBase 中的 column 由 column family （列簇）以及 qualifier （列名）兩部分組成。column family 在表創(chuàng)建的時(shí)候需要指定，用戶不能隨意增減。column family 下可以設(shè)置任意多個(gè) qualifier ，因此可以理解為 HBase 中的列可以動(dòng)態(tài)增加。
• cell ：單元格，由五元組（ row ， column ， timestamp ， type ， value ）組成的結(jié)構(gòu)，其中 type 表示 Put/Delete 這樣的操作類型， timestamp 代表這個(gè) cell 的版本。這個(gè)結(jié)構(gòu)在數(shù)據(jù)庫中實(shí)際是以 KV 結(jié)構(gòu)存儲(chǔ)的，其中（ row ， column ， timestamp ， type ）是 K ， value 字段對(duì)應(yīng) KV 結(jié)構(gòu)的 V 。
• timestamp ：每個(gè) cell 在寫入 HBase 的時(shí)候都會(huì)默認(rèn)分配一個(gè)時(shí)間戳作為該 cell 的版本， HBase 支持多版本特性，即同一 Row-Key 、 column 下可以有多個(gè) value 存在，這些 value 使用 timestamp 作為版本號(hào)。
• HBase 是一個(gè)面向列的數(shù)據(jù)庫，在表中它由行排序。表模式定義只能列族，也就是鍵值對(duì)。一個(gè)表有多個(gè)列族以及 每一個(gè)列族可以有任意數(shù)量的列 。后續(xù)列的值連續(xù)存儲(chǔ)在磁盤上。表中的每個(gè)單元格值都具有時(shí)間戳?？傊?，在一個(gè) HBase ：表是行的集合，行是列族的集合，列族是列的集合，列是鍵值對(duì)的集合。

表 1 邏輯存儲(chǔ)視圖

表 2 物理存儲(chǔ)視圖

HBase 的邏輯存儲(chǔ)視圖由行鍵、時(shí)間戳、列族組成一個(gè)類似二維表一樣的結(jié)構(gòu)，但是在實(shí)際存儲(chǔ)的時(shí)候，數(shù)據(jù)庫存儲(chǔ)的數(shù)據(jù)是以列族為單位進(jìn)行存儲(chǔ)的，是完全將行數(shù)據(jù)按列族的方式進(jìn)行分列。

3. Hbase 的存儲(chǔ)架構(gòu)是什么樣的？

圖 1 Hbase 物理存儲(chǔ)架構(gòu)

Region 是 HBase 中分布式存儲(chǔ)和負(fù)載均衡的最小單元，不同的 Region 分布到不同的 RegionServer 上，如圖 Table1 、 Table2 中均有多個(gè) Region ，這些 Region 分布在不同的 RegionServer 中。Region 雖然是分布式分布式存儲(chǔ)的最小單元，但并不是存儲(chǔ)的最小單元， Store 是存儲(chǔ)的最小單元。Region 由一個(gè)或者多個(gè) Store 組成，每個(gè) Store 會(huì)保存一個(gè) Column Family ；每個(gè) Store 又由一個(gè) MemStore 或 0 至多個(gè) Hfile 組成；MemStore 存儲(chǔ)在內(nèi)存中， HFile 存儲(chǔ)在 HDFS 中。

Hbase 在數(shù)據(jù)存儲(chǔ)的過程當(dāng)中，涉及到的物理對(duì)象分為如下：

• HMaster: 負(fù)責(zé) DDL 創(chuàng)建或刪除 tables ，同一時(shí)間只能有一個(gè) active 狀態(tài)的 master 存在。
• Zookeeper: 判定 HMaster 的狀態(tài)，記錄 Meta Table 的具體位置；
• Region: 一張 BigTable 的一個(gè)分片（ Shard ），記錄著 key 的開始和結(jié)束；
• WAL: 預(yù)寫日志，持久化且順序存儲(chǔ)，一個(gè) RegionServer 維護(hù)一套 WAL ；
• RegionServer: RegionServer 中維護(hù)多個(gè) region ， region 里包含 MemStore 以及多個(gè) HFiles ；
• MemStore: 對(duì)應(yīng)一個(gè) BigTable 的 Column Family ，存在于文件緩存中，擁有文件句柄；
• BlockCache: 讀緩存，存于內(nèi)存；(Row-Key – > row) ；

HFiles: 從 MemStore Flush 出來的文件，本身是持久化的，存儲(chǔ)于 HDFS 的 DataNode 之中，每次 Flush 生成一個(gè)新的 HFile 文件，文件包含有序的鍵值對(duì)序列。

4. Hbase 是如何進(jìn)行數(shù)據(jù)的讀寫？

圖 2 Hbase 讀寫原理圖

數(shù)據(jù)寫入流程（如左圖）：

• 客戶端首先從 Zookeeper 找到 meta 表的 region 位置，然后讀取 meta 表中的數(shù)據(jù)， meta 表中存儲(chǔ)了用戶表的 region 信息。
• 根據(jù) namespace 、表名和 Row-Key 信息。找到寫入數(shù)據(jù)對(duì)應(yīng)的 region 信息
• 找到這個(gè) region 對(duì)應(yīng)的 regionServer ，然后發(fā)送請求。
• 把數(shù)據(jù)分別寫到 HLog （ write ahead log ）和 memstore 各一份。
• memstore 達(dá)到閾值后把數(shù)據(jù)刷到磁盤，生成 storeFile 文件。
• 刪除 HLog 中的歷史數(shù)據(jù)。

數(shù)據(jù)讀出流程（如右圖）：

• 客戶端首先與 Zookeeper 進(jìn)行連接；從 Zookeeper 找到 meta 表的 region 位置，即 meta 表的數(shù)據(jù)存儲(chǔ)在某一 HRegionServer 上；客戶端與此 HRegionServer 建立連接，然后讀取 meta 表中的數(shù)據(jù)；meta 表中存儲(chǔ)了所有用戶表的 region 信息，我們可以通過 scan 'hbase:meta' 來查看 meta 表信息。
• 根據(jù)要查詢的 namespace 、表名和 Row-Key 信息。找到寫入數(shù)據(jù)對(duì)應(yīng)的 region 信息。
• 找到這個(gè) region 對(duì)應(yīng)的 regionServer 發(fā)送請求，并找到相應(yīng) region 。
• 先從 memstore 查找數(shù)據(jù)，如果沒有，再從 BlockCache 上讀取。
• 如果 BlockCache 中也沒有找到，再到 StoreFile 上進(jìn)行讀取，從 storeFile 中讀取到數(shù)據(jù)之后，不是直接把結(jié)果數(shù)據(jù)返回給客戶端，而是把數(shù)據(jù)先寫入到 BlockCache 中，目的是為了加快后續(xù)的查詢；然后在返回結(jié)果給客戶端。

5. Hbase 的存儲(chǔ)引擎是什么類型的？

首先需要確定的是 Hbase 的存儲(chǔ)引擎是 LSM-Tree （可以參考之前的文章：DB 存儲(chǔ)引擎知識(shí)系列之三：LSM-Tree 存儲(chǔ)引擎詳細(xì)分解）。

通過之前文章對(duì) LSM-Tree 的介紹，我們知道 LSM-Tree 相比較 B+Tree 而言，最大的特點(diǎn)就是在于通過犧牲部分讀性能，利用分層合并的思想，將小樹合并為大樹，將無序數(shù)據(jù)合并為有序數(shù)據(jù)，然后統(tǒng)一刷入磁盤，從而大大提高了寫的性能。那么 HBase 套用到 LSM 中， Memstore 就是 LSM 當(dāng)中的 Memtable ，也就是 C0 層的小樹寫入， HFiles 就是 LSM 當(dāng)中的 SSTables ，也就是 Cn 層的合并之后的樹的順序?qū)懭搿?/p>

除此之外 Hbase 在實(shí)現(xiàn) Hbase 的時(shí)候，其實(shí)還是有自己獨(dú)到的地方：

• Minor vs Major Compaction ：Minor Compaction ，根據(jù)配置策略，自動(dòng)檢查小文件，合并到大文件，從而減少碎片文件，然而并不會(huì)立馬刪除掉舊 HFile 文件；Major Compaction ，每個(gè) CF 中，不管有多少個(gè) HFiles 文件，最終都是將 HFiles 合并到一個(gè)大的 HFile 中，并且把所有的舊 HFile 文件刪除，即 CF 與 HFile 最終變成一一對(duì)應(yīng)的關(guān)系。
• BlockCache ：除了 MemStore （也就是 MemTable ） 以外， HBase 還提供了另一種緩存結(jié)構(gòu)， BlockCache 。BlockCache 本質(zhì)上是將熱數(shù)據(jù)放到內(nèi)存里維護(hù)起來，避免 Disk I/O ，當(dāng)然即使 BlockCache 找不到數(shù)據(jù)還是可以去 MemStore 中找的，只有兩邊都不存在數(shù)據(jù)的時(shí)候，才會(huì)讀內(nèi)存里的 HFile 索引尋址到硬盤，進(jìn)行一次 I/O 操作。HBase 將 BucketCache 和 LRUBlockCache 搭配使用，稱之為 CombinedBlockCache 。系統(tǒng)在 LRUBlockCache 中主要存儲(chǔ) Index Block ，而將 Data Block 存儲(chǔ)在 BucketCache 中。因此一次隨機(jī)讀需要首先在 LRUBlockCache 中查到對(duì)應(yīng)的 Index Block ，然后再到 BucketCache 查找對(duì)應(yīng)數(shù)據(jù)塊。
• HFile ：HFile 的數(shù)據(jù)結(jié)構(gòu)也是 Hbase 的重要改進(jìn)之處。

圖示是 HFile 的數(shù)據(jù)結(jié)構(gòu)，主要包含四個(gè)部分：數(shù)據(jù)塊、頭信息、索引信息、地址信息。索引就是 HFile 內(nèi)置的一個(gè) B+ 樹索引，當(dāng) RegionServer 啟動(dòng)后并且 HFile 被打開的時(shí)候，這個(gè)索引會(huì)被加載到 Block Cache 即內(nèi)存里；KeyValues 存儲(chǔ)在增長中的隊(duì)列中的數(shù)據(jù)塊里，數(shù)據(jù)塊可以指定大小，默認(rèn) 64k ，數(shù)據(jù)塊越大，順序檢索能力越強(qiáng)；數(shù)據(jù)塊越小，隨機(jī)讀寫能力越強(qiáng)，需要權(quán)衡。

6. Hbase 與傳統(tǒng)的 RDBMS 有什么區(qū)別？

表 4 列式數(shù)據(jù)庫與關(guān)系型數(shù)據(jù)庫的區(qū)別

介紹了很多 HBase 與 RDBMS 的區(qū)別。那么什么時(shí)候最需要 HBase ，或者說 HBase 是否可以替代原有的 RDBMS ？對(duì)于這個(gè)問題，我們必須時(shí)刻謹(jǐn)記 HBase 并不適合所有場景，其最終目標(biāo)并不是完全替代 RDBMS ，而是對(duì) RDBMS 的一個(gè)重要補(bǔ)充。當(dāng)需要考量 HBase 作為一個(gè)備選選型產(chǎn)品的時(shí)候，我們需要考慮以下幾個(gè)關(guān)鍵問題。

• 業(yè)務(wù)場景是否符合非 ACID 事務(wù)原則？
• 數(shù)據(jù)的業(yè)務(wù)特性上是否需要復(fù)雜查詢，例如 SQL 實(shí)現(xiàn)的復(fù)雜連接、排序、復(fù)雜條件等？
• 業(yè)務(wù)場景是不是可以通過讀取列族數(shù)據(jù)的方式更有效地實(shí)現(xiàn)，數(shù)據(jù)是否可以用字符型表示？
• 數(shù)據(jù)量是否足夠發(fā)揮 Hbase 列式數(shù)據(jù)庫的優(yōu)勢？
• 是否可以找到合適的 Row-key ？隨機(jī)性的 Row-key 適合頻繁寫，有序的 Row-key 適合大量的讀。

7. Hbase 如何解決熱點(diǎn)的問題？

HBase 中的行是按照 Row-Key 的字典順序排序的，這種設(shè)計(jì)優(yōu)化了掃描操作，可以將相關(guān)的行存放在臨近位置，便于掃描。然而糟糕的 Row-Key 設(shè)計(jì)是熱點(diǎn)的源頭。一旦由于 Row-Key 設(shè)計(jì)與業(yè)務(wù)場景不相符，大量訪問會(huì)使熱點(diǎn) region 所在的單個(gè)機(jī)器超出自身承受能力，引起性能下降甚至不可用，這也會(huì)影響同一個(gè) RegionServer 上的其他 region 。

那么如何避免這樣的問題發(fā)生呢？通常會(huì)有以下幾種設(shè)計(jì)思想可供參考：

• 反轉(zhuǎn)：將 Row-Key 的字符串可變的部分提到前面，相對(duì)固定的部分提到后面。這樣就會(huì)打亂 Row-Key 的有序性，在一定程度上降低了批量數(shù)據(jù)寫的性能，但是讀的時(shí)候就會(huì)減少熱點(diǎn)查詢，通過犧牲部分寫的性能而提升讀的性能。
• 前綴：將每一個(gè) Row-Key 加一個(gè)隨機(jī)字符前綴，使得數(shù)據(jù)分散在多個(gè)不同的 Region ，達(dá)到 Region 負(fù)載均衡的目標(biāo)。最終消除局部熱點(diǎn)，解決熱點(diǎn)讀寫的問題。
• 散列：通過哈希散列的方式將 Row-Key 重新設(shè)計(jì)，使得數(shù)據(jù)分散在不同的 Region ，同時(shí)效果要比前綴的方式更好，因?yàn)樵谧x的時(shí)候，它是可以通過哈希的計(jì)算減少讀性能的損耗。既解決了熱點(diǎn)問題，同時(shí)也不必消耗太多的讀性能。