-
八年磨一劍
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 的能力和使用場景，也希望大家持續關注後續的相關解讀。
技術社群
【HBase生态+Spark社群大群】
群福利：群内每周進行群直播技術分享及問答
加入方式1：
點選link申請加入加入方式2：釘釘掃碼加入