大數據時代數據庫-雲HBase架構&生態&實踐

2018第九屆中國數據庫技術大會，阿里雲高級技術專家、架構師封神(曹龍)帶來題爲大數據時代數據庫-雲HBase架構&生態&實踐的演講。主要內容有三個方面：首先介紹了業務挑戰帶來的架構演進，其次分析了ApsaraDB HBase及生態，最後分享了大數據數據庫的實際案例。

講師介紹：

　　封神，真名曹龍，09年加入阿里，現任阿里雲高級技術專家、架構師，專一於大數據分佈式計算、數據庫、存儲領域，前後研發上萬臺Hadoop、ODPS集羣，負責阿里YARN、Spark及自主研發內存計算引擎，目前爲廣大公共雲用戶提供專業的雲HBase數據庫及計算服務。

　　正文演講：

　業務的挑戰

　　存儲量量/併發計算增大

　　現現在大量的中小型公司並無大規模的數據，若是一家公司的數據量超過100T，且能經過數據產生新的價值，基本能夠說是大數據公司了 。起初，一個創業公司的基本思路就是首先架構一個或者幾個ECS，後面加入MySQL,若是有圖片需求還可加入磁盤，該架構的基本能力包括事務、存儲、索引和計算力。隨着公司的慢慢發展，數據量在不斷地增大，其經過MySQL及磁盤基本沒法知足需求，只有分佈式化。 這個時候MySQL變成了HBase,檢索變成了Solr/ES，再ECS提供的計算力變成了Spark。但這也會面臨存儲量大且存儲成本高等問題。

非結構化業務增多

　　另一個趨勢就是非結構化的數據愈來愈多，數據結構的模式不只僅是SQL，時序、時空、graph模式也愈來愈多，須要一些新的存儲結構或新的算法去解決這類問題，也意味着所須要作的工程量就會相對較高。

引入更多的數據

　　對於數據處理大體可歸類爲四個方面，分別是複雜性、靈活性、延遲<讀,寫>和分佈式，其中分佈式確定是不可少的，一旦缺乏分佈式就沒法解決大規模問題 。靈活性的意思是業務能夠任意改變的;複雜性就是運行一條SQL可以訪問多少數據或者說SQL是否複雜;延遲也可分爲讀與寫的延遲。Hadoop & Spark能夠解決計算複雜性和靈活性，可是解決不了延遲的問題;HBase&分佈式索引、分佈式數據庫能夠解決靈活性與延遲的問題，但因爲它沒有不少計算節點，因此解決不了計算複雜性的問題。Kylin(知足讀延遲)在計算複雜性與延遲之間找了一個平衡點，這個平衡點就是怎樣快速出報表，但對於這個結果的輸入時間咱們並不關心，對於大部分的報表類的需求就是這樣的。每一個引擎都有必定的側重，沒有銀彈!

ApsaraDB HBase產品架構及改進

　　應對的辦法

　　咱們也不能解決全部的問題，咱們只是解決其中大部分的問題。如何找到一個在工程上可以解決大部分問題的方案相當重要，應對辦法：

　　分佈式：提供擴展性

　　計算?延伸：算?+SQL，從ECS到Spark其本質其實就是一種計算力的延伸

　　分層設計：下降複雜性，提供多模式的存儲模型

　　雲化：複用資源&彈性，下降成本

基本構架

　　首先包含了兩個分離

　　·分別是HDFS與分佈式Region\分佈式檢索分離

　　·SQL\時空\圖\時序\Cube與分佈式Region\檢索分離

　　大體的分層機構以下：

　　· 第一層：介質層，熱SSD介質、溫SSD&SATA 混合、冷純SATA(作EC)

　　· 第二層：分佈式文件系統，也就是盤古。事實上越是底層越容易作封裝優化。

　　· 第三層：分佈式安全隔離保障層QOS，若是咱們作存儲計算分離，就意味着底層的三個集羣須要布三套，這樣每一個集羣就會有幾十臺甚至幾百臺的節點，此時存儲力是由你們來均攤的，這就意味着分佈式安全隔離保障層要作好隔離性，引入QOS就意味着會增長延遲，此時會引入一些新的硬件(好比RDMA)去儘量的減少延遲。

　　· 第四層：分佈式?文件接?：HDFS & API(此層看狀況無關緊要)

　　· 第五層：咱們提供了兩個組件，分佈式Region-HBase與分佈式檢索-Solr，在研究分佈索引的時候發現單機索引是相對簡單的，咱們提供針對二級索引採起內置的分佈式Region的分佈式架構，針對全文索引採起外置Solr分佈式索引方案

　　· 第六層：建設在分佈式KV之上，有NewSQL套件、時空套件、時序套件、圖套件及Cube套件

　　另外，能夠引入spark來分析，這個也是社區目前通用的方案

解決成本的方案

　　對於解決成本的方案簡單介紹以下：

　　· 分級存儲：SSD與SATA的價格相差不少，在冷數據上，咱們建議直接採起冷存儲的方式 ，能夠節約500%的成本

　　· 高壓縮比：在分級存儲上有一個較好的壓縮，尤爲是在冷數據，咱們能夠提升壓縮比例，另外分佈式文件系統能夠採起EC進一步下降存儲成本，節約100%的成本

　　· 基礎設施共享：庫存壓力分擔，雲平臺能夠釋放紅利給客戶

　　· 存儲與計算分離：按需計費

　　· 優化性能：再把性能提高1倍左右

雲數據庫基本部署結構

　　假設在北京有三個機房可用區A、B和C,咱們會在可用區A中部署一個熱的存儲集羣，在北京總體區域部一個冷的存儲集羣，實際上有幾個可用區就能夠有幾個熱集羣，主要是保障延遲的;冷集羣對延遲相對不敏感，能夠地域單獨部署，只要交換機知足冷集羣所需的帶寬便可。這樣的好處是三個區共享一個冷集羣，就意味着能夠共享庫存。

ApsaraDB HBase產品能力

　　咱們提供兩個版本，一是單節點版，其特色是給開發測試用或者可用性不?，數據量不大的場景。二是集羣版本其特色是高至5000w QPS，多達10P存儲與高可靠低延遲等。

　　· 數據可靠性：99.99999999%：之因此可靠性能夠達到如此之高，其核心的緣由就是存儲集羣是單獨部署的，其會根據機架等進行副本放置優化

　　· 服務可用性：單集羣99.9% 雙集羣99.99%。

　　· 服務保障：服務未知足SLA賠付。

　　· 數據備份及恢復。

　　· 數據熱冷分離\分級存儲。

　　· 企業級安全：認證受權及加密。

　　· 提供檢索及二級索引及NewSQL能?。

　　· 提供時序/圖/時空/Cube相關能?。

　　· 與Spark無縫集成，提供AP能?。

數據備份及恢復

　　備份分爲全量備份HFile與 增量量備份HLog;恢復分爲HLog轉化爲HFile和BulkLoad加載。阿里雲集團迄今爲止已經有一萬兩千多臺的HBase,大部分都是主備集羣的，在雲上因爲客戶成本的緣由，大部分不選擇主備，因此須要對數據進行備份。其難點在於備份須要引入計算資源，咱們須要引入彈性的計算資源來處理備份的相關計算任務

Compaction 離線Compaction(研究中)

　　咱們在內部研究如何通FPGA對Compaction進行加速，這會使得集羣運行比較平緩，特別是對計算資源少，存儲量大的狀況下，能夠經過離線的做業處理Compaction。

　組件層

　　咱們有5中組件，NewSQL(Phoenix)、時序OpenTSDB、時空GeoMesa、圖JanusGraph及Cube的Kylin，及提供HTAP能力的Spark。這裏簡單描述幾個，以下：

　NewSQL - Phoenix

　　客戶仍是比較喜歡用SQL的,Phoenix會支持SQL及二級索引，在超過1T的數據量的狀況下，對事務的需求就不多(因此咱們並無支持事務);二級索引是經過再新建一張HBase表來實現的。在命中索引的狀況下，萬億級別的訪問基本在毫秒級別，但因爲Phoenix聚合點在一個節點，因此不能作Shuffle相似的事情，同時也就不能處理複雜的計算，因此任何說我是HTAP架構的，若是不能作Shuffle，就基本不能作複雜的計算。

HTAP – Spark

　　在HTAP-Spark這部分主要介紹一下RDD API、 SQL、直接訪問HFile的特色。

　　· RDD API具備簡單?便，默認支持的特色，但高併發scan大表會影響穩定性;

　　· SQL支持算?子下推、schema映射、各類參數調優，高併發scan大表會影響穩定性;

　　· 直接訪問HFile，直接訪問存儲不通過計算，大批量量訪問性能最好，須要snapshot對齊數據。

　時序 – OpenTSDB & HiTSDB

　　TSD沒有狀態，能夠動態加減節點，並按照時序數據的特色設計表結構，其內置針對浮點的高壓縮比的算法，咱們雲上專業版的HiTSDB增長倒排等能?，並可以針對時序增長插值、降精度等優化。

大數據數據庫的實際案例

　　如下簡單介紹幾個客戶的案例，目前已經在雲上ApsaraDB HBase運行，數據量基本在10T以上：

某車聯網公司

　　這是一個車聯網的客戶，有100萬車，每輛車每10秒上傳一次，每次1KB，這樣一年就有300T數據，六個月以上是數據低頻訪問，因此他要作分級存儲，把冷數據放到低介質上

某大數據控公司

　　這是一個大數據控公司，它大約有200T+的數據量，將HBase數據 (在線實時大數據存儲)做爲主數據庫，先用HBase作算法訓練，再用HBase SQL出報表，另外作了一套ECS進行實時查以便與客戶之間進行數據交換。

某社交公司

　　社交會有大量的推薦，因此SLA要求高達99.99，並採用雙集羣保障，單集羣讀寫高峯QPS 能夠達到1000w+，數據量在30T左右。

　某基金公司

　　這是一個金融公司，它有10000億以上的交易數據，目前用多個二級索引支持毫秒級別的查詢，數據量在100T左右

某公司報表系統

　　先離線建好Cube再把數據同步到HBase中，實時數據經過Blink對接進行更新，數據量在可達20T左右