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

一、為什么選擇HBase及HBase生態(tài)？

存儲(chǔ)量/并發(fā)計(jì)算增大

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

非結(jié)構(gòu)化業(yè)務(wù)增多

目前來說，非結(jié)構(gòu)化業(yè)務(wù)也在逐漸地增多，包括時(shí)序和時(shí)空數(shù)據(jù)以及最新的NewSQL等，這里的NewSQL雖然屬于比較時(shí)髦的詞，但是實(shí)際上是在分布式上加了一些SQL的能力。這里對于工程的挑戰(zhàn)就是比較復(fù)雜。

如下圖所示的是DB-Engines Ranking的市場關(guān)注度的大致趨勢圖?？梢钥吹皆?016年到現(xiàn)在已經(jīng)過去的兩年時(shí)間中不同類型數(shù)據(jù)存儲(chǔ)大致的情況，可以看到關(guān)系型數(shù)據(jù)庫關(guān)注度呈現(xiàn)下降的趨勢，兩年的時(shí)間內(nèi)關(guān)注度就下降了將近一半；而關(guān)注度增長最快的是時(shí)序數(shù)據(jù)，在最近一年其增長了將近兩倍，而圖以及KV等數(shù)據(jù)存儲(chǔ)也在增長?？梢园l(fā)現(xiàn)，在關(guān)注度方面，非關(guān)系型數(shù)據(jù)越來越多，這也是因?yàn)槲覀兊臉I(yè)務(wù)變得更加多元化，特別是物聯(lián)網(wǎng)的加快發(fā)展。

引入更多的數(shù)據(jù)

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

云的能力

因?yàn)楸疚牡闹黝}是云能夠?yàn)镠Base帶來什么，其實(shí)云所能帶來很多東西。比如云帶來的彈性、復(fù)用、分離以及新硬件等特性，對于目前層出不窮的新硬件而言，像RDMA、FPGA、GPU等新硬件，很多小公司不會(huì)自己去購買這些，但是在云上就會(huì)提供這些硬件的能力，并且不同公司可以去復(fù)用這些硬件。云所帶來的價(jià)值更多地就是為了降低成本，以及快速構(gòu)建系統(tǒng)獲取更多的商機(jī)。 這些就是云的能力。

總結(jié)-四大因素

云的能力可以大致總結(jié)為四大因素，即分布式、計(jì)算力延伸、非結(jié)構(gòu)化數(shù)據(jù)以及云化。HBase生態(tài)就能夠很好地解決前三點(diǎn)問題，而云HBase就融合最后一點(diǎn)的云化能力。

二、云HBase架構(gòu)的思考

大數(shù)據(jù)數(shù)據(jù)庫

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

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

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

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

總結(jié)能力

總結(jié)能力而言就是超越Apache HBase、多模式的數(shù)據(jù)庫以及混合的負(fù)載，最終實(shí)現(xiàn)低成本、全分布式架構(gòu)等能力，能夠滿足80%以上中小企業(yè)的訴求。

三、部署細(xì)節(jié)

云HBase細(xì)節(jié)部署結(jié)構(gòu)

對于云HBase的部署結(jié)構(gòu)而言，會(huì)先在大規(guī)格上面部署proxy接口，前面做一個(gè)負(fù)載均衡去提供SQL、Thrift的Rest、OpenTSDB、JanusGraph以及GeoMesa這樣的能力，RS和Solr等組件都會(huì)直接承接到下面的共享存儲(chǔ)。

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

四、運(yùn)維能力

運(yùn)維能力主要首先體現(xiàn)在產(chǎn)品層、接入層和網(wǎng)絡(luò)層，無論是滴滴、360還是其他的公司也都是這樣做的，阿里云是按照非常標(biāo)準(zhǔn)的網(wǎng)絡(luò)協(xié)議或者云協(xié)議來實(shí)現(xiàn)的。

其次，阿里云大數(shù)據(jù)數(shù)據(jù)庫服務(wù)所能提供的自動(dòng)化運(yùn)維能力包括自動(dòng)部署集群、自動(dòng)守護(hù)進(jìn)程、可用性檢測以及報(bào)警、節(jié)點(diǎn)和磁盤擴(kuò)容等。

總結(jié)而言，阿里云大數(shù)據(jù)數(shù)據(jù)庫所提供的運(yùn)維能力如下所示。可能僅需要點(diǎn)一個(gè)按鈕，成千上百的進(jìn)程就生成了，而且可以在15分鐘之內(nèi)交付集群，但是如果線下自己搭建則是非常困難的。而且不需要提前規(guī)劃容量，因?yàn)榇鎯?chǔ)和計(jì)算分離，所以可以隨時(shí)進(jìn)行調(diào)整，發(fā)現(xiàn)資源少了或者多了，隨時(shí)都可以通過點(diǎn)擊按鈕進(jìn)行調(diào)整，也是非常方便的。

五、生態(tài)組件

對于生態(tài)組件這部分由于時(shí)間關(guān)系，就簡單講下。Phoenix、JanusGraph、OpenTSDB、GeoMesa單獨(dú)講也不少內(nèi)容。講下Spark，目前HTAP非?；鸨?。跟HBase結(jié)合做復(fù)雜分析的是Spark，Spark可以配合HBase一起做非常復(fù)雜的計(jì)算。推薦直接采取SQL的入口，比較簡單方便，且目前做了不少優(yōu)化，比如算子下沉等。

六、實(shí)際案例

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

客戶案例 - 某車聯(lián)網(wǎng)公司

該車聯(lián)網(wǎng)公司大概有一百萬輛車，那么一年大概需要存儲(chǔ)300T的數(shù)據(jù)，對于300T的數(shù)據(jù)而言，6個(gè)月以上是低頻訪問，而6個(gè)月之前則可以放到冷存儲(chǔ)，可以以1.3份EC進(jìn)行訪問。設(shè)計(jì)使得HBase能夠同時(shí)支持兩種文件系統(tǒng)，一種文件系統(tǒng)支持寫入HDFS，另外一種支持寫入另一種介質(zhì)。

客戶案例 - 大數(shù)據(jù)風(fēng)控公司

另外一個(gè)案例是大數(shù)據(jù)風(fēng)控公司，其主要做的是大數(shù)據(jù)風(fēng)控存儲(chǔ)，其首先需要爬取很多數(shù)據(jù)過來并將這些數(shù)據(jù)塞到HBase里面去，并做了一些Spark算法訓(xùn)練，再去做一些ECS的實(shí)時(shí)數(shù)據(jù)報(bào)表，這也是一個(gè)非常典型的場景。

客戶案例 - 某社交公司

某社交公司的案例大致就是相當(dāng)于用戶注冊了一個(gè)賬號，就需要向你推薦其他的人，如何實(shí)現(xiàn)推薦呢？其實(shí)就是當(dāng)注冊完成之后，數(shù)據(jù)會(huì)立即流入到SparkStreaming里面，之后立即查找用戶標(biāo)簽，并根據(jù)用戶標(biāo)簽對大量相關(guān)的用戶進(jìn)行推薦。

客戶案例 - 某基金公司

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

客戶案例 - 某公司報(bào)表系統(tǒng)

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

七、展望未來

硬件發(fā)展帶來的變化

大家能夠發(fā)現(xiàn)硬件的發(fā)展變化是非?？斓模f兆網(wǎng)的普及以及存儲(chǔ)和計(jì)算的分離不斷加速；其次，固態(tài)存儲(chǔ)容量更大，價(jià)位更低，未來SSD甚至?xí)萐ATA更加便宜；此外，內(nèi)存也在不斷增長，并且去向可持久化，未來使用內(nèi)存當(dāng)做存儲(chǔ)也能會(huì)快速實(shí)現(xiàn)。

提升分析能力

原來需要結(jié)合Spark所提供的分析能力，如何實(shí)現(xiàn)及時(shí)分析以及行轉(zhuǎn)列等。

不斷加強(qiáng)單個(gè)組件的能力

阿里云的技術(shù)團(tuán)隊(duì)也在不斷加強(qiáng)單個(gè)組件的能力，包括完善和滿足圖、時(shí)空、時(shí)序的訴求。

其實(shí)還有非常有意思的兩點(diǎn)，離線Compaction和備份即是分析。

離線Compaction

離線Compaction其實(shí)是非常耗費(fèi)臨時(shí)流量的，這時(shí)候通過引入彈性資源，因?yàn)镋CS里面有FPGA的彈性資源，當(dāng)將FPGA的彈性資源申請過來，把數(shù)據(jù)拖到彈性資源池進(jìn)行Compaction，這是不會(huì)對原集群的CPU計(jì)算產(chǎn)生影響的。阿里云技術(shù)團(tuán)隊(duì)在這部分使得集群沒有Major的影響。

備份及分析

其次因?yàn)樵粕虾芏鄶?shù)據(jù)需要備份，既然需要備份，那么為何不備份成列存？比如HBase是行存的，將其備份成列存，這樣就可以直接滿足列式分析，這也是目前阿里云在研究的內(nèi)容，也就是將備份數(shù)據(jù)作為直接分析的場景。比如上圖中的HBase前面的數(shù)據(jù)流過來，將實(shí)時(shí)或者半實(shí)時(shí)的數(shù)據(jù)轉(zhuǎn)化為列存，在列存儲(chǔ)上面架一個(gè)Spark就可以滿足非常高的復(fù)雜分析的要求。

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。