當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就可以滿足非常高的複雜分析的要求。