1. 八年磨一劍
   1.1 HBase 的前世今生

關係型資料庫的發展已經經歷了 40 多年的歷史了，而 HBase 以及大資料這套東 西的歷史大概從 2006 年被認為是大資料的發起時期到現在，也就是 13 年左右 而已。那麼，為什麼會出現 HBase 以及 Hadoop 整體生態鏈的這些內容呢?這 是因為在大資料時代，傳統資料庫需要面對很多挑戰，出現了資料量增多、業務 複雜度提升、非結構化資料和結構化資料並存等諸多問題。這些問題所帶來的最 直接的就是成本挑戰，因此特別需要價格低廉的資料庫來解決問題。

這也就是 Google 提出 BigTable 開源最佳實現的原因。Google 是全球最大的搜 索引擎，當他們發現出現的儲存成本問題之後，通過內部研究就發出來關於 BigTable 的這篇論文，而大概在 2006 年的時候也就發起了 HBase 這個專案，並 且在兩年之後其就成為 Hadoop 的子專案，經過了十幾年的發展，目前演變到了 2.0 版本。HBase 能夠幫助我們以低成本解決大資料量、高併發、低時延的問題， 並且保證了低成本的儲存。

1.2 阿里的 HBase 之旅

為何叫做“八年磨一劍”呢?這其實與阿里巴巴對於 HBase 的研發歷程是緊密相 關的。在 2010 年，HBase 正式成為了 Apache 的頂級專案，與此同時阿里巴巴 內部的業務也達到了瓶頸期，因此在 2010 年阿里巴巴開始對於 HBase 進行預研， 經過了持續 8 年的研發，在 2017 年的時候輸出到阿里雲上，並將 HBase 的能力 提供給廣大的使用者。其實，在阿里集團內部已經有了超過 12000 臺的 HBase 服 務器規模，而最大叢集也超過了 2000 臺，這在世界上都是數一數二的，並且也 經過了天貓“雙 11”的歷練。

阿里投入了很多資源和人力來研發 HBase，所以開源社群也給予了非常積極的回 饋。目前第一個東八區的 PMC 就誕生在阿里雲，而整個阿里集團內有 3 個 HBase PMC、6 個 Committer 以及幾十位核心貢獻者，並且共享了 200 多個核心 patch。 此外，阿里雲的 HBase 版本相比於開源版本在很多方面也有極大的提升。

1.3 HBase 適合的場景和問題

(1) 關係型資料庫與 HBase 的區別
HBase 等 NoSQL 出現的原因是傳統的關係型資料庫在面對大資料量、高業務復 雜度以及高成本的挑戰時，無法對於底層進行優化和改進。如下圖所示的表格能 夠幫助大家對比關係型資料庫與 HBase 的主要區別。

關係型資料的主要應用場景基本都是交易類場景，而 HBase 所代表的的非關係 型資料庫所需要解決的就是相容結構化和非結構化的資料，解決交易場景之外的 實時業務或者 OLAP 分析以及大規模儲存。而在可擴充套件性上，關係型資料庫單表 不超過千列，一般在 GB~TB 級別，而對於 HBase 而言，這樣的資料量就不算什 麼挑戰了，一張表會輕鬆突破百億行和百萬列，HBase 比較適合 200G 到 10P 資料量級別。在效能方面也能體現出關係型資料和 HBase 最大的區別，對於關係型 資料庫而言，10W 級別的效能就已經很強了，HBase 能力能夠達到 5000 萬併發 量，其核心需要解決的就是高併發和低吞吐。在成本方面，傳統關係型資料庫需 要使用高效能硬體，隨著也帶來了成本問題，而 HBase 則是選擇了另外一條路， 通過本地盤和普通 CPU 實現，其核心的儲存結構不再是關係型儲存結構，而是 合併成批量讀寫，充分地利用硬碟高吞吐的能力來達到低成本。總結而言，HBase 資料庫解決的核心問題就是相容結構化和非結構化的資料、大資料量、高併發、 低延時等問題。

(2) ApsaraDB HBase 典型場景
NoSQL 資料庫和傳統資料的一個較大區別就是傳統資料庫比較適合所以行業的 交易模型，而 HBase 的能力非常聚焦，其適合時序資料、時空資料、Cube 分析、 NewSQL、Feeds 流、訊息/訂單儲存、推薦畫像、物件儲存等 8 個場景。接下來 逐一介紹各個典型場景。

時序資料:在如今這個 IoT 的時代，出現了大量的時序資料。因為各種感測器比 較多，時序資料需要滿足高併發、海量儲存等基本要求，除了 IoT 之外，在股票 以及監控資料裡面也需要用到這樣的時序資料。
時空資料:軌跡以及氣象網格資料也需要 HBase 的高併發和海量儲存能力。 Cube 分析:實時報表以及資料科學家需要進行實時資料分析，這些需要以很低的時延查詢出來，並且併發量非常高，這時候就需要用到 Cube 的能力。

NewSQL:對於傳統 SQL 所不能解決的一些問題，比如效能瓶頸，這些就需要使 用 NewSQL 能力，並且除了能夠解決效能問題之外，還會有一定的更新能力。 HBase 能夠較好地適應這種場景，除了支援 SQL 之外，還支援二級索引、動態增 加列，所以很多元資料庫也使用了 HBase。

Feeds 流:Feeds 流的典型應用場景就是微信朋友圈以及微博等社交網路，其所 需要的就是高併發的請求訪問，因為使用者數非常多，需要保證一致性體驗，HBase 非常適合這樣的場景。

訊息/訂單儲存:訂單數量是非常多的，所以需要強同步，並且可靠性不能丟， 對於聊天訊息而言也是一樣的，這就會用到 HBase 的強一致性同步以及大資料 儲存能力。

推薦畫像:推薦畫像在使用者特徵裡面使用的比較多，一般而言在做畫像時對於使用者會勾畫很多特徵，資料表中的每一列就可以放一個特徵，而隨著不斷深入地挖掘，特徵就會越來越多，而傳統關係型資料庫首先不能夠儲存太多列，超過 1000 列就遇到瓶頸了，而在真正進行儲存的時候可能需要百萬列。其次，對於傳統關係型資料庫而言，如果某列存在空值，依然佔據空間，而 HBase 不僅可以動態地增加列，而且如果某列為空就不會佔據空間，所以非常適合這樣的場景。

物件儲存:通常而言物件儲存最可能用到的就是 OSS，但是 OSS 比較適合高並 發地寫，但是並不適合高併發地讀，但是還有很多資料比如圖片、網頁、文件、 新聞等，除了需要能夠寫入之外，還需要提供高併發地查詢能力的場景下，就比 較適合使用 HBase 作為前置資料儲存。而如果隨著時間的遷移，一些資料的重要 性降低了，那就可以通過 HBase 本身的能力將資料遷移到 OSS 裡面，作為溫資料或者冷資料的歸檔。

上面大致分享了 HBase 的整個發展歷程以及 HBase 的適合場景。總結而言，就是阿里巴巴經過了 8 年的研發將自己改進的 HBase 版本能夠提供給廣大的使用者， 這就叫做 8 年磨一劍。這首先說明了阿里巴巴有很強的技術實力，其次說明了 HBase 有它自己非常適合的場景，比如高併發、低時延以及低成本需求的場景。

2. 重新定義 HBase

大家都知道開源軟體在穩定性以及各方面的能力上都往往不能夠達到企業實際 應用的要求。雖然這些開源軟體的核心能力非常強大，但是當在企業中應用的時 候卻是比較困難的。而阿里巴巴在 HBase 方面做了很多的工作，也經過內部的使 用提升了 HBase 的能力，使其能夠更好地適應企業的應用，並且針對不同的場景 提供了不同的產品形態。

2.1 HBase2.0 解讀

HBase 2.0 版本是本次重點發布的版本。實際上，社群在 2014 年 6 月開始迭代， 經過了 4 年的時間，終於在 2018 年 4 月 30 日正式釋出。而阿里巴巴也立即將 原來的一些能力反向地融合到 HBase 最新的版本中，並且經過了穩定性和效能 測試，這個版本將會在 6 月 6 日正式釋出公測。

HBase 2.0 版本經過四年時間的研發，其在架構上也發生了較大的變化，在效能 以及穩定性上也有了較大的提升。總結而言，產生了兩個最有價值的場景，其中 一個是大容量、高併發、低延時的寫場景，相比於 1.X 版本，HBase 2.0 版本提升了穩定性，將記憶體全部放在堆外進行管理，不再完全依賴 JVM，這是因為 JVM 存在一些始終難於解決的問題。此外 HBase 2.0 版本還提升了效能，對於資源管理器進行了優化，解決了效能毛刺問題。此外，效能的增強還體現在了時延的提 升上。HBase 處理時延可以穩定在 50ms 以內。這個對 HBase 來說拓寬了一個大 容量推薦場景;這個也是其他目前資料庫引擎不具備的能力。例如金融，社交朋友圈等行業有廣泛的訴求。另外一個場景就是高效能物件儲存場景，以前包括阿里集團更多的是適合結構化的資料的儲存。HBase 2.0 版本支援高效物件儲存， 能高效地儲存那些 100k~10M 中等大小的物件。有了這個能力之後，就相當於在 物件儲存能力上有了非常強的提升，可以包裝出一種新的產品形態或者場景，解 決不滿意物件儲存效能的，對效能有一定要求的大容量物件儲存的需求。這樣的能力預計在傳媒，教育，企業辦公等領域有廣泛的訴求。HBase 2.0 不僅能夠提供很強大的寫能力之外，還能夠提供很強大的讀能力。

2.2 重新定義產品形態

HBase 作為開源軟體，並沒有考慮很多的企業級能力，而阿里雲的 HBase 在開源軟體的基礎之上進行較大的創新和優化。首先針對於不同的業務場景，提供了不 同產品形態的 HBase。在開發測試環境下，可用性要求不高，資料量也不大，而 需要比較低的成本，這時候就可以使用單節點版本。而針對於線上業務，QPS 在 5000 萬以內，儲存在 10P 以內，需要高可靠、低時延的處理能力，阿里雲優先 推薦叢集版本。還有第三種雙活版本，在很多企業的金融級業務裡面，可用性要 求很高，也需要跨 AZ 的高可靠，需要雙活版本，一個叢集除了故障，另外一個 叢集能夠實時地進行接管。

除了提供了以上三種不同的產品形態之外，阿里雲 HBase 還在可用性、資料冷熱 分離、寫安全以及二級索引等能力上做了較大的提升。

2.3 重新定義 HBase 能力 (1) 儲存計算分離，真正的彈性

儲存計算分離這個特性是非常有價值的能力，雖然在現在企業往往也能夠自己搭建 HBase 伺服器，但是卻很難實現儲存計算分離的能力。這是因為業務會飛速發 展變化，所以難以在最初規劃時確定究竟多少資源是足夠的，後續擴充就會變得 比較麻煩，也會造成資源的浪費和比較高的成本。在阿里雲上做了儲存於計算分離，使得儲存和計算可以分開進行計費，可以單獨擴充儲存或者計算資源，這極大地有利於企業業務的靈活變化，同樣也極大地降低了成本。

(2) 多重防護機制，企業級安全

大家都知道開源版本的 HBase 基本上沒有安全能力，完全屬於“裸奔”狀態。這使 得企業資料的安全性無法得到有效的保證，因此阿里雲在 HBase 的安全方面也 做了大量的工作。比如許可權控制管理上，提供了賬號密碼驗證、ACL 許可權控制以 及抵禦惡意資料損毀上，這些方面阿里雲都貢獻了很大的能力。而在 VPC 隔離、 防 DDOS 攻擊以及 IP 白名單配置上，阿里雲也做了非常多的事情，通過多重機 制保證使用者的資料安全以及可靠性。

(3) 全量和增量備份以及恢復，資料無丟失風險

對於企業而言，最具有價值的就是資料，因此企業所最擔心的也就是資料的丟失。 藉助阿里雲 HBase 的全量和增量備份以及恢復的能力則能夠儘量降低資料丟失 的風險。首先，阿里雲在機器裡面有高可靠的能力，其次再通過全量或者增量備份一份資料到物件儲存裡面來。如果萬一出現了資料故障，也能夠迅速地將資料 恢復回來，不會有資料丟失的風險，這對於 DBA 或者企業而言，能夠有效地對於資料進行保障。

(4) 核心級優化，效能和穩定性全面提升

阿里雲具備可以稱得上東半球對於 HBase 最強的研發實力，這也是能夠非常深 刻地體現到阿里雲 HBase 產品裡面的一點。如上圖所示的是用阿里雲 HBase 與 社群的 HBase 的一個版本進行的對比情況，可以看到隨機讀最高可以提升 200% 以上，而隨機寫提升 50%以上。此外，在穩定性方面還實現了讀寫分離機制，能 夠確保讀寫不會衝突，進而保證穩定性。

(5) 重新定義運維能力，客戶基本免運維

大家都知道，21 世紀最具有價值的就是人才，HBase 的確非常好，但是其使用起來的難度也非常高，因為其技術難度的門檻放在那裡，如果沒有能力較強的人才， 很難幫助企業恢復資料，並且實時地保障業務的平穩執行。而阿里雲所提供的 HBase 版本基本上能夠實現客戶免運維。在阿里雲提供的運維自動化裡面，專家會提供 24 小時線上的服務，可以幫助客戶搞定一切運維問題。

3.生態和案例

其實企業在選擇 HBase 不僅僅是看重的是其高併發、低時延的處理能力，還看重了其背後的大資料生態，因為當有了這樣的大資料生態之後將可以做很多的事情。

3.1 使用場景和生態

(1) NewSQL-Phoenix 支援二級索引，解決 TP 資料效能瓶頸

在 NewSQL 方面，阿里雲 HBase 預設搭配了 Phoenix 元件，這樣就可以用標準 的 SQL 介面去訪問資料。此外，相比於開源版本，阿里雲的 HBase 在擴充套件性方面也有極大的提升，在這裡面可以實現更新、高併發的讀寫。並且 Phoenix 還支援二級索引能力，進而可以進一步提升效能。

(2) HTAP-同時支援 TP 和 AP

當需要大資料分析能力時，HBase 就需要結合大資料生態中一個非常重要的元件 ——Spark。Spark 可以通過三種方式訪問資料，而每種方式都有自己不同的特點， 比如直接通過 API 的方式，比較簡單，但是隻適合基本的使用;其次可以使用Spark SQL，其自帶了運算元下推、schema 對映以及各種引數調優的能力;第三種 就是在打批量訪問的時候可以直接訪問 HFile 進行分析。HBase 搭配 Spark 可以實現混合的 TP 和 AP 能力。

(3) 時序-OpenTSDB&HiTSDB，IoT 場景首選

HBase 本身自帶了開源元件 OpenTSDB，直接搭配就可以滿足時序需求。

(4) 時空-GeoMesa

HBase 結合 GeoMesa 的能力就可以將三維的精度、維度以及時間進行降維，得 到一維的資料並存儲到 HBase 裡面。

(5) 圖資料庫-HGraphDB，關係分析，風控場景必備

圖資料庫雖然不常見，但是在很多行業中使用的也非常多，比如關係分析以及風控場景。

(6) Cube-Kylin，面向資料科學家建模專用

在大資料時代，資料的價值的挖掘需要資料科學家來實現。資料科學家在進行 資料建模之前需要將資料拿出來，反覆地進行分析，所以需要很多隨機的條件下進行，想要得到低時延的反饋就需要建立 Cube 來實現。

3.2 實際客戶案例

(1) 客戶案例-某車聯網公司

對於現在的很多網際網路公司而言，往往都需要將資料高併發地寫入進來，但是超 期之後資料的價值就會降低，但是因為法律法規等方面政策的要求，這些資料不 能被刪除。這樣就需要分級儲存的能力，能夠以很低的成本解決大量資料的儲存問題。
**
(2) 客戶案例-某大資料風控公司**

(3) 客戶案例-某社交公司

對於社交網路而言，比如一個帖子需要瞬間分發給三百萬或者五百萬使用者還需要保證在幾十毫秒之內，這樣的能力目前只有 HBase 才能做到。案例中的使用者使用 了雙叢集，最高有四個 9 的可靠性，並且其 QPS 能夠達到 1 千萬以上，能夠瞬間將 Feed 流推到所有使用者上面去。

(4) 客戶案例-某基金公司

對於某基金公司而言，單張表有一萬億以上資料，而對於傳統關係型資料庫而言， 有個 1000 資料已經非常大了，而像這種百 TB 級別的資料的查詢以及少量的更新只能使用 HBase+Phoenix 搞定。

（5) 客戶案例-某公司報表系統

某公司的報表系統通過離線提前接好 Cube 實現了資料的實時更新和查詢。

在本文中，首先介紹了阿里巴巴集團對於 HBase 的八年研發歷程。第二部分，分 享了 HBase 作為一款開源軟體在很多企業級軟體功能上的不足，所以阿里雲重新定義了產品形態，並增強了 HBase 產品能力，使得企業能夠更快更好地使用 HBase 服務。最後，選擇了 HBase 所代表的不僅僅是 HBase 本身的能力，而是 其背後的整個大資料生態，在未來進行業務能力擴充套件上也是非常有幫助的。而相 比於傳統關係型資料庫 40 幾年的發展歷程，HBase 的短短十幾年的發展歷史還 是比較短的，在使用門檻上相對比較高，因此阿里雲也藉助 HBase2.0 版本釋出 的契機，聯合了一些國內頂尖的公司，比如滴滴和小米，大家一起深度地解讀 HBase 的能力和使用場景，也希望大家持續關注後續的相關解讀。