《唯品會海量實時OLAP分析技術(shù)升級之路》要點：
本文介紹了唯品會海量實時OLAP分析技術(shù)升級之路，希望對您有用。如果有疑問，可以聯(lián)系我們。

本文根據(jù)謝麟炯老師在〖DAMS 2017中國數(shù)據(jù)資產(chǎn)管理峰會〗現(xiàn)場演講內(nèi)容整理而成.

講師介紹

謝麟炯,唯品會大數(shù)據(jù)平臺高級技術(shù)架構(gòu)經(jīng)理,主要負責(zé)大數(shù)據(jù)自助多維分析平臺,離線數(shù)據(jù)開發(fā)平臺及分析引擎團隊的開發(fā)和管理工作,加入唯品會以來還曾負責(zé)流量基礎(chǔ)數(shù)據(jù)的采集和數(shù)據(jù)倉庫建設(shè)以及移動流量分析等數(shù)據(jù)產(chǎn)品的工作.

分享大綱：

1. 海量數(shù)據(jù)實時OLAP場景的困境
2. 唯品會大數(shù)據(jù)實時OLAP升級過程
3. 唯品會在開源計算引擎上所做的改進
4. OLAP方案升級方向

1.海量數(shù)據(jù)實時OLAP場景的困境

大數(shù)據(jù)

首先來看一下我們在最初幾年遇到的問題.第一就是大數(shù)據(jù),聽起來好像蠻無聊的,但大數(shù)據(jù)到底是指什么呢?最主要的問題就是數(shù)據(jù)大,唯品會在這幾年快速發(fā)展,用戶流量數(shù)據(jù)從剛開始的幾百萬、幾千萬發(fā)展到現(xiàn)在的幾個億,呈現(xiàn)了100倍以上的增長.

對我們而言,所謂的大數(shù)據(jù)就是數(shù)據(jù)量的快速膨脹,帶來的問題最主要的就是傳統(tǒng)RDBMS無法滿足存儲的需求,繼而是計算的需求,我們的挑戰(zhàn)便是如何克服這個問題.

慢查詢

第二個問題是慢查詢,有兩個方面：一是OLAP查詢的速度變慢；二是ETL數(shù)據(jù)處理效率降低.

分析下這兩個問題：首先,用戶使用OLAP分析系統(tǒng)時會有這樣的預(yù)期,當(dāng)我點擊查詢按鈕時希望所有的數(shù)據(jù)能夠秒出,而不是我抽身去泡個茶,回來一看數(shù)據(jù)才跑了10%,這是無法接受的.由于數(shù)據(jù)量大,我們也可以選擇預(yù)先計算好,當(dāng)用戶查詢時直接從計算結(jié)果中找到對應(yīng)的值返回,那么查詢就是秒出的.數(shù)據(jù)量大對預(yù)計算而言也有同樣的問題,就是ETL的性能也下降了,本來準(zhǔn)備這個數(shù)據(jù)可能只需40分鐘或一個小時,現(xiàn)在數(shù)據(jù)量翻了一百倍,需要三個小時,這時候數(shù)據(jù)分析師上班時就會抱怨數(shù)據(jù)沒有準(zhǔn)備好,得等到中午分析之類的,會聽到來自同事不斷的抱怨.

長迭代

數(shù)據(jù)量變大帶來的第三個毛病,就是開發(fā)周期變長.兩個角度：第一,新業(yè)務(wù)上線,用戶會說我能不能在這個新的角度上線前,看看歷史數(shù)據(jù),要看一年的,這時就要刷數(shù)據(jù)了.刷數(shù)據(jù)這件事情大家知道,每次刷頭都很大,花的時間很長.舊業(yè)務(wù)也一樣,加新的指標(biāo),沒有歷史趨勢也不行,也要刷數(shù)據(jù),開發(fā)就不斷地刷數(shù)據(jù).因為數(shù)據(jù)量大,刷數(shù)據(jù)的時間非常長,數(shù)據(jù)驗證也需要花很多的時間,慢慢的,開發(fā)周期變慢,業(yè)務(wù)很急躁,覺得不就是加個字段嗎,怎么這么慢.這樣一來,數(shù)據(jù)的迭代長,周期變慢,都讓業(yè)務(wù)部門對大數(shù)據(jù)業(yè)務(wù)提出很多的質(zhì)疑,我們需要改進來解決這些問題.

業(yè)務(wù)部門的想法是,不管你是什么業(yè)務(wù),不管現(xiàn)在用的是什么方法,他們只關(guān)心三點：第一,提的需求要很快滿足；第二,數(shù)據(jù)要很快準(zhǔn)備好；第三,數(shù)據(jù)準(zhǔn)備好之后,當(dāng)我來做分析時數(shù)據(jù)能夠很快地返回.業(yè)務(wù)要的是快快快,但現(xiàn)在的能力是慢慢慢,為此,我們急需解決業(yè)務(wù)部門的需求和現(xiàn)狀之間的沖突.

2.唯品會大數(shù)據(jù)實時OLAP升級過程

第0階段

 

這是我們的初始狀態(tài),架構(gòu)比較簡單.底層的計算、存儲和OLAP分析用MDB的數(shù)據(jù)倉庫解決的,上層用Tableau的BI工具,開發(fā)速度比較快,同時有數(shù)據(jù)可視化效果,業(yè)務(wù)部分非常認可.GreenPlum是MPP的方案,它的高并發(fā)查詢非常適合我們這種OLAP的查詢,性能非常好.所以我們在這個階段,把GreenPlum作為數(shù)據(jù)倉庫和OLAP混用的實現(xiàn).

這樣一個架構(gòu)其實是一個通用的架構(gòu),像Tableau可以輕易被替換, GreenPlum也可以替換成Oracle之類的,這樣一個常用的工具、一個架構(gòu),其實滿足了部分的需求,但也有個問題,就是像GreenPlum這樣的RDBMS數(shù)據(jù)庫,在面對海量的數(shù)據(jù)寫入時存儲和計算的資源快速地枯竭了, GreenPlum的水平擴展有限,所以同樣碰到了大數(shù)據(jù)的問題.

第1階段

所以很快我們就進入了第一階段.這個階段,我們引入了Hadoop/Hive,所有的計算結(jié)果做預(yù)計算之后,會同步到GreenPlum里面,接下去一樣,用GreenPlum去做分析.OLAP講聚合講的Ad-hoc,繼續(xù)由GreenPlum承載,數(shù)據(jù)倉庫講明細數(shù)據(jù)講Batch,就交給專為批量而生的Hive來做,這樣就能把OLAP和數(shù)據(jù)倉庫這兩個場景用兩個不一樣技術(shù)棧分開.這樣一個技術(shù)方案解決了數(shù)據(jù)量大的問題,ETL批量就不會說跑不動或者數(shù)據(jù)沒法存儲.

但問題是增加了新的同步機制,需要在兩個不同的DB之間同步數(shù)據(jù).同步數(shù)據(jù)最顯而易見的問題就是除了數(shù)據(jù)冗余外,如果數(shù)據(jù)不同步怎么辦?比如ETL開發(fā)在Hadoop上更新,但沒有同步到GreenPlum上,用戶會發(fā)現(xiàn)數(shù)據(jù)還是錯誤的.第二,對用戶來說,當(dāng)他去做OLAP分析時,Tabluea是更適合做報表的工具,隨著我們業(yè)務(wù)的擴展和數(shù)據(jù)驅(qū)動不斷的深入,業(yè)務(wù)不管分析師還是商務(wù)、運營、市場,他們會越來越多地想組合不同的指標(biāo)和維度去觀察自己的數(shù)據(jù),找自己運營的分析點.傳統(tǒng)的Tabluea報表已經(jīng)不能滿足他們.

我們需要一個新的BI解決方案

對我們來說數(shù)據(jù)不同步還可以解決,畢竟是偶然發(fā)生的,處理一下就可以了.但是BI工具有很大的問題,不能滿足業(yè)務(wù)已經(jīng)進化的需求.所以我們需要一個新的BI解決方案：

1. 首先它要足夠靈活,不能發(fā)布之后用戶什么都不能做,只能看,我們希望它的維度和指標(biāo)可以快速整合.
2. 第二,門檻要低,我們不可能希望業(yè)務(wù)像BI工程師學(xué)習(xí)它的開發(fā)是怎么做的,所以它要入門非常簡單.其次,要能夠用語言描述自己的需求,而不是用SQL,讓商務(wù)這種感性思維的人學(xué)SQL簡直是不可能的,所以要能用語言描述他們自己想要什么.
3. 第三就是開發(fā)周期短,業(yè)務(wù)想看什么,所有的數(shù)據(jù)都需要提需求,需求分析,排期實施,提變更又要排期實施,這時候雖然說業(yè)務(wù)發(fā)展不是一天一變,但很多業(yè)務(wù)試錯的時間非常快,數(shù)據(jù)開發(fā)出來黃花菜都涼了.所以希望有一個新的BI方案解決這三個問題.

我們看了一下市面上的商業(yè)工具并不適合,并且這樣靈活的方案需要我們有更強的掌控性,于是我們就開始走向了自研的道路.

第2階段

我們進入了OLAP分析的第二個階段,這時前端開發(fā)了一個產(chǎn)品叫自助分析平臺,這個平臺上用戶可以通過拖拉拽把左邊的維度指標(biāo)自己組合拖到上面,組成自己想看的結(jié)果.結(jié)果查詢出來后可以用表格也可以圖形進行展示,包括折線、柱狀、條形圖,這里面所有的分析結(jié)果都是可保存、可分享、可下載的.

利用這樣的工具可以幫助分析師或者業(yè)務(wù)人員更好地自由的組合剛才我們所說的一切,并且靈活性、門檻低的問題其實也都迎刃而解了.而且像這樣拖拉拽是非常容易學(xué)習(xí)的,只要去學(xué)習(xí)怎么把業(yè)務(wù)邏輯轉(zhuǎn)化成一個數(shù)據(jù)的邏輯描述,搞懂要怎么轉(zhuǎn)化成什么形式,行里面顯示什么,列顯示什么,度量是什么就可以了,雖然有一點的學(xué)習(xí)曲線,但比起學(xué)習(xí)完整的BI工具,門檻降低了很多.

前端是這樣的產(chǎn)品,后端也要跟著它一起變.首先前端是一個拖拉拽的UI組件,這個組件意味著用傳統(tǒng)的選擇SQL,直接形成報表的方式已經(jīng)不可行了,因為所有的一切不管是維度指標(biāo)都是用戶自己組合的,所以我們需要一個SQL Parser幫助用戶把它的數(shù)據(jù)的描述轉(zhuǎn)化成SQL,還要進行性能的調(diào)優(yōu),保證以一個比較高的性能反饋數(shù)據(jù).

所以我們就開發(fā)了一個SQL Parser用來承接組件生成的數(shù)據(jù)結(jié)構(gòu),同時用SQL Parser直接去OLAP數(shù)據(jù).還是通過預(yù)計算的方式,把我們需要的指標(biāo)維度算好同步到SQL Parser.這樣的模型一旦建立,可以多次復(fù)用.

但我們知道這個計算方案有幾個明顯的缺點：第一,所有的數(shù)據(jù)必須經(jīng)過計算,計算范圍之外的不能組合；第二,還是有數(shù)據(jù)同步的問題,第三是什么?其實預(yù)計算的時候大家會經(jīng)常發(fā)現(xiàn)我們認為這些組合是有效的,用戶可能不會查,但不去查這次計算就浪費掉了.是不是有更好的辦法去解決這種現(xiàn)狀?

我們需要一個新的OLAP計算引擎

從這個角度來看GreenPlum已經(jīng)不能滿足我們了,就算預(yù)先計算好也不能滿足,需要一個新的OLAP計算引擎.這個新的引擎需要滿足三個條件：

1. 沒有預(yù)計算的模型.因為預(yù)計算的缺點是沒有傳統(tǒng)意義上的數(shù)據(jù)匯總層,直接從DW層明細數(shù)據(jù)上的直接計算.而且我們所有的業(yè)務(wù)場景化,只要DW層有這個數(shù)據(jù)就不用再開發(fā)了,直接拿來用就可以了.之前我們講到數(shù)據(jù)先匯總,有些緩慢變化是需要刷數(shù)據(jù)的,這個頭很疼,也要解決.
2. 速度要足夠快.數(shù)據(jù)平均10秒返回,看上去挺慢的,不是秒出,為什么當(dāng)時定這樣的目標(biāo)?因為剛才講到之前的開發(fā)方式業(yè)務(wù)要排期等,這個周期非常長,如果現(xiàn)在通過一個可以隨意組合的方式去滿足它90%以上的需求,其實它在真正做的時候?qū)π阅艿囊蟛]有那么嚴苛.我們也不希望這邊查詢的時候因為等待數(shù)據(jù)把自己分析的思路或者日程打亂了,10秒可能是比較合適的.然后,因為我們的數(shù)據(jù)倉庫DW層用維度建模,所以這個OLAP引擎必須支持Join.
3. 最后是支持橫向擴展,計算能力可通過計算節(jié)點擴容獲得提高,同時沒有DB同步的問題.這里面東西還是挺多的,怎么解決這個問題呢?我們把需求分解了一下.

首先查詢速度要快,我們需要一個SQL內(nèi)在的高并發(fā).其次用純內(nèi)存計算代替內(nèi)存+硬盤的計算,內(nèi)存+硬盤的計算講的就是Hive,Hive一個SQL啟動一下,包括實際計算過程都是很慢的.第二個是數(shù)據(jù)模型,剛才講到數(shù)據(jù)倉庫才是維度建模的,必須支持Join,像外面比較流行的Druid或者ES的方案其實不適用了.第三個就是數(shù)據(jù)不需要同步,意味著需要數(shù)據(jù)存在HDFS上,計算引擎要能夠感知到Hive的Metadata.第四個是通過擴容提高計算能力,如果想做到完全沒有服務(wù)降級的擴容,一個計算引擎沒有狀態(tài)是最好的,同時計算的節(jié)點互相無依賴.最后一點是方案成熟穩(wěn)定,因為這是在嘗試新的OLAP方案,如果這個OLAP方案不穩(wěn)定,直接影響到了用戶體驗,我們希望線上出問題時我們不至于手忙腳亂到?jīng)]辦法快速解決.

Presto：Facebook貢獻的開源MPP OLAP引擎

這時候Presto進入我們的視野,它是Facebook貢獻的開源MPP OLAP引擎.這是一個紅酒的名字,因為開發(fā)組所有的人都喜歡喝這個牌子的紅酒,所以把它命名為這個名字.作為MPP引擎,它的處理方式是把所有的數(shù)據(jù)Scan出來,通過Hash的方法把數(shù)據(jù)變成更小的塊,讓不同的節(jié)點并發(fā),處理完結(jié)果后快速地返回給用戶.我們看到它的邏輯架構(gòu)也是這樣,發(fā)起一個SQL,然后找這些數(shù)據(jù)在哪些HDFS節(jié)點上,然后分配后做具體的處理,最后再把數(shù)據(jù)返回.

為什么是Presto

從原理上來看,高并發(fā)查詢因為是MPP引擎的支持.純內(nèi)存計算,它是純內(nèi)存的,跟硬盤沒有任何交互.第三,因為它是一個SQL引擎,所以支持Join.另外數(shù)據(jù)沒有存儲,數(shù)據(jù)直接存儲在HDFS上.計算引擎沒有狀態(tài),計算節(jié)點互相無依賴都是滿足的.另外它也是一個成熟方案,Facebook本身也是大廠,國外有谷歌在用,國內(nèi)京東也有自己的版本,所以這個東西其實還是滿足我們需求的.

Presto性能測試

我們在用之前做了POC.我們做了一個嘗試,把在我們平臺上常用的SQL(不用TPCH的原因是我們平臺的SQL更適合我們的場景),在GP和Presto兩個計算引擎上,用相同的機器配置和節(jié)點數(shù)同時做了一次基準(zhǔn)性能測試,可以看到結(jié)果是非常令人歡喜的.

整體而言相同節(jié)點的Presto比GreenPlum的性能提升70%,而且SQL9到SQL16都從100多秒下降到10秒,可見它的提升是非常明顯的.

當(dāng)我們做完性能測試時,我們一個專門做引擎開發(fā)的同學(xué)叫了起來,說就你了,用Presto替代GreenPlum.

第3階段

在Presto引進來之后,我們發(fā)現(xiàn)整個數(shù)據(jù)架構(gòu)變得非常順暢,上層用拖拉拽的UI組件生成傳給SQL到Parser,然后傳給Presto執(zhí)行.不管是流量數(shù)據(jù),還是埋點,還是曝光數(shù)據(jù)返回非常快,同時我們也把場景擴展到包括訂單、銷售之類的事務(wù)型分析上.用了之后中位數(shù)返回時間5秒鐘,平均返回時間15秒,基本上這段時間可以返回所有的OLAP查詢.因為用了DW數(shù)據(jù),維度更豐富,大多數(shù)的需求問題被解決.

用了Presto之后用戶的第一反應(yīng)是為什么會這么快,到底用了什么黑科技.但是運行了一段時間后我們觀察了用戶的行為是什么樣的,到底在查詢什么樣的SQL,什么維度和指標(biāo)的組合,希望還能再做一些優(yōu)化.

最快的計算方法是不計算

在這個時候我們突然發(fā)現(xiàn),即使是用戶自由組合的指標(biāo)也會發(fā)現(xiàn)不同業(yè)務(wù)在相同業(yè)務(wù)場景下會去查完全相同的數(shù)據(jù)組合.比如很多用戶會查同一渠道的銷售流量轉(zhuǎn)化,現(xiàn)在的方案會有什么問題呢?完全相同的查詢也需要到上面真正執(zhí)行一遍,實際上如果完全相同的可以直接返回結(jié)果不用計算了.所以我們就在想怎么解決這個問題?實際這里有一個所謂的理論——就是最快的計算就是不計算,怎么做呢?如果我們能夠模仿Oracle的BGA,把計算結(jié)果存儲下來,用戶查詢相同時可以把數(shù)據(jù)取出來給用戶直接返回就好了.

于是這里就講到了緩存復(fù)用.第一個階段完全相同的直接返回,第二個階段更進一步,相對來說更復(fù)雜一些,如果說提出一個新的SQL,結(jié)果是上一個的,我們也不結(jié)算,從上一個結(jié)果里面直接做二次處理,把緩存的數(shù)據(jù)拿出來反饋給用戶.除了這個亮點之外,其實緩存很重要的就是生命周期管理,非常復(fù)雜,因為數(shù)據(jù)不斷地更新,緩存如果不更新可能查出來的數(shù)據(jù)不對,在數(shù)據(jù)庫會說這是臟讀或者幻影讀,我們希望緩存的生命周期可以自己管理,不希望是通過超時來管理緩存,我們更希望緩存可以管理自己的生命周期,跟源數(shù)據(jù)同步生命周期,這樣緩存使用效率會是最好的.

Redis：成熟的緩存方案

說到緩存要提到Redis,這是很多生產(chǎn)系統(tǒng)上大量使用的,它也非常適合OLAP.

首先我們想要的是SQL跟結(jié)果一對一匹配,它是非常符合這個需求的.其次我們希望緩存更快的返回,Redis是純內(nèi)存的存儲,返回速度非常快,一般是毫秒級.第三個生命周期管理,它提供API,我們做二次開發(fā),跟我們ETL調(diào)度系統(tǒng)打通,處理更新時就可以通知什么樣的數(shù)據(jù)可以被用到.而緩存復(fù)用是不支持的,我們可以自己來做.

第3.5階段

于是這時就把Redis的方案引入進來.

引入Redis之后帶來一個新的挑戰(zhàn),我們不是只有一個計算引擎,我們暫時先把Redis稱為一個計算引擎,因為數(shù)據(jù)可能在Redis,也可能需要通過Presto去把數(shù)據(jù)讀出來,這時我們在剛才生成SQL之后還加入了新的一個組件,Query Engine的目的就是在不同的引擎之間做路由,找到最快返回數(shù)據(jù)的匹配.比如說我們一個SQL發(fā)下來,它會先去找Redis,看在Redis找有沒有這個SQL緩存的記錄,有就直接返回給用戶,沒有再到Presto上面查詢.上線了之后,我們觀察了結(jié)果,結(jié)果也是非常不錯的,發(fā)現(xiàn)平均的緩存命中率達到15%,意味著這15%的查詢都是秒出.

因為我們有不同的主題,流量主題、銷售、收藏、客戶,類似不同的主題,用戶查詢的組合不一樣,特殊的場景下,命中率達到60%,這樣除去緩存的返回速度非常快之外,緩存也有好處,就是釋放了Presto的計算能力,原先需要跑一次的查詢便不需要了.釋放出來的內(nèi)存和CPU就可以給其它的查詢提供計算能力了.

空間換時間：OLAP分析的另一條途徑

緩存的方案實施之后,看上去很不錯了,這時候我們又引起了另一次思考,緩存現(xiàn)在是在做第二次查詢的提速,但我們想讓第一次的速度也可以更快一些.說到第一次的查詢,我們要走回老路了,我們說空間換時間,是提升第一次查詢一個最顯而易見的辦法.

空間換時間,如果說OLAP ad-hoc查詢從事先計算好的結(jié)果里查詢,那是不是返回速度也會很快?其次,空間換時間要支持維度建模,它也要支持Join.最后希望數(shù)據(jù)管理簡單一些,之前講到為什么淘汰了GreenPlum,是因為數(shù)據(jù)同步復(fù)雜,數(shù)據(jù)的預(yù)計算不好控制,所以希望數(shù)據(jù)管理可以更簡單一些.預(yù)計算的過程和結(jié)果的同步不需要二次開發(fā),最好由OLAP計算引擎自己管理.同時之前講到我們會有一個預(yù)先設(shè)計存在過度設(shè)計的問題,這個問題怎么解決?我們目前的場景是有Presto來兜底的,如果沒有命中CUBE,那兜底的好處就是說我們還可以用Presto來承載計算,這讓設(shè)計預(yù)計算查詢的時候它的選擇余地會更多.它不需要完全根據(jù)用戶的需求或者業(yè)務(wù)需求把所有的設(shè)計在里面,只要挑自己合適的就可以,對于那些沒有命中的SQL,雖然慢了一點,但給我們帶來的好處就是管理的成本大大降低了.

Kylin：eBay貢獻的開源MOLAP引擎

Kylin是由eBay開源的一個引擎,Kylin把數(shù)據(jù)讀出來做計算,結(jié)算的結(jié)果會被存在HBase里,通過HBase做Ad-hoc的功能.HBase的好處是有索引的,所以做Ad-hoc的性能非常好.

為什么是Kylin

首先空間換時間,我們在剛開始引入Kylin時跟Kylin開發(fā)聊過,他們借鑒了Oracle CUBE的概念,對傳統(tǒng)數(shù)據(jù)庫開發(fā)的人來說很容易理解概念和使用.支持維度建模自然支持也Join.預(yù)計算的過程是由Kylin自己管理的,也開放了API,與調(diào)度系統(tǒng)打通做數(shù)據(jù)刷新.另外Kylin是在eBay上很大的、美團也是投入了很大的精力的有成功經(jīng)驗的產(chǎn)品,所以很容易地引進來了.

第4階段

于是,我們進入了唯品會OLAP分析架構(gòu)的第四階段：Hybird：Presto的ROLAP和Kylin的MOLAP結(jié)合發(fā)揮各自優(yōu)勢,Redis緩存進一步提升效率.

查詢在Query Engine根據(jù)Redis-> Kylin再到Presto的優(yōu)先級進行路由探查,在找到第一個可命中的路徑之后,轉(zhuǎn)向?qū)?yīng)的引擎進行計算并給用戶返回結(jié)果.Kylin的引入主要用于提升核心指標(biāo)的OLAP分析的首次響應(yīng)速度.這個狀態(tài)可以看到Kylin的查詢覆蓋率平均15%,最高25%,大幅提升核心數(shù)據(jù)的查詢.同時流量幾十億、幾百億的數(shù)據(jù)從Kylin走也大大地減輕了Presto.雖然說這樣的架構(gòu)看起來挺復(fù)雜的,但這樣的一個架構(gòu)出來之后,基本上滿足了90%的OLAP分析了.

OLAP分析的技術(shù)進化是一個迷宮而不是金字塔

經(jīng)過這么長一段時間的演進和一些摸索之后,我們覺得OLAP分析的技術(shù)是它的進化是一個迷宮,不是一個金字塔.過去說升級,像金字塔往上攀登,但實際上在剛才的過程大家發(fā)現(xiàn)實際上它更是像走迷宮,每個轉(zhuǎn)角其實是都碰到了問題,在這個轉(zhuǎn)角,在當(dāng)時的情況下找最佳的方案.

不是做了大數(shù)據(jù)之后放棄了計算,也不是做了大數(shù)據(jù)不再考慮數(shù)據(jù)同步的問題.其實可以發(fā)現(xiàn)很多傳統(tǒng)數(shù)據(jù)倉庫或者RBDMS的索引、CUBE之類的概念慢慢重新回到了大數(shù)據(jù)的視野里面.對我們而言,我們認為更多的時候,我們在做一些大數(shù)據(jù)的新技術(shù)演進時更多的是用更優(yōu)秀的技術(shù)來做落地和實現(xiàn),而不是去拒絕過去的一些大家感覺好像比較陳舊的的邏輯或概念.所以說對每個人來說,適合自己業(yè)務(wù)的場景方案才是最好的方案.

3.唯品會在開源計算引擎上所做的改進

接下來講一下我們在開源計算引擎上做的改進.Presto和Kylin的角度不一樣,所以我們在優(yōu)化的方向上也不同.Presto主要注重提升查詢性能,減少計算量,提升實時性.Kylin最主要優(yōu)化維表查找,提高CUBE的利用率.

Presto上的改進

在提升查詢性能上：

• 新增Hint語法,首先做的也是最重要的改動是在Presto中增加了一個Hint的語法,可以在SQL Join級別動態(tài)設(shè)置策略,通過編譯時讓讓join在replica和distribute兩者之間設(shè)置,提高Join效率；
• 監(jiān)控告警JOIN數(shù)據(jù)傾斜,通過減少數(shù)據(jù)傾斜提高執(zhí)行效率；
• 增加多集群LOAD BALANCE,可平衡不同集群間計算量；
• 經(jīng)過改造,Presto的查詢實時性大幅提升.

在減少計算量上：

• 新增Kylin Connector,通過CUBE探嗅自動匹配SQL子查詢中可以命中Kylin CUBE的部分,從Kylin提取數(shù)據(jù)后做進一步的計算,降低查詢計算量；
• 經(jīng)過改造,Presto升級為Hybird OLAP引擎,同時支持ROLAP和MOLAP兩種模式.

在提高實時性上：

• 重寫Kafka Connector,支持熱更新Kafka中Topic、Message 和表/列的映射定義；
• 支持Kafka按offset讀取數(shù)據(jù),支持PB格式,提高Kafka數(shù)據(jù)源的讀取效率；
• 經(jīng)過改造,Presto不僅是離線OLAP引擎,準(zhǔn)實時數(shù)據(jù)處理的能力也得到提高.

Kylin上的改進

在優(yōu)化維表查找上：

• 通過引入Presto解決Kylin億級維表實時Lookup OOM的問題,通過Presto查詢替換了原有復(fù)雜的維表映射值查找機制;
• 經(jīng)過改造,唯品會版的Kylin相比開源版本極大的擴展了對業(yè)務(wù)場景的支持程度.

在提升CUBE利用率上：

• 開發(fā)CUBE Advisor,通過統(tǒng)計分析總結(jié)合適的維度和指標(biāo)組合輔助開發(fā)選擇判斷新建CUBE的策略,減少冗余和經(jīng)驗判斷上的誤差;
• 提供CUBE命中率監(jiān)控,形成CUBE新建、使用到總結(jié)升級的閉環(huán);
• 經(jīng)此改造,CUBE命中率大幅提高,減少了資源的浪費提升了響應(yīng)速度,經(jīng)過這樣的改造,開發(fā)不再只是根據(jù)自己的經(jīng)驗或者盲目建立,而是有數(shù)據(jù)可依.

4.OLAP方案升級方向

最后我們講一下OLAP升級方向.

對于Presto,我們將探索如何用RowID級別的索引的存儲格式替換現(xiàn)有RowGroup級別索引的ORC File,在數(shù)據(jù)Scan級別盡可能精確的獲取所需的數(shù)據(jù),減少數(shù)據(jù)量,同時提高OLAP查詢的并發(fā)度,應(yīng)對大量用戶并發(fā)OLAP分析場景.

對于Kylin,我們會嘗試Streaming Cubing,使得Kylin OLAP分析從離線數(shù)據(jù)向?qū)崟r數(shù)據(jù)遷移,以及探索Lamda Cubing,實現(xiàn)實時離線CUBE無縫融合.

最后,嘗試探索下一代的方案,需要有更強的實時離線融合,與更強的原始數(shù)據(jù)和匯總的數(shù)據(jù)的融合,以及更強的數(shù)據(jù)處理能力,短期來講沒有更好的方案,希望跟大家一起討論.

文章來自微信公眾號：DBAplus社群

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/2210.html