摘要: 2018第九屆中國數據庫技術大會,阿里雲高級技術專家、架構師封神(曹龍)帶來題爲大數據時代數據庫-雲HBase架構&生態&實踐的演講。主要內容有三個方面:首先介紹了業務挑戰帶來的架構演進,其次分析了ApsaraDB HBase及生態,最後分享了大數據數據庫的實際案例。算法
2018第九屆中國數據庫技術大會,阿里雲高級技術專家、架構師封神(曹龍)帶來題爲大數據時代數據庫-雲HBase架構&生態&實踐的演講。主要內容有三個方面:首先介紹了業務挑戰帶來的架構演進,其次分析了ApsaraDB HBase及生態,最後分享了大數據數據庫的實際案例。
直播視頻回顧
PPT下載請點擊
如下是精彩視頻內容整理:數據庫
現現在大量的中小型公司並無大規模的數據,若是一家公司的數據量超過100T,且能經過數據產生新的價值,基本能夠說是大數據公司了 。起初,一個創業公司的基本思路就是首先架構一個或者幾個ECS,後面加入MySQL,若是有圖片需求還可加入磁盤,該架構的基本能力包括事務、存儲、索引和計算力。隨着公司的慢慢發展,數據量在不斷地增大,其經過MySQL及磁盤基本沒法知足需求,只有分佈式化。 這個時候MySQL變成了HBase,檢索變成了Solr/ES,再ECS提供的計算力變成了Spark。但這也會面臨存儲量大且存儲成本高等問題。安全
另一個趨勢就是非結構化的數據愈來愈多,數據結構的模式不只僅是SQL,時序、時空、graph模式也愈來愈多,須要一些新的存儲結構或新的算法去解決這類問題,也意味着所須要作的工程量就會相對較高。數據結構
對於數據處理大體可歸類爲四個方面,分別是複雜性、靈活性、延遲<讀,寫>和分佈式,其中分佈式確定是不可少的,一旦缺乏分佈式就沒法解決大規模問題 。靈活性的意思是業務能夠任意改變的;複雜性就是運行一條SQL可以訪問多少數據或者說SQL是否複雜;延遲也可分爲讀與寫的延遲。Hadoop & Spark能夠解決計算複雜性和靈活性,可是解決不了延遲的問題;HBase&分佈式索引、分佈式數據庫能夠解決靈活性與延遲的問題,但因爲它沒有不少計算節點,因此解決不了計算複雜性的問題。Kylin(知足讀延遲)在計算複雜性與延遲之間找了一個平衡點,這個平衡點就是怎樣快速出報表,但對於這個結果的輸入時間咱們並不關心,對於大部分的報表類的需求就是這樣的。每一個引擎都是必定的側重,沒有銀彈!架構
咱們也不能解決全部的問題,咱們只是解決其中大部分的問題。如何找到一個在工程上可以解決大部分問題的方案相當重要,應對辦法:併發
首先包含了兩個分離分佈式
對於解決成本的方案簡單介紹以下:高併發
假設在北京有三個機房可用區A、B和C,咱們會在可用區A中部署一個熱的存儲集羣,在北京總體區域部一個冷的存儲集羣,實際上有幾個可用區就能夠有幾個熱集羣,主要是保障延遲的;冷集羣對延遲相對不敏感,能夠地域單獨部署,只要交換機知足冷集羣所需的帶寬便可。這樣的好處是三個區共享一個冷集羣,就意味着能夠共享庫存。oop
咱們提供兩個版本,一是單節點版,其特色是給開發測試用或者可用性不高,數據量不大的場景。二是集羣版本其特色是高至5000w QPS,多達10P存儲與高可靠低延遲等。性能
備份分爲全量備份HFile與 增量量備份HLog;恢復分爲HLog轉化爲HFile和BulkLoad加載。阿里雲集團迄今爲止已經有一萬兩千多臺的HBase,大部分都是主備集羣的,在雲上因爲客戶成本的緣由,大部分不選擇主備,因此須要對數據進行備份。其難點在於備份須要引入計算資源,咱們須要引入彈性的計算資源來處理備份的相關計算任務
咱們在內部研究如何通FPGA對Compaction進行加速,這會使得集羣運行比較平緩,特別是對計算資源少,存儲量大的狀況下,能夠經過離線的做業處理Compaction。
咱們有5中組件,NewSQL(Phoenix)、時序OpenTSDB、時空GeoMesa、圖JanusGraph及Cube的Kylin,及提供HTAP能力的Spark。這裏簡單描述幾個,以下:
客戶仍是比較喜歡用SQL的,Phoenix會支持SQL及二級索引,在超過1T的數據量的狀況下,對事務的需求就不多(因此咱們並無支持事務);二級索引是經過再新建一張HBase表來實現的。在命中索引的狀況下,萬億級別的訪問基本在毫秒級別,但因爲Phoenix聚合點在一個節點,因此不能作Shuffle相似的事情,同時也就不能處理複雜的計算,因此任何說我是HTAP架構的,若是不能作Shuffle,就基本不能作複雜的計算。
在HTAP-Spark這部分主要介紹一下RDD API、 SQL、直接訪問HFile,它們的特色以下:
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左右。