縱觀數據庫發展的幾十年，從網狀數據庫、層次數據庫到RDBMS數據庫，在最近幾年的NewSQL的興起，加上開源的運動，再加上云的特性，可以說是日新月異。在20世紀80年代后，大部分的業務確定了使用RDBMS數據為存儲基礎。新世紀開始，隨著互聯網的發展，數據量的增大，慢慢RDBMS數據庫撐不住了，就出現了讀寫分離策略。隨著壓力增加，Master撐不住了，這時就要分庫了，把關聯不大的數據分開部署，一些join查詢不能用了，需要借助中間層。隨著數據量的進一步增加，一個表的記錄越來越大，查詢就變得很慢，于是又得搞分表，比如按ID取模分成多個表以減少單個表的記錄數。經歷過這些事的人都知道過程是多么的折騰。在不同的場景下，就出現各自優秀的分布式數據庫，比如在文檔型存儲下的MongoDB，KV類型的Redis，再比如今天講的列族類型的HBase。

大數據時代數據存儲的特點為：基礎量大、增長快、計算與存儲的實時性要求迫切、支持時效性短、易發散、易產生臟數據，這些HBase自出生起，就滿足這些需求。在大數據時代，我們認為HBase是公認的大數據存儲。HBase的原型出自Google的BigTable，這個跟大數據的GFS及MapReduce齊名的三篇論文，由此開創了大數據時代。目前在阿里，已經有上萬臺的HBase集群，在各個場景下有廣泛的應用。

為什么要上云，需要了解到HBase本身比較復雜，這涉及到分布式、數據存儲、響應延遲，索引等一些分布式、數據庫的知識，對于運維好這個復雜系統還是有一定的難度;要有很好的使用姿勢，雖然API比較簡單，但是各種組合情況下，暢玩好HBase還是需要一定的功力; 上云是趨勢，自己去基于ECS建設又不太了解云環境下，怎么正確部署HBase，怎么跟OSS等云上組件配合。

為此，我們提供云HBase加上專家服務 解決以上3個問題

最后，HBase在阿里集團使用了6年之久，已經在HBase的性能、運維等積累了大量的經驗，我們希望把這些回饋給客戶，例如：我們僅僅單條低字節高頻寫入情況就比社區版本高出30%+的性能。

目前提供的價值點有，以下幾點：

• 高可靠： 數據備份，數據可靠性9個9
• 高可用：Master節點強制HA機制，出現問題后直接切換
• 易運維：一鍵構建、配置修改、一鍵擴容、自動備份、數據流入
• 高性能：比如開源性能大幅度提升30%+
• 低成本：后續本地盤、云盤、OSS分級別存儲

技術架構

從技術架構層面看，大致如下：

基礎資源層：我們底層使用了ECS及本地磁盤的架構，保證在低成本的同時又具備高性能

基礎軟件層，我們使用了ALi-JDK及ALi-Liunx，這兩個都有專門的團隊在維護，對云HBase的貢獻，比如：改進gc算法減少毛刺，改進linux中斷提升性能。

HBase內核層，目前使用是跟阿里集團內部一致的版本，也就是說內部所有的性能優化、功能增強在公有云的客戶都可以享受到。這些包括但不限于：提升讀寫性能、增強穩定性、降低磁盤、網絡抖動引起的毛刺等等。 -另外就是運維平臺，逐步完善，后續會包括 監控報警、配置管理、健康診斷等等 易于運維的功能。

目前支持兩種訪問網絡類型，第一種是經典網絡、第二種是VPC網絡。區別就是VPC再加了一層網絡隔離。

經典網絡：

VPC網絡：

使用場景

HBase作為默認的大數據時代的存儲，基本解決以下三大類的場景：

平臺類，基本存放是平臺的產品，就是其它軟件的存儲，比如 目前很就行的kylin，阿里內部的日志同步工具TT，圖組件Titan等。此類存放的往往平臺的數據，有時候往往是無業務含義的。作為平臺的底層存儲使用。

用戶行為類，此類主要是面向各個業務系統。這里的用戶不僅僅指的人，也包括物，比如物聯網。在阿里主要還是人產生的數據，比如：淘寶收藏夾、交易數據、旺旺聊天記錄等等。這里使用比較直接，就直接存放HBase，再讀取。難度就是需要支持千萬級別的并發寫訪問及讀取，需要解決服務質量的問題，比如GC了，就出現大量的毛刺。

報表類的需求，比如報表、大屏等，最出名的就是阿里巴巴的天貓雙十一大屏。

基本上：Mysql支持小數據量，查詢較為復雜的數據應用;HBase支持大數據，查詢較為簡單的數據應用。

后續計劃

一些功能，比如同步等，產品化，直接從rds及離線系統導入數據到云HBase系統中

完善云HBase功能，不斷做精細化

提供HBase on OSS的能力，降低數據存儲的成本

提供雙集群多寫多度的能力，做多區多地域容災