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

（點(diǎn)擊底部“閱讀原文”獲取謝麟炯演講完整PPT）

講師介紹

分享大綱：

海量數(shù)據(jù)實(shí)時(shí)OLAP場(chǎng)景的困境

大數(shù)據(jù)

首先來(lái)看一下我們?cè)谧畛鯉啄暧龅降膯栴}。第一就是大數(shù)據(jù)，聽起來(lái)好像蠻無(wú)聊的，但大數(shù)據(jù)到底是指什么呢？最主要的問題就是數(shù)據(jù)大，唯品會(huì)在這幾年快速發(fā)展，用戶流量數(shù)據(jù)從剛開始的幾百萬(wàn)、幾千萬(wàn)發(fā)展到現(xiàn)在的幾個(gè)億，呈現(xiàn)了100倍以上的增長(zhǎng)。

對(duì)我們而言，所謂的大數(shù)據(jù)就是數(shù)據(jù)量的快速膨脹，帶來(lái)的問題最主要的就是傳統(tǒng)RDBMS無(wú)法滿足存儲(chǔ)的需求，繼而是計(jì)算的需求，我們的挑戰(zhàn)便是如何克服這個(gè)問題。

慢查詢

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

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

長(zhǎng)迭代

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

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

唯品會(huì)大數(shù)據(jù)實(shí)時(shí)OLAP升級(jí)過(guò)程

第0階段

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

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

第1階段

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

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

我們需要一個(gè)新的BI解決方案

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

1. 首先它要足夠靈活，不能發(fā)布之后用戶什么都不能做，只能看，我們希望它的維度和指標(biāo)可以快速整合。

2. 第二，門檻要低，我們不可能希望業(yè)務(wù)像BI工程師學(xué)習(xí)它的開發(fā)是怎么做的，所以它要入門非常簡(jiǎn)單。其次，要能夠用語(yǔ)言描述自己的需求，而不是用SQL，讓商務(wù)這種感性思維的人學(xué)SQL簡(jiǎn)直是不可能的，所以要能用語(yǔ)言描述他們自己想要什么。

3. 第三就是開發(fā)周期短，業(yè)務(wù)想看什么，所有的數(shù)據(jù)都需要提需求，需求分析，排期實(shí)施，提變更又要排期實(shí)施，這時(shí)候雖然說(shuō)業(yè)務(wù)發(fā)展不是一天一變，但很多業(yè)務(wù)試錯(cuò)的時(shí)間非常快，數(shù)據(jù)開發(fā)出來(lái)黃花菜都涼了。所以希望有一個(gè)新的BI方案解決這三個(gè)問題。

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

第2階段

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

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

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

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

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

我們需要一個(gè)新的OLAP計(jì)算引擎

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

1. 沒有預(yù)計(jì)算的模型。因?yàn)轭A(yù)計(jì)算的缺點(diǎn)是沒有傳統(tǒng)意義上的數(shù)據(jù)匯總層，直接從DW層明細(xì)數(shù)據(jù)上的直接計(jì)算。而且我們所有的業(yè)務(wù)場(chǎng)景化，只要DW層有這個(gè)數(shù)據(jù)就不用再開發(fā)了，直接拿來(lái)用就可以了。之前我們講到數(shù)據(jù)先匯總，有些緩慢變化是需要刷數(shù)據(jù)的，這個(gè)頭很疼，也要解決。

2. 速度要足夠快。數(shù)據(jù)平均10秒返回，看上去挺慢的，不是秒出，為什么當(dāng)時(shí)定這樣的目標(biāo)？因?yàn)閯偛胖v到之前的開發(fā)方式業(yè)務(wù)要排期等，這個(gè)周期非常長(zhǎng)，如果現(xiàn)在通過(guò)一個(gè)可以隨意組合的方式去滿足它90%以上的需求，其實(shí)它在真正做的時(shí)候?qū)π阅艿囊蟛]有那么嚴(yán)苛。我們也不希望這邊查詢的時(shí)候因?yàn)榈却龜?shù)據(jù)把自己分析的思路或者日程打亂了，10秒可能是比較合適的。然后，因?yàn)槲覀兊臄?shù)據(jù)倉(cāng)庫(kù)DW層用維度建模，所以這個(gè)OLAP引擎必須支持Join。

3. 最后是支持橫向擴(kuò)展，計(jì)算能力可通過(guò)計(jì)算節(jié)點(diǎn)擴(kuò)容獲得提高，同時(shí)沒有DB同步的問題。這里面東西還是挺多的，怎么解決這個(gè)問題呢？我們把需求分解了一下。

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

Presto：Facebook貢獻(xiàn)的開源MPP OLAP引擎

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

為什么是Presto

從原理上來(lái)看，高并發(fā)查詢因?yàn)槭荕PP引擎的支持。純內(nèi)存計(jì)算，它是純內(nèi)存的，跟硬盤沒有任何交互。第三，因?yàn)樗且粋€(gè)SQL引擎，所以支持Join。另外數(shù)據(jù)沒有存儲(chǔ)，數(shù)據(jù)直接存儲(chǔ)在HDFS上。計(jì)算引擎沒有狀態(tài)，計(jì)算節(jié)點(diǎn)互相無(wú)依賴都是滿足的。另外它也是一個(gè)成熟方案，F(xiàn)acebook本身也是大廠，國(guó)外有谷歌在用，國(guó)內(nèi)京東也有自己的版本，所以這個(gè)東西其實(shí)還是滿足我們需求的。

Presto性能測(cè)試

我們?cè)谟弥白隽薖OC。我們做了一個(gè)嘗試，把在我們平臺(tái)上常用的SQL（不用TPCH的原因是我們平臺(tái)的SQL更適合我們的場(chǎng)景），在GP和Presto兩個(gè)計(jì)算引擎上，用相同的機(jī)器配置和節(jié)點(diǎn)數(shù)同時(shí)做了一次基準(zhǔn)性能測(cè)試，可以看到結(jié)果是非常令人歡喜的。

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

當(dāng)我們做完性能測(cè)試時(shí)，我們一個(gè)專門做引擎開發(fā)的同學(xué)叫了起來(lái)，說(shuō)就你了，用Presto替代GreenPlum。

第3階段

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

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

最快的計(jì)算方法是不計(jì)算

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

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

Redis：成熟的緩存方案

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

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

第3.5階段

于是這時(shí)就把Redis的方案引入進(jìn)來(lái)。

引入Redis之后帶來(lái)一個(gè)新的挑戰(zhàn)，我們不是只有一個(gè)計(jì)算引擎，我們暫時(shí)先把Redis稱為一個(gè)計(jì)算引擎，因?yàn)閿?shù)據(jù)可能在Redis，也可能需要通過(guò)Presto去把數(shù)據(jù)讀出來(lái)，這時(shí)我們?cè)趧偛派蒘QL之后還加入了新的一個(gè)組件，Query Engine的目的就是在不同的引擎之間做路由，找到最快返回?cái)?shù)據(jù)的匹配。比如說(shuō)我們一個(gè)SQL發(fā)下來(lái)，它會(huì)先去找Redis，看在Redis找有沒有這個(gè)SQL緩存的記錄，有就直接返回給用戶，沒有再到Presto上面查詢。上線了之后，我們觀察了結(jié)果，結(jié)果也是非常不錯(cuò)的，發(fā)現(xiàn)平均的緩存命中率達(dá)到15%，意味著這15%的查詢都是秒出。

因?yàn)槲覀冇胁煌闹黝}，流量主題、銷售、收藏、客戶，類似不同的主題，用戶查詢的組合不一樣，特殊的場(chǎng)景下，命中率達(dá)到60%，這樣除去緩存的返回速度非常快之外，緩存也有好處，就是釋放了Presto的計(jì)算能力，原先需要跑一次的查詢便不需要了。釋放出來(lái)的內(nèi)存和CPU就可以給其它的查詢提供計(jì)算能力了。

空間換時(shí)間：OLAP分析的另一條途徑

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

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

Kylin：eBay貢獻(xiàn)的開源MOLAP引擎

Kylin是由eBay開源的一個(gè)引擎，Kylin把數(shù)據(jù)讀出來(lái)做計(jì)算，結(jié)算的結(jié)果會(huì)被存在HBase里，通過(guò)HBase做Ad-hoc的功能。HBase的好處是有索引的，所以做Ad-hoc的性能非常好。

為什么是Kylin

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

第4階段

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

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

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

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

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

唯品會(huì)在開源計(jì)算引擎上所做的改進(jìn)

接下來(lái)講一下我們?cè)陂_源計(jì)算引擎上做的改進(jìn)。Presto和Kylin的角度不一樣，所以我們?cè)趦?yōu)化的方向上也不同。Presto主要注重提升查詢性能，減少計(jì)算量，提升實(shí)時(shí)性。Kylin最主要優(yōu)化維表查找，提高CUBE的利用率。

Presto上的改進(jìn)

在提升查詢性能上：

• 新增Hint語(yǔ)法，首先做的也是最重要的改動(dòng)是在Presto中增加了一個(gè)Hint的語(yǔ)法，可以在SQL Join級(jí)別動(dòng)態(tài)設(shè)置策略，通過(guò)編譯時(shí)讓讓join在replica和distribute兩者之間設(shè)置，提高Join效率；

• 監(jiān)控告警JOIN數(shù)據(jù)傾斜，通過(guò)減少數(shù)據(jù)傾斜提高執(zhí)行效率；

• 增加多集群LOAD BALANCE，可平衡不同集群間計(jì)算量；

• 經(jīng)過(guò)改造，Presto的查詢實(shí)時(shí)性大幅提升。

在減少計(jì)算量上：

• 新增Kylin Connector，通過(guò)CUBE探嗅自動(dòng)匹配SQL子查詢中可以命中Kylin CUBE的部分，從Kylin提取數(shù)據(jù)后做進(jìn)一步的計(jì)算，降低查詢計(jì)算量；

• 經(jīng)過(guò)改造，Presto升級(jí)為Hybird OLAP引擎，同時(shí)支持ROLAP和MOLAP兩種模式。

在提高實(shí)時(shí)性上：

• 重寫Kafka Connector，支持熱更新Kafka中Topic、Message 和表/列的映射定義；

• 支持Kafka按offset讀取數(shù)據(jù)，支持PB格式，提高Kafka數(shù)據(jù)源的讀取效率；

• 經(jīng)過(guò)改造，Presto不僅是離線OLAP引擎，準(zhǔn)實(shí)時(shí)數(shù)據(jù)處理的能力也得到提高。

Kylin上的改進(jìn)

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

• 通過(guò)引入Presto解決Kylin億級(jí)維表實(shí)時(shí)Lookup OOM的問題，通過(guò)Presto查詢替換了原有復(fù)雜的維表映射值查找機(jī)制;

• 經(jīng)過(guò)改造，唯品會(huì)版的Kylin相比開源版本極大的擴(kuò)展了對(duì)業(yè)務(wù)場(chǎng)景的支持程度.

在提升CUBE利用率上：

• 開發(fā)CUBE Advisor，通過(guò)統(tǒng)計(jì)分析總結(jié)合適的維度和指標(biāo)組合輔助開發(fā)選擇判斷新建CUBE的策略，減少冗余和經(jīng)驗(yàn)判斷上的誤差;

• 提供CUBE命中率監(jiān)控，形成CUBE新建、使用到總結(jié)升級(jí)的閉環(huán);

• 經(jīng)此改造，CUBE命中率大幅提高，減少了資源的浪費(fèi)提升了響應(yīng)速度，經(jīng)過(guò)這樣的改造，開發(fā)不再只是根據(jù)自己的經(jīng)驗(yàn)或者盲目建立，而是有數(shù)據(jù)可依。

OLAP方案升級(jí)方向

最后我們講一下OLAP升級(jí)方向。

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

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

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

相關(guān)專題：

• 年度巨獻(xiàn)！DAMS 2017 中國(guó)數(shù)據(jù)資產(chǎn)管理峰會(huì)圓滿落幕

• 唯品會(huì)大數(shù)據(jù)存儲(chǔ)和計(jì)算資源管理的痛、解決方法與思路

贈(zèng)書來(lái)了

在本文微信訂閱號(hào)（dbaplus）評(píng)論區(qū)留下足以引起共鳴的真知灼見，并在本文發(fā)布后的隔天中午12點(diǎn)成為點(diǎn)贊數(shù)最多的2名，可獲得以下新書一本~

特別鳴謝博文視點(diǎn)為活動(dòng)提供圖書贊助。