為什麼

縱觀資料庫發展的幾十年，從網狀資料庫、層次資料庫到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再加了一層網路隔離。
經典網路：

使用場景

HBase作為預設的大資料時代的儲存，基本解決以下三大類的場景：

• 平臺類，就是其它軟體的儲存，比如目前很流行的Kylin，阿里內部的日誌同步工具TT，圖元件Titan等。此類存放的往往是平臺的資料，有時候往往是無業務含義的。作為平臺的底層儲存使用。
• 使用者行為類，此類主要是面向各個業務系統。這裡的使用者不僅僅指的人，也包括物，比如物聯網。在阿里主要還是人產生的資料，比如：淘寶收藏夾、交易資料、旺旺聊天記錄等等。這裡使用比較直接，就直接存放HBase，再讀取。難度就是需要支援千萬級別的併發寫訪問及讀取，需要解決服務質量的問題，比如GC了，就出現大量的毛刺。
• 報表類的需求，比如報表、大屏等，最具代表的就是阿里巴巴的天貓雙十一大屏。如下圖所示：
  

基本上：Mysql支援小資料量，查詢較為複雜的資料應用；HBase支援大資料，查詢較為簡單的資料應用。

後續計劃

• 一些功能，比如同步等，產品化，直接從rds及離線系統匯入資料到雲HBase系統中
• 完善雲HBase功能，不斷做精細化
• 提供HBase on OSS的能力，降低資料儲存的成本
• 提供雙叢集多寫多度的能力，做多區多地域容災
• 關注HBase2.0，與社群一起提升HBase核心的能力及穩定性