本文來自於 2018 年 10 月 20 日由中國 HBase 技術社群在武漢舉辦的中國 HBase Meetup 第六次線下交流會。HBase 基本知識介紹及典型案例分析 PPT 下載:https://yq.aliyun.com/download/3259

本次分享的內容主要分為以下五點

1. HBase 基本知識
2. HBase 讀寫流程
3. RowKey 設計要點
4. HBase 生態介紹
5. HBase 典型案例分析

1. HBase 基本知識

首先我們簡單介紹一下 HBase 是什麼?

HBase 最開始是受 Google 的 BigTable 啟發而開發的分散式、多版本、面向列 的開源資料庫。其主要特點是支援上億行、百萬列，支援強一致性、並且具有高 擴充套件、高可用等特點。
既然 HBase 是一種分散式的資料庫，那麼其和傳統的 RMDB 有什麼區別的呢? 我們先來看看HBase表核心概念，理解這些基本的核心概念對後面我理解 HBase 的讀寫以及如何設計 HBase 表有著重要的聯絡。

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

1. RowKey:表中每條記錄的主鍵;
2. Column Family:列族，將表進行橫向切割，後面簡稱 CF;
3. Column:屬於某一個列族，可動態新增列;
4. Version Number:型別為 Long，預設值是系統時間戳，可由使用者自定義;
5. Value:真實的資料。

大家可以從上面的圖看出:一行(Row)資料是可以包含一個或多個 Column Family，但是我們並不推薦一張 HBase 表的 ColumnFamily 超過三個。Column 是屬於 Column Family 的，一個 Column Family 包含一個或多個 Column。
在物理層面上，所有的資料其實是存放在 Region 裡面的，而 Region 又由 RegionServer 管理，其對於的關係如下:

1. Region:一段資料的集合;
2. RegionServer:用於存放 Region 的服務。
   從上面的圖也可以清晰看到，一個 RegionServer 管理多個 Region;而一個 Region 管理一個或多個 Column Family。

2. HBase 讀寫流程
到這裡我們已經瞭解了 HBase 表的組成，但是 HBase 表裡面的資料到底是怎 麼儲存的呢?

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

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

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

為了簡便期間，在後面的表示我們刪除了類似於 Key Length 的屬性，只保留 RowKey、ColumnFamily、ColumnQualifier等資訊。所以 RowKey 為 Row1 的 資料第一列表示為上圖最後一行的形式。以此類推，整個表的儲存就可以如下表示:

大家可以從上面的 kv 表現形式看出，Row11 的 phone 這列其實是沒有資料的， 在 HBase 的底層儲存裡面也就沒有儲存這列了，這點和我們傳統的關係型資料庫有很大的區別，有了這個特點， HBase 特別適合儲存稀疏表。我們前面也將了 HBase 其實是多版本的，那如果我們修改了 HBase 表的一列，HBase 又是如何儲存的呢?

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

1. HBase 支援資料多版本特性，通過帶有不同時間戳的多個 KeyValue 版本來實現的;
2. 每次 put，delete 都會產生一個新的Cell，都擁有一個版本;
3. 預設只存放資料的三個版本，可以配置;
4. 查詢預設返回最新版本的資料，可以通過制定版本號或版本數獲取舊資料。

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

HBase 的寫過程如下:

1. 先將資料寫到 WAL 中;
2. WAL 存放在 HDFS 之上;
3. 每次 Put、Delete 操作的資料均追加到 WAL 末端;
4. 持久化到 WAL 之後，再寫到 MemStore 中;
5. 兩者寫完返回 ACK 到客戶端。

MemStore 其實是一種記憶體結構，一個 Column Family 對應一個 MemStore， MemStore 裡面的資料也是對 Rowkey 進行字典排序的，如下:

既然我們寫數都是先寫 WAL，再寫 MemStore ，而 MemStore 是記憶體結構， 所以 MemStore 總會寫滿的，將 MemStore 的資料從記憶體刷寫到磁碟的操作成 為 flush:

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

1. 全域性記憶體控制;
2. MemStore 使用達到上限;
3. RegionServer 的 Hlog 數量達到上限;
4. 手動觸發;
5. 關閉 RegionServer 觸發。

每次 flush 操作都是將一個 MemStore 的資料寫到一個 HFile 裡面的，所以上 圖中 HDFS 上有許多個 HFile 檔案。檔案多了會對後面的讀操作有影響，所以 HBase 會隔一定的時間將 HFile 進行合併。根據合併的範圍不同分為 Minor Compaction 和 Major Compaction:

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

1. 將一個 column family 下所有的 Hfiles 合併成更大的;
2. 刪除那些被標記為刪除的資料、超過 TTL(time-to-live)時限的資料，以 及超過了版本數量限制的資料。
   HBase 讀操作相對於寫操作更為複雜，其需要讀取 BlockCache、MemStore 以及 HFile。

上圖只是簡單的表示 HBase 讀的操作，實際上讀的操作比這個還要複雜，我這裡就不深入介紹了。
到這裡，有些人可能就想到了，前面我們說 HBase 表按照 Rowkey 分佈到叢集的不同機器上，那麼我們如何去確定我們該讀寫哪些 RegionServer 呢?這就是 HBase Region 查詢的問題

客戶端按照上面的流程查詢需要讀寫的 RegionServer 。這個過程一般是第一次讀寫的時候進行的，在第一次讀取到元資料之後客戶端一般會把這些資訊快取到 自己記憶體中，後面操作直接從記憶體拿就行。當然，後面元資料資訊可能還會變動， 這時候客戶端會再次按照上面流程獲取元資料。到這裡整個讀寫流程得基本知識就講完了。

3. RowKey 設計要點

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

HBase 中的 Rowkey 主要有以下的作用:

1. 讀寫資料時通過 Row Key 找到對應的 Region
2. MemStore 中的資料按 RowKey 字典順序排序
3. HFile 中的資料按 RowKey 字典順序排序

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

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

這三種 Rowkey 的設計非常常見，具體的內容圖片上也有了，我就不打文字了。 資料如果只是儲存在哪裡其實並沒有什麼用，我們還需要有辦法能夠使用到裡面的資料。幸好的是，當前 HBase 有許多的元件可以滿足我們各種需求。如下圖是 HBase 比較常用的元件:

4. HBase 生態介紹

HBase 的生態主要有:

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

下面簡單介紹一下這些元件

5. HBase 典型案例分析

有了這麼多元件，我們都可以幹什麼呢?來看看 HBase 的典型案例。

HBase 在風控場景、車聯網/物聯網、廣告推薦、電子商務等行業有著廣泛的使用。下面是四個典型案例的架構，由於圖片裡有詳細的文字，我就不再打出來了。

大家工作學習遇到 HBase 技術問題，把問題釋出到 HBase 技術社群論壇 http://hbase.group，歡迎大家論壇上面提問留言討論。想了解更多 HBase 技術關注 HBase 技術社群公眾號(微訊號:hbasegroup)，非常歡迎大家積極投稿。