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

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

存儲量/并發(fā)計算增大

隨著關(guān)系型數(shù)據(jù)庫存儲和業(yè)務(wù)的挑戰(zhàn)，數(shù)據(jù)量慢慢變大。其實，在以前包括阿里在內(nèi)的很多企業(yè)使用的往往是使用ECS下面掛載MySQL數(shù)據(jù)庫或者磁盤這樣的方式，這樣的架構(gòu)能夠具備四種能力，即計算力、檢索、存儲以及事務(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ù)據(jù)以及最新的NewSQL等，這里的NewSQL雖然屬于比較時髦的詞，但是實際上是在分布式上加了一些SQL的能力。這里對于工程的挑戰(zhàn)就是比較復(fù)雜。

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

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

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

云的能力

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

總結(jié)-四大因素

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

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

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

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

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

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

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

總結(jié)能力

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

三、部署細節(jié)

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

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

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

四、運維能力

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

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

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

五、生態(tài)組件

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

六、實際案例

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

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

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

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

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

客戶案例 - 某社交公司

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

客戶案例 - 某基金公司

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

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

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

七、展望未來

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

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

提升分析能力

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

不斷加強單個組件的能力

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

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

離線Compaction

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

備份及分析

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

原文鏈接

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