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

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

講師介紹

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

分享大綱：

1. 海量數(shù)據(jù)實(shí)時(shí)OLAP場(chǎng)景的困境
2. 唯品會(huì)大數(shù)據(jù)實(shí)時(shí)OLAP升級(jí)過(guò)程
3. 唯品會(huì)在開(kāi)源計(jì)算引擎上所做的改進(jìn)
4. OLAP方案升級(jí)方向

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

大數(shù)據(jù)

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

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

慢查詢(xún)

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

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

長(zhǎng)迭代

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

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

2.唯品會(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工具,開(kāi)發(fā)速度比較快,同時(shí)有數(shù)據(jù)可視化效果,業(yè)務(wù)部分非常認(rèn)可.GreenPlum是MPP的方案,它的高并發(fā)查詢(xún)非常適合我們這種OLAP的查詢(xún),性能非常好.所以我們?cè)谶@個(gè)階段,把GreenPlum作為數(shù)據(jù)倉(cāng)庫(kù)和OLAP混用的實(shí)現(xiàn).

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

第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,就交給專(zhuān)為批量而生的Hive來(lái)做,這樣就能把OLAP和數(shù)據(jù)倉(cāng)庫(kù)這兩個(gè)場(chǎng)景用兩個(gè)不一樣技術(shù)棧分開(kāi).這樣一個(gè)技術(shù)方案解決了數(shù)據(jù)量大的問(wèn)題,ETL批量就不會(huì)說(shuō)跑不動(dòng)或者數(shù)據(jù)沒(méi)法存儲(chǔ).

但問(wèn)題是增加了新的同步機(jī)制,需要在兩個(gè)不同的DB之間同步數(shù)據(jù).同步數(shù)據(jù)最顯而易見(jiàn)的問(wèn)題就是除了數(shù)據(jù)冗余外,如果數(shù)據(jù)不同步怎么辦?比如ETL開(kāi)發(fā)在Hadoop上更新,但沒(méi)有同步到GreenPlum上,用戶(hù)會(huì)發(fā)現(xiàn)數(shù)據(jù)還是錯(cuò)誤的.第二,對(duì)用戶(hù)來(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)不能滿(mǎn)足他們.

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

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

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

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

第2階段

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

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

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

所以我們就開(kāi)發(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ù)同步的問(wèn)題,第三是什么?其實(shí)預(yù)計(jì)算的時(shí)候大家會(huì)經(jīng)常發(fā)現(xiàn)我們認(rèn)為這些組合是有效的,用戶(hù)可能不會(huì)查,但不去查這次計(jì)算就浪費(fèi)掉了.是不是有更好的辦法去解決這種現(xiàn)狀?

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

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

1. 沒(méi)有預(yù)計(jì)算的模型.因?yàn)轭A(yù)計(jì)算的缺點(diǎn)是沒(méi)有傳統(tǒng)意義上的數(shù)據(jù)匯總層,直接從DW層明細(xì)數(shù)據(jù)上的直接計(jì)算.而且我們所有的業(yè)務(wù)場(chǎng)景化,只要DW層有這個(gè)數(shù)據(jù)就不用再開(kāi)發(fā)了,直接拿來(lái)用就可以了.之前我們講到數(shù)據(jù)先匯總,有些緩慢變化是需要刷數(shù)據(jù)的,這個(gè)頭很疼,也要解決.
2. 速度要足夠快.數(shù)據(jù)平均10秒返回,看上去挺慢的,不是秒出,為什么當(dāng)時(shí)定這樣的目標(biāo)?因?yàn)閯偛胖v到之前的開(kāi)發(fā)方式業(yè)務(wù)要排期等,這個(gè)周期非常長(zhǎng),如果現(xiàn)在通過(guò)一個(gè)可以隨意組合的方式去滿(mǎn)足它90%以上的需求,其實(shí)它在真正做的時(shí)候?qū)π阅艿囊蟛](méi)有那么嚴(yán)苛.我們也不希望這邊查詢(xú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í)沒(méi)有DB同步的問(wèn)題.這里面東西還是挺多的,怎么解決這個(gè)問(wèn)題呢?我們把需求分解了一下.

首先查詢(xún)速度要快,我們需要一個(gè)SQL內(nèi)在的高并發(fā).其次用純內(nèi)存計(jì)算代替內(nèi)存+硬盤(pán)的計(jì)算,內(nèi)存+硬盤(pán)的計(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ì)算能力,如果想做到完全沒(méi)有服務(wù)降級(jí)的擴(kuò)容,一個(gè)計(jì)算引擎沒(méi)有狀態(tài)是最好的,同時(shí)計(jì)算的節(jié)點(diǎn)互相無(wú)依賴(lài).最后一點(diǎn)是方案成熟穩(wěn)定,因?yàn)檫@是在嘗試新的OLAP方案,如果這個(gè)OLAP方案不穩(wěn)定,直接影響到了用戶(hù)體驗(yàn),我們希望線(xiàn)上出問(wèn)題時(shí)我們不至于手忙腳亂到?jīng)]辦法快速解決.

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

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

為什么是Presto

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

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秒,可見(jiàn)它的提升是非常明顯的.

當(dāng)我們做完性能測(cè)試時(shí),我們一個(gè)專(zhuān)門(mén)做引擎開(kāi)發(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ò)展到包括訂單、銷(xiāo)售之類(lèi)的事務(wù)型分析上.用了之后中位數(shù)返回時(shí)間5秒鐘,平均返回時(shí)間15秒,基本上這段時(shí)間可以返回所有的OLAP查詢(xún).因?yàn)橛昧薉W數(shù)據(jù),維度更豐富,大多數(shù)的需求問(wèn)題被解決.

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

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

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

于是這里就講到了緩存復(fù)用.第一個(gè)階段完全相同的直接返回,第二個(gè)階段更進(jìn)一步,相對(duì)來(lái)說(shuō)更復(fù)雜一些,如果說(shuō)提出一個(gè)新的SQL,結(jié)果是上一個(gè)的,我們也不結(jié)算,從上一個(gè)結(jié)果里面直接做二次處理,把緩存的數(shù)據(jù)拿出來(lái)反饋給用戶(hù).除了這個(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,我們做二次開(kāi)發(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稱(chēng)為一個(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找有沒(méi)有這個(gè)SQL緩存的記錄,有就直接返回給用戶(hù),沒(méi)有再到Presto上面查詢(xún).上線(xiàn)了之后,我們觀察了結(jié)果,結(jié)果也是非常不錯(cuò)的,發(fā)現(xiàn)平均的緩存命中率達(dá)到15%,意味著這15%的查詢(xún)都是秒出.

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

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

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

空間換時(shí)間,如果說(shuō)OLAP ad-hoc查詢(xún)從事先計(jì)算好的結(jié)果里查詢(xún),那是不是返回速度也會(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é)果的同步不需要二次開(kāi)發(fā),最好由OLAP計(jì)算引擎自己管理.同時(shí)之前講到我們會(huì)有一個(gè)預(yù)先設(shè)計(jì)存在過(guò)度設(shè)計(jì)的問(wèn)題,這個(gè)問(wèn)題怎么解決?我們目前的場(chǎng)景是有Presto來(lái)兜底的,如果沒(méi)有命中CUBE,那兜底的好處就是說(shuō)我們還可以用Presto來(lái)承載計(jì)算,這讓設(shè)計(jì)預(yù)計(jì)算查詢(xún)的時(shí)候它的選擇余地會(huì)更多.它不需要完全根據(jù)用戶(hù)的需求或者業(yè)務(wù)需求把所有的設(shè)計(jì)在里面,只要挑自己合適的就可以,對(duì)于那些沒(méi)有命中的SQL,雖然慢了一點(diǎn),但給我們帶來(lái)的好處就是管理的成本大大降低了.

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

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

為什么是Kylin

首先空間換時(shí)間,我們?cè)趧傞_(kāi)始引入Kylin時(shí)跟Kylin開(kāi)發(fā)聊過(guò),他們借鑒了Oracle CUBE的概念,對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)開(kāi)發(fā)的人來(lái)說(shuō)很容易理解概念和使用.支持維度建模自然支持也Join.預(yù)計(jì)算的過(guò)程是由Kylin自己管理的,也開(kāi)放了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ā)揮各自?xún)?yōu)勢(shì),Redis緩存進(jìn)一步提升效率.

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

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

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

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

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

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

Presto上的改進(jìn)

在提升查詢(xú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的查詢(xún)實(shí)時(shí)性大幅提升.

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

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

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

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

Kylin上的改進(jìn)

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

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

在提升CUBE利用率上：

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

4.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查詢(xún)的并發(fā)度,應(yīng)對(duì)大量用戶(hù)并發(fā)OLAP分析場(chǎng)景.

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

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

文章來(lái)自微信公眾號(hào)：DBAplus社群

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