大數(shù)據(jù)時代數(shù)據(jù)庫-云HBase架構(gòu)&生態(tài)&實踐

摘要：2018第九屆中國數(shù)據(jù)庫技術(shù)大會，阿里云高級技術(shù)專家、架構(gòu)師封神(曹龍)帶來題為大數(shù)據(jù)時代數(shù)據(jù)庫-云HBase架構(gòu)&生態(tài)&實踐的演講。主要內(nèi)容有三個方面：首先介紹了業(yè)務挑戰(zhàn)帶來的架構(gòu)演進，其次分析了ApsaraDB HBase及生態(tài)，最后分享了大數(shù)據(jù)數(shù)據(jù)庫的實際案例。

滎經(jīng)網(wǎng)站制作公司哪家好，找成都創(chuàng)新互聯(lián)公司！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、響應式網(wǎng)站建設等網(wǎng)站項目制作，到程序開發(fā)，運營維護。成都創(chuàng)新互聯(lián)公司從2013年創(chuàng)立到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選成都創(chuàng)新互聯(lián)公司。

講師介紹：

封神，真名曹龍，09年加入阿里，現(xiàn)任阿里云高級技術(shù)專家、架構(gòu)師，專注于大數(shù)據(jù)分布式計算、數(shù)據(jù)庫、存儲領域，先后研發(fā)上萬臺Hadoop、ODPS集群，負責阿里YARN、Spark及自主研發(fā)內(nèi)存計算引擎，目前為廣大公共云用戶提供專業(yè)的云HBase數(shù)據(jù)庫及計算服務。

　　正文演講：

　業(yè)務的挑戰(zhàn)

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

現(xiàn)如今大量的中小型公司并沒有大規(guī)模的數(shù)據(jù)，如果一家公司的數(shù)據(jù)量超過100T，且能通過數(shù)據(jù)產(chǎn)生新的價值，基本可以說是大數(shù)據(jù)公司了 。起初，一個創(chuàng)業(yè)公司的基本思路就是首先架構(gòu)一個或者幾個ECS，后面加入MySQL,如果有圖片需求還可加入磁盤，該架構(gòu)的基本能力包括事務、存儲、索引和計算力。隨著公司的慢慢發(fā)展，數(shù)據(jù)量在不斷地增大，其通過MySQL及磁盤基本無法滿足需求，只有分布式化。 這個時候MySQL變成了HBase,檢索變成了Solr/ES，再ECS提供的計算力變成了Spark。但這也會面臨存儲量大且存儲成本高等問題。

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

另外一個趨勢就是非結(jié)構(gòu)化的數(shù)據(jù)越來越多，數(shù)據(jù)結(jié)構(gòu)的模式不僅僅是SQL，時序、時空、graph模式也越來越多，需要一些新的存儲結(jié)構(gòu)或新的算法去解決這類問題，也意味著所需要做的工程量就會相對較高。

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

對于數(shù)據(jù)處理大致可歸類為四個方面，分別是復雜性、靈活性、延遲<讀,寫>和分布式，其中分布式肯定是不可少的，一旦缺少分布式就無法解決大規(guī)模問題 。靈活性的意思是業(yè)務可以任意改變的;復雜性就是運行一條SQL能夠訪問多少數(shù)據(jù)或者說SQL是否復雜;延遲也可分為讀與寫的延遲。Hadoop & Spark可以解決計算復雜性和靈活性，但是解決不了延遲的問題;HBase&分布式索引、分布式數(shù)據(jù)庫可以解決靈活性與延遲的問題，但由于它沒有很多計算節(jié)點，所以解決不了計算復雜性的問題。Kylin(滿足讀延遲)在計算復雜性與延遲之間找了一個平衡點，這個平衡點就是怎樣快速出報表，但對于這個結(jié)果的輸入時間我們并不關(guān)心，對于大部分的報表類的需求就是這樣的。每個引擎都有一定的側(cè)重，沒有銀彈!

ApsaraDB HBase產(chǎn)品架構(gòu)及改進

　　應對的辦法

我們也不能解決所有的問題，我們只是解決其中大部分的問題。如何找到一個在工程上能夠解決大部分問題的方案至關(guān)重要，應對辦法：

分布式：提供擴展性

計算力延伸：算子+SQL，從ECS到Spark其本質(zhì)其實就是一種計算力的延伸

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

云化：復用資源&彈性，降低成本

基本構(gòu)架

首先包含了兩個分離

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

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

大致的分層機構(gòu)如下：

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

· 第二層：分布式文件系統(tǒng)，也就是盤古。事實上越是底層越容易做封裝優(yōu)化。

· 第三層：分布式安全隔離保障層QOS，如果我們做存儲計算分離，就意味著底層的三個集群需要布三套，這樣每個集群就會有幾十臺甚至幾百臺的節(jié)點，此時存儲力是由大家來均攤的，這就意味著分布式安全隔離保障層要做好隔離性，引入QOS就意味著會增加延遲，此時會引入一些新的硬件(比如RDMA)去盡可能的減小延遲。

· 第四層：分布式?文件接?：HDFS & API(此層看情況可有可無)

· 第五層：我們提供了兩個組件，分布式Region-HBase與分布式檢索-Solr，在研究分布索引的時候發(fā)現(xiàn)單機索引是相對簡單的，我們提供針對二級索引采取內(nèi)置的分布式Region的分布式架構(gòu)，針對全文索引采取外置Solr分布式索引方案

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

另外，可以引入spark來分析，這個也是社區(qū)目前通用的方案

解決成本的方案

對于解決成本的方案簡單介紹如下：

· 分級存儲：SSD與SATA的價格相差很多，在冷數(shù)據(jù)上，我們建議直接采取冷存儲的方式 ，可以節(jié)約500%的成本

· 高壓縮比：在分級存儲上有一個較好的壓縮，尤其是在冷數(shù)據(jù)，我們可以提高壓縮比例，另外分布式文件系統(tǒng)可以采取EC進一步降低存儲成本，節(jié)約100%的成本

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

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

· 優(yōu)化性能：再把性能提升1倍左右

云數(shù)據(jù)庫基本部署結(jié)構(gòu)

假設在北京有三個機房可用區(qū)A、B和C,我們會在可用區(qū)A中部署一個熱的存儲集群，在北京整體區(qū)域部一個冷的存儲集群，實際上有幾個可用區(qū)就可以有幾個熱集群，主要是保障延遲的;冷集群對延遲相對不敏感，可以地域單獨部署，只要交換機滿足冷集群所需的帶寬即可。這樣的好處是三個區(qū)共享一個冷集群，就意味著可以共享庫存。

ApsaraDB HBase產(chǎn)品能力

我們提供兩個版本，一是單節(jié)點版，其特點是給開發(fā)測試用或者可用性不?，數(shù)據(jù)量不大的場景。二是集群版本其特點是高至5000w QPS，多達10P存儲與高可靠低延遲等。

· 數(shù)據(jù)可靠性：99.99999999%：之所以可靠性可以達到如此之高，其核心的原因就是存儲集群是單獨部署的，其會根據(jù)機架等進行副本放置優(yōu)化

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

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

· 數(shù)據(jù)備份及恢復。

· 數(shù)據(jù)熱冷分離\分級存儲。

· 企業(yè)級安全：認證授權(quán)及加密。

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

· 提供時序/圖/時空/Cube相關(guān)能?。

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

數(shù)據(jù)備份及恢復

備份分為全量備份HFile與 增量量備份HLog;恢復分為HLog轉(zhuǎn)化為HFile和BulkLoad加載。阿里云集團迄今為止已經(jīng)有一萬兩千多臺的HBase,大部分都是主備集群的，在云上由于客戶成本的原因，大部分不選擇主備，所以需要對數(shù)據(jù)進行備份。其難點在于備份需要引入計算資源，我們需要引入彈性的計算資源來處理備份的相關(guān)計算任務

Compaction 離線Compaction(研究中)

我們在內(nèi)部研究如何通FPGA對Compaction進行加速，這會使得集群運行比較平緩，特別是對計算資源少，存儲量大的情況下，可以通過離線的作業(yè)處理Compaction。

　組件層

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

　NewSQL - Phoenix

客戶還是比較喜歡用SQL的,Phoenix會支持SQL及二級索引，在超過1T的數(shù)據(jù)量的情況下，對事務的需求就很少(所以我們并沒有支持事務);二級索引是通過再新建一張HBase表來實現(xiàn)的。在命中索引的情況下，萬億級別的訪問基本在毫秒級別，但由于Phoenix聚合點在一個節(jié)點，所以不能做Shuffle類似的事情，同時也就不能處理復雜的計算，所以任何說我是HTAP架構(gòu)的，如果不能做Shuffle，就基本不能做復雜的計算。

HTAP – Spark

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

· RDD API具有簡單?便，默認支持的特點，但高并發(fā)scan大表會影響穩(wěn)定性;

· SQL支持算?子下推、schema映射、各種參數(shù)調(diào)優(yōu)，高并發(fā)scan大表會影響穩(wěn)定性;

· 直接訪問HFile，直接訪問存儲不經(jīng)過計算，大批量量訪問性能最好，需要snapshot對齊數(shù)據(jù)。

　時序 – OpenTSDB & HiTSDB

TSD沒有狀態(tài)，可以動態(tài)加減節(jié)點，并按照時序數(shù)據(jù)的特點設計表結(jié)構(gòu)，其內(nèi)置針對浮點的高壓縮比的算法，我們云上專業(yè)版的HiTSDB增加倒排等能?，并能夠針對時序增加插值、降精度等優(yōu)化。

大數(shù)據(jù)數(shù)據(jù)庫的實際案例

以下簡單介紹幾個客戶的案例，目前已經(jīng)在云上ApsaraDB HBase運行，數(shù)據(jù)量基本在10T以上：

某車聯(lián)網(wǎng)公司

這是一個車聯(lián)網(wǎng)的客戶，有100萬車，每輛車每10秒上傳一次，每次1KB，這樣一年就有300T數(shù)據(jù)，六個月以上是數(shù)據(jù)低頻訪問，所以他要做分級存儲，把冷數(shù)據(jù)放到低介質(zhì)上

某大數(shù)據(jù)控公司

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

某社交公司

社交會有大量的推薦，所以SLA要求高達99.99，并采用雙集群保障，單集群讀寫高峰QPS 可以達到1000w+，數(shù)據(jù)量在30T左右。

　某基金公司

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

某公司報表系統(tǒng)

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

網(wǎng)頁題目：大數(shù)據(jù)時代數(shù)據(jù)庫-云HBase架構(gòu)&生態(tài)&實踐
轉(zhuǎn)載源于：http://bm7419.com/article2/psssoc.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁設計公司、手機網(wǎng)站建設、網(wǎng)站排名、做網(wǎng)站、Google、品牌網(wǎng)站建設

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)