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

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

講師介紹

分享大綱：

海量數(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ì)疑，我們需要改進(jìn)來解決這些問題。

業(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)狀之間的沖突。

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

第0階段

這是我們的初始狀態(tài)，架構(gòu)比較簡單。底層的計算、存儲和OLAP分析用MDB的數(shù)據(jù)倉庫解決的，上層用Tableau的BI工具，開發(fā)速度比較快，同時有數(shù)據(jù)可視化效果，業(yè)務(wù)部分非常認(rèn)可。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階段

所以很快我們就進(jìn)入了第一階段。這個階段，我們引入了Hadoop/Hive，所有的計算結(jié)果做預(yù)計算之后，會同步到GreenPlum里面，接下去一樣，用GreenPlum去做分析。OLAP講聚合講的Ad-hoc，繼續(xù)由GreenPlum承載，數(shù)據(jù)倉庫講明細(xì)數(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)進(jìn)化的需求。所以我們需要一個新的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階段

我們進(jìn)入了OLAP分析的第二個階段，這時前端開發(fā)了一個產(chǎn)品叫自助分析平臺，這個平臺上用戶可以通過拖拉拽把左邊的維度指標(biāo)自己組合拖到上面，組成自己想看的結(jié)果。結(jié)果查詢出來后可以用表格也可以圖形進(jìn)行展示，包括折線、柱狀、條形圖，這里面所有的分析結(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，還要進(jìn)行性能的調(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)我們認(rèn)為這些組合是有效的，用戶可能不會查，但不去查這次計算就浪費掉了。是不是有更好的辦法去解決這種現(xiàn)狀？

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

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

1. 沒有預(yù)計算的模型。因為預(yù)計算的缺點是沒有傳統(tǒng)意義上的數(shù)據(jù)匯總層，直接從DW層明細(xì)數(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ū)π阅艿囊蟛]有那么嚴(yán)苛。我們也不希望這邊查詢的時候因為等待數(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貢獻(xiàn)的開源MPP OLAP引擎

這時候Presto進(jìn)入我們的視野，它是Facebook貢獻(xiàn)的開源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é)點互相無依賴都是滿足的。另外它也是一個成熟方案，F(xiàn)acebook本身也是大廠，國外有谷歌在用，國內(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引進(jìn)來之后，我們發(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ù)用。第一個階段完全相同的直接返回，第二個階段更進(jìn)一步，相對來說更復(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的方案引入進(jìn)來。

引入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)平均的緩存命中率達(dá)到15%，意味著這15%的查詢都是秒出。

因為我們有不同的主題，流量主題、銷售、收藏、客戶，類似不同的主題，用戶查詢的組合不一樣，特殊的場景下，命中率達(dá)到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貢獻(xiàn)的開源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)品，所以很容易地引進(jìn)來了。

第4階段

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

查詢在Query Engine根據(jù)Redis-> Kylin再到Presto的優(yōu)先級進(jìn)行路由探查，在找到第一個可命中的路徑之后，轉(zhuǎn)向?qū)?yīng)的引擎進(jìn)行計算并給用戶返回結(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ìn)化是一個迷宮而不是金字塔

經(jīng)過這么長一段時間的演進(jìn)和一些摸索之后，我們覺得OLAP分析的技術(shù)是它的進(jìn)化是一個迷宮，不是一個金字塔。過去說升級，像金字塔往上攀登，但實際上在剛才的過程大家發(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ù)的視野里面。對我們而言，我們認(rèn)為更多的時候，我們在做一些大數(shù)據(jù)的新技術(shù)演進(jìn)時更多的是用更優(yōu)秀的技術(shù)來做落地和實現(xiàn)，而不是去拒絕過去的一些大家感覺好像比較陳舊的的邏輯或概念。所以說對每個人來說，適合自己業(yè)務(wù)的場景方案才是最好的方案。

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

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

Presto上的改進(jìn)

在提升查詢性能上：

• 新增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ìn)一步的計算，降低查詢計算量；

• 經(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上的改進(jìn)

在優(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ù)可依。

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ù)處理能力，短期來講沒有更好的方案，希望跟大家一起討論。

相關(guān)專題：

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

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

贈書來了

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

特別鳴謝博文視點為活動提供圖書贊助。