本文來自於2018年10月20日由中國 HBase 技術社區在武漢舉辦的中國 HBase Meetup 第六次線下交流會。分享者爲過往記憶。

一、簡單介紹一下 HBase 是什麼

HBase 最開始是受 Google 的 BigTable 啓發而開發的分佈式、多版本、面向列的開源數據庫。其主要特點是支持上億行、百萬列，支持強一致性、並且具有高擴展、高可用等特點。

既然 HBase 是一種分佈式的數據庫，那麼其和傳統的 RMDB 有什麼區別的呢？我們先來看看HBase表核心概念，理解這些基本的核心概念對後面我理解 HBase 的讀寫以及如何設計 HBase 表有着重要的聯繫。

HBase 表主要由以下幾個元素組成：

RowKey：表中每條記錄的主鍵；
Column Family：列族，將表進行橫向切割，後面簡稱CF；Region : 水平拆分， Store ：一個列族，垂直拆分
Column：屬於某一個列族，可動態添加列；
Version Number：類型爲Long，默認值是系統時間戳，可由用戶自定義；
Value：真實的數據。

大家可以從上面的圖看出：一行（Row）數據是可以包含一個或多個 Column Family，但是我們並不推薦一張 HBase 表的 Column Family 超過三個。Column 是屬於 Column Family 的，一個 Column Family 包含一個或多個 Column。

在物理層面上，所有的數據其實是存放在 Region 裏面的，而 Region 又由 RegionServer 管理，其對於的關係如下：

Region：一段數據的集合；
RegionServer：用於存放Region的服務。

從上面的圖也可以清晰看到，一個 RegionServer 管理多個 Region；而一個 Region 管理一個或多個 Column Family。

到這裏我們已經瞭解了 HBase 表的組成，但是 HBase 表裏面的數據到底是怎麼存儲的呢？

上面是一張從邏輯上看 HBase 表形式，這個和關係型數據庫很類似。那麼如果我們再深入看，可以看出，這張表的劃分可以如下圖表示。

從上圖大家可以明顯看出，這張表有兩個 Column Family ，分別爲 personal 和 office。而 personal 又有三列name、city 以及 phone；office 有兩列 tel 以及 address。由於存儲在 HBase 裏面的表一般有上億行，所以 HBase 表會對整個數據按照 RowKey 進行字典排序，然後再對這張表進行橫向切割。切割出來的數據是存儲在 HFile 裏面，而不同的 Column Family 雖然屬於一行，但是其在底層存儲是放在不同的 HFile 裏。所以這張表我用了六種顏色表示，也就是說，這張表的數據會被放在六個 HFile 裏面的，這就可以把數據儘可能的分散到整個集羣。

在前面我們介紹了 HBase 其實是面向列的數據庫，所以說一行 HBase 的數據其實是分了好幾行存儲，一個列對應一行，HBase 的 KV 結構如下：

爲了簡便起見，在後面的表示我們刪除了類似於 Key Length 的屬性，只保留 Row Key、Column Family、Column Qualifier等信息。所以 RowKey 爲 Row1 的數據第一列表示爲上圖最後一行的形式。以此類推，整個表的存儲就可以如下表示：

大家可以從上面的 kv 表現形式看出，Row11 的 phone 這列其實是沒有數據的，在 HBase 的底層存儲裏面也就沒有存儲這列了，這點和我們傳統的關係型數據庫有很大的區別，有了這個特點， HBase 特別適合存儲稀疏表。

我們前面也將了 HBase 其實是多版本的，那如果我們修改了 HBase 表的一列，HBase 又是如何存儲的呢？

比如上圖中我們將 Row1 的 city 列從北京修改爲上海了，如果使用 KV 表示的話，我們可以看出其實底層存儲了兩條數據，這兩條數據的版本是不一樣的，最新的一條數據版本比之前的新。總結起來就是：

HBase支持數據多版本特性，通過帶有不同時間戳的多個KeyValue版本來實現的；
每次put，delete都會產生一個新的Cell，都擁有一個版本；
默認只存放數據的三個版本，可以配置；
查詢默認返回最新版本的數據（排序實現），可以通過制定版本號或版本數獲取舊數據。

二、 HBase 是如何讀寫數據的

到這裏我們已經瞭解了 HBase 表及其底層的 KV 存儲了，現在讓我們來了解一下 HBase 是如何讀寫數據的。首先我們來看看 HBase 的架構設計，這種圖來自於社區：

HBase 的寫過程如下：

先將數據寫到WAL（Write-Ahead Logging 預寫日誌----HLog）中；
WAL 存放在HDFS之上；
每次Put、Delete操作的數據均追加到WAL末端；
持久化到WAL之後，再寫到MemStore中；
兩者寫完返回ACK到客戶端。

MemStore （數據有序）其實是一種內存結構

一個Store 對應一個 ColumnFamily
一個Column Family 對應一個MemStore

MemStore 裏面的數據也是對 Rowkey 進行字典排序的，如下：

既然我們寫數據都是先寫 WAL，再寫 MemStore ，而 MemStore 是內存結構，所以 MemStore 總會寫滿的，

將 MemStore 的數據從內存刷寫到磁盤的操作成爲 flush：

以下幾種行爲會導致 flush 操作

全局內存控制；
MemStore使用達到上限；
RegionServer的Hlog數量達到上限；
手動觸發；
關閉RegionServer觸發。

每次 flush 操作都是將一個 MemStore 的數據寫到一個 HFile 裏面的，所以上圖中 HDFS 上有許多個 HFile 文件。文件多了會對後面的讀操作有影響，所以 HBase 會隔一定的時間將 HFile 進行合併。

HFile Compaction

根據合併的範圍不同分爲 Minor Compaction 和 Major Compaction：

Minor Compaction: 指選取一些小的、相鄰的HFile將他們合併成一個更大的Hfile。

Major Compaction：

將一個column family下所有的 Hfiles 合併成更大的；
刪除那些被標記爲刪除的數據、超過TTL（time-to-live）時限的數據，以及超過了版本數量限制的數據。

HBase 讀操作

相對於寫操作更爲複雜，其需要讀取 BlockCache、MemStore 以及 HFile。

上圖只是簡單的表示 HBase 讀的操作，實際上讀的操作比這個還要複雜，我這裏就不深入介紹了。

Hbase 讀流程

zookeeper元數據-----> 找region---->MemStore---> bolockStore-----> SotreFile 找到回寫blockStore ---->HFile

到這裏，有些人可能就想到了，前面我們說 HBase 表按照 Rowkey 分佈到集羣的不同機器上，那麼我們如何去確定我們該讀寫哪些 RegionServer 呢？

這就是 HBase Region 查找的問題

客戶端按照上面的流程查找需要讀寫的 RegionServer 。這個過程一般是第一次讀寫的時候進行的，在第一次讀取到元數據之後客戶端一般會把這些信息緩存到自己內存中，後面操作直接從內存拿就行。當然，後面元數據信息可能還會變動，這時候客戶端會再次按照上面流程獲取元數據。

三、RowKey的設計要點

現在我們來看看 HBase RowKey 的設計要點。我們一般都會說，看 HBase 設計的好不好，就看其 RowKey 設計的好不好，所以RowKey 的設計在後面的寫操作至關重要。我們先來看看 Rowkey 的作用

讀寫數據時通過Row Key找到對應的Region
MemStore 中的數據按 RowKey 字典順序排序
HFile 中的數據按RowKey字典順序排序

從下圖可以看到，底層的 HFile 最終是按照 Rowkey 進行切分的，所以我們的設計原則是結合業務的特點，並考慮高頻查詢，儘可能的將數據打散到整個集羣。

一定要充分分析清楚後面我們的表需要怎麼查詢。下面我們來看看三種比較場景的 Rowkey 設計方案。

這三種 Rowkey 的設計非常常見，具體的內容圖片上也有了，我就不打文字了。

數據如果只是存儲在哪裏其實並沒有什麼用，我們還需要有辦法能夠使用到裏面的數據。幸好的是，當前 HBase 有許多的組件可以滿足我們各種需求。

四、HBase 生態介紹

如下圖是 HBase 比較常用的組件：

HBase 的生態主要有：

Phoenix：主要提供使用 SQL 的方式來查詢 HBase 裏面的數據。一般能夠在毫秒級別返回，比較適合 OLTP 場景。
Spark：我們可以使用 Spark 進行 OLAP 分析；也可以使用 Spark SQL 來滿足比較複雜的 SQL 查詢場景；使用 Spark Streaming 來進行實時流分析。
Solr：原生的 HBase 只提供了 Rowkey 單主鍵，如果我們需要對 Rowkey 之外的列進行查找，這時候就會有問題。幸好我們可以使用 Solr 來建立二級索引/全文索引充分滿足我們的查詢需求。
HGraphDB：HGraphDB是分佈式圖數據庫。依託圖關聯技術，幫助金融機構有效識別隱藏在網絡中的黑色信息，在團伙欺詐、黑中介識別等。
GeoMesa：目前基於NoSQL數據庫的時空數據引擎中功能最豐富、社區貢獻人數最多的開源系統。
OpenTSDB：基於HBase的分佈式的，可伸縮的時間序列數據庫。適合做監控系統；譬如收集大規模集羣（包括網絡設備、操作系統、應用程序）的監控數據並進行存儲，查詢。

下面簡單介紹一下這些組件。