摘要：?阿里云HBase2.0也就是阿里云即將要上線的ApsaraDB for HBase2.0。它不僅兼容開源HBase2.0，也承載著阿里多年大規模HBase使用的技術積淀，還有廣大公有云用戶喜歡的商業化功能。

一、為什么選擇HBase及HBase生態？

存儲量/并發計算增大

隨著關系型數據庫存儲和業務的挑戰，數據量慢慢變大。其實，在以前包括阿里在內的很多企業使用的往往是使用ECS下面掛載MySQL數據庫或者磁盤這樣的方式，這樣的架構能夠具備四種能力，即計算力、檢索、存儲以及事務。而當數據量變大之后，阿里就換成了另外一套架構，主要使用Spark+下層的ES/Solr和HBase以及列存相應的組件。這樣的架構則面對著數據量大、分布式復雜以及成本高等問題。

非結構化業務增多

目前來說，非結構化業務也在逐漸地增多，包括時序和時空數據以及最新的NewSQL等，這里的NewSQL雖然屬于比較時髦的詞，但是實際上是在分布式上加了一些SQL的能力。這里對于工程的挑戰就是比較復雜。

如下圖所示的是DB-Engines Ranking的市場關注度的大致趨勢圖。可以看到在2016年到現在已經過去的兩年時間中不同類型數據存儲大致的情況，可以看到關系型數據庫關注度呈現下降的趨勢，兩年的時間內關注度就下降了將近一半；而關注度增長最快的是時序數據，在最近一年其增長了將近兩倍，而圖以及KV等數據存儲也在增長。可以發現，在關注度方面，非關系型數據越來越多，這也是因為我們的業務變得更加多元化，特別是物聯網的加快發展。

引入更多的數據

其實可以將數據世界大致分為四個象限：復雜性、靈活性、讀寫延遲以及分布式。分布式肯定是少不了的，缺少了分布式什么問題都解決不了，所以就需要在另外的復雜性、靈活性和讀寫延遲中尋找平衡。大致發現Hadoop、Spark解決的是靈活性和復雜性的問題；一邊則是滿足讀延遲， Kylin主要滿足讀延遲的，提前需要Build一些Cube；另外在延遲及靈活性上一般是使用HBase加上solr等搭配。包括Hadoop以及Spark也都可以和HBase進行組合實現一些業務，kylin也是構建在HBase之上的，并且很多企業也都是這樣做的。

云的能力

因為本文的主題是云能夠為HBase帶來什么，其實云所能帶來很多東西。比如云帶來的彈性、復用、分離以及新硬件等特性，對于目前層出不窮的新硬件而言，像RDMA、FPGA、GPU等新硬件，很多小公司不會自己去購買這些，但是在云上就會提供這些硬件的能力，并且不同公司可以去復用這些硬件。云所帶來的價值更多地就是為了降低成本，以及快速構建系統獲取更多的商機。 這些就是云的能力。

總結-四大因素

云的能力可以大致總結為四大因素，即分布式、計算力延伸、非結構化數據以及云化。HBase生態就能夠很好地解決前三點問題，而云HBase就融合最后一點的云化能力。

二、云HBase架構的思考

大數據數據庫

首先，所有的底層存儲將會提供冷、溫、熱三種介質，一種是純粹的SSD，一種是SSD和SATA混合，這里用到了2塊SSD和10塊SATA，也就是SSD作為一個寫的緩存，而第三種是純粹的SATA，且做了EC。在這之上是阿里的分布式文件系統盤古以及文件接口。每個集群也可以同時支持多種介質，不同介質可以采取不同的壓縮算法降低成本。此外，計算資源和存儲資源也是完全分離的，分離之后可以進行單獨的擴容，完全不用擔心到底是存儲多還是計算多.

HBase天生就提供了分布式KV的核心能力，但是實際上還缺少一些分布式檢索的能力，所以需要融合分布式索引。在這一層需要構建分布式KV及檢索的能力、降低大內存計算的影響以及KV及索引互相之間內嵌數據同步，滿足數據一致性的要求。

第三層就是多模式的入口，這一層提供了NewSQL入口，可以滿足百TB的TP需求，并且提供了一定的聚合能力。包括對于時序數據庫而言，之前也看到了DB-Engines Ranking排名來看，時序數據庫發展是最快的，時序兩倍、圖一倍增速。這里的核心能力就是打造一個Proxy層，提供基礎非結構化的Graph、時序和時空等能力。

最后是必須要引入Spark的能力，上面的聚合都是單獨的Client節點或者Proxy進行的聚合，是無法滿足非常復雜的場景的。HBase結合Spark將會提供靈活獨特的資源滿足。這就是阿里巴巴的大數據數據庫的總體結構，相信很多公司自己在做的時候也大致是這樣的，當然對于具體的每一層而言都可能以自己的方式進行構建。

總結能力

總結能力而言就是超越Apache HBase、多模式的數據庫以及混合的負載，最終實現低成本、全分布式架構等能力，能夠滿足80%以上中小企業的訴求。

三、部署細節

云HBase細節部署結構

對于云HBase的部署結構而言，會先在大規格上面部署proxy接口，前面做一個負載均衡去提供SQL、Thrift的Rest、OpenTSDB、JanusGraph以及GeoMesa這樣的能力，RS和Solr等組件都會直接承接到下面的共享存儲。

下圖所展現的是全局的部署結構。圖中分為杭州區域和北京區域，當然除此之外還有其他區域，每個區域之間有一個類似移動容災的能力。這套集群的存儲節點和可用區A的數據是放在一起的，冷存儲是多個可用區混合的。對于阿里云等云廠商而言，可用區的概念就是其爆炸半徑，也就是某一個炸彈在某個地方爆炸了但是卻不能影響云中心，這就是可用區的概念。大概兩個可用區之間，一般而言的延遲是1到2毫秒，甚至是3毫秒，所以如果是比較熱的數據盡量可用區內放，如果是比較冷的數據，比如車聯網或者20~30毫秒延遲也沒有什么影響的情況下，如果訪問頻次也比較低，那么就可以直接把這些數據拖出來。基本原則是：在多個可用區大家共享一個冷集群可以降低成本，而熱集群和溫集群則是每個可用區都有以此來保證低延遲。兩地之間也可以做一些容災的事情。

四、運維能力

運維能力主要首先體現在產品層、接入層和網絡層，無論是滴滴、360還是其他的公司也都是這樣做的，阿里云是按照非常標準的網絡協議或者云協議來實現的。

其次，阿里云大數據數據庫服務所能提供的自動化運維能力包括自動部署集群、自動守護進程、可用性檢測以及報警、節點和磁盤擴容等。

總結而言，阿里云大數據數據庫所提供的運維能力如下所示。可能僅需要點一個按鈕，成千上百的進程就生成了，而且可以在15分鐘之內交付集群，但是如果線下自己搭建則是非常困難的。而且不需要提前規劃容量，因為存儲和計算分離，所以可以隨時進行調整，發現資源少了或者多了，隨時都可以通過點擊按鈕進行調整，也是非常方便的。

五、生態組件

對于生態組件這部分由于時間關系，就簡單講下。Phoenix、JanusGraph、OpenTSDB、GeoMesa單獨講也不少內容。講下Spark，目前HTAP非常火爆。跟HBase結合做復雜分析的是Spark，Spark可以配合HBase一起做非常復雜的計算。推薦直接采取SQL的入口，比較簡單方便，且目前做了不少優化，比如算子下沉等。

六、實際案例

HBase能夠支持大概8種場景，即對象存儲、推薦畫像、消息/訂單存儲、Feeds流、NewSQL、Cube分析、時空數據、時序數據等場景。

客戶案例 - 某車聯網公司

該車聯網公司大概有一百萬輛車，那么一年大概需要存儲300T的數據，對于300T的數據而言，6個月以上是低頻訪問，而6個月之前則可以放到冷存儲，可以以1.3份EC進行訪問。設計使得HBase能夠同時支持兩種文件系統，一種文件系統支持寫入HDFS，另外一種支持寫入另一種介質。

客戶案例 - 大數據風控公司

另外一個案例是大數據風控公司，其主要做的是大數據風控存儲，其首先需要爬取很多數據過來并將這些數據塞到HBase里面去，并做了一些Spark算法訓練，再去做一些ECS的實時數據報表，這也是一個非常典型的場景。

客戶案例 - 某社交公司

某社交公司的案例大致就是相當于用戶注冊了一個賬號，就需要向你推薦其他的人，如何實現推薦呢？其實就是當注冊完成之后，數據會立即流入到SparkStreaming里面，之后立即查找用戶標簽，并根據用戶標簽對大量相關的用戶進行推薦。

客戶案例 - 某基金公司

這個基金公司的數據量非常多，有萬億以上的數據，能夠達到100T以上，其是使用Phoenix做搜索和實時查詢的，其將索引通過ODPS+Spark將數據拖取出來并放入到HBase里面去，簡單而言就是需要支持如此大的數據量在延遲比較低的情況下的查詢。

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

大部分做報表的公司基本都是這樣操作的，最適合的就是用Lambda最適合查詢低延遲、數據量大并且簡單的場景，并且可以定制業務本身，來滿足業務訴求。離線建好Cube，流式實現實時更新，并且數據量可以達到20T+左右。

七、展望未來

硬件發展帶來的變化

大家能夠發現硬件的發展變化是非常快的，萬兆網的普及以及存儲和計算的分離不斷加速；其次，固態存儲容量更大，價位更低，未來SSD甚至會比SATA更加便宜；此外，內存也在不斷增長，并且去向可持久化，未來使用內存當做存儲也能會快速實現。

提升分析能力

原來需要結合Spark所提供的分析能力，如何實現及時分析以及行轉列等。

不斷加強單個組件的能力

阿里云的技術團隊也在不斷加強單個組件的能力，包括完善和滿足圖、時空、時序的訴求。

其實還有非常有意思的兩點，離線Compaction和備份即是分析。

離線Compaction

離線Compaction其實是非常耗費臨時流量的，這時候通過引入彈性資源，因為ECS里面有FPGA的彈性資源，當將FPGA的彈性資源申請過來，把數據拖到彈性資源池進行Compaction，這是不會對原集群的CPU計算產生影響的。阿里云技術團隊在這部分使得集群沒有Major的影響。

備份及分析

其次因為云上很多數據需要備份，既然需要備份，那么為何不備份成列存？比如HBase是行存的，將其備份成列存，這樣就可以直接滿足列式分析，這也是目前阿里云在研究的內容，也就是將備份數據作為直接分析的場景。比如上圖中的HBase前面的數據流過來，將實時或者半實時的數據轉化為列存，在列存儲上面架一個Spark就可以滿足非常高的復雜分析的要求。

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。