惟品會海量實時OLAP分析技術升級之路

本文轉載自公衆號 DBAplus社羣 ， 做者：謝麟炯

謝麟炯，惟品會大數據平臺高級技術架構經理，主要負責大數據自助多維分析平臺，離線數據開發平臺及分析引擎團隊的開發和管理工做，加入惟品會以來還曾負責流量基礎數據的採集和數據倉庫建設以及移動流量分析等數據產品的工做。

---

海量數據實時OLAP場景的困境

大數據

首先來看一下咱們在最初幾年遇到的問題。第一就是大數據，聽起來好像蠻無聊的，但大數據究竟是指什麼呢？最主要的問題就是數據大，惟品會在這幾年快速發展，用戶流量數據從剛開始的幾百萬、幾千萬發展到如今的幾個億，呈現了100倍以上的增加。

對咱們而言，所謂的大數據就是數據量的快速膨脹，帶來的問題最主要的就是傳統RDBMS沒法知足存儲的需求，繼而是計算的需求，咱們的挑戰即是如何克服這個問題。

慢查詢

第二個問題是慢查詢，有兩個方面：一是OLAP查詢的速度變慢；二是ETL數據處理效率下降。

分析下這兩個問題：首先，用戶使用OLAP分析系統時會有這樣的預期，當我點擊查詢按鈕時但願全部的數據可以秒出，而不是我抽身去泡個茶，回來一看數據才跑了10%，這是沒法接受的。因爲數據量大，咱們也能夠選擇預先計算好，當用戶查詢時直接從計算結果中找到對應的值返回，那麼查詢就是秒出的。數據量大對預計算而言也有一樣的問題，就是ETL的性能也降低了，原本準備這個數據可能只需40分鐘或一個小時，如今數據量翻了一百倍，須要三個小時，這時候數據分析師上班時就會抱怨數據沒有準備好，得等到中午分析之類的，會聽到來自同事不斷的抱怨。

長迭代

數據量變大帶來的第三個毛病，就是開發週期變長。兩個角度：第一，新業務上線，用戶會說我能不能在這個新的角度上線前，看看歷史數據，要看一年的，這時就要刷數據了。刷數據這件事情你們知道，每次刷頭都很大，花的時間很長。舊業務也同樣，加新的指標，沒有歷史趨勢也不行，也要刷數據，開發就不斷地刷數據。由於數據量大，刷數據的時間很是長，數據驗證也須要花不少的時間，慢慢的，開發週期變慢，業務很急躁，以爲不就是加個字段嗎，怎麼這麼慢。這樣一來，數據的迭代長，週期變慢，都讓業務部門對大數據業務提出不少的質疑，咱們須要改進來解決這些問題。

業務部門的想法是，無論你是什麼業務，無論如今用的是什麼方法，他們只關心三點：第一，提的需求要很快知足；第二，數據要很快準備好；第三，數據準備好以後，當我來作分析時數據可以很快地返回。業務要的是快快快，但如今的能力是慢慢慢，爲此，咱們急需解決業務部門的需求和現狀之間的衝突。

 

惟品會大數據實時OLAP升級過程

第0階段

這是咱們的初始狀態，架構比較簡單。底層的計算、存儲和OLAP分析用MDB的數據倉庫解決的，上層用Tableau的BI工具，開發速度比較快，同時有數據可視化效果，業務部分很是承認。GreenPlum是MPP的方案，它的高併發查詢很是適合咱們這種OLAP的查詢，性能很是好。因此咱們在這個階段，把GreenPlum做爲數據倉庫和OLAP混用的實現。

這樣一個架構實際上是一個通用的架構，像Tableau能夠輕易被替換， GreenPlum也能夠替換成Oracle之類的，這樣一個經常使用的工具、一個架構，其實知足了部分的需求，但也有個問題，就是像GreenPlum這樣的RDBMS數據庫，在面對海量的數據寫入時存儲和計算的資源快速地枯竭了， GreenPlum的水平擴展有限，因此一樣碰到了大數據的問題。

第1階段

因此很快咱們就進入了第一階段。這個階段，咱們引入了Hadoop/Hive，全部的計算結果作預計算以後，會同步到GreenPlum裏面，接下去同樣，用GreenPlum去作分析。OLAP講聚合講的Ad-hoc，繼續由GreenPlum承載，數據倉庫講明細數據講Batch，就交給專爲批量而生的Hive來作，這樣就能把OLAP和數據倉庫這兩個場景用兩個不同技術棧分開。這樣一個技術方案解決了數據量大的問題，ETL批量就不會說跑不動或者數據無法存儲。

但問題是增長了新的同步機制，須要在兩個不一樣的DB之間同步數據。同步數據最顯而易見的問題就是除了數據冗餘外，若是數據不一樣步怎麼辦？好比ETL開發在Hadoop上更新，但沒有同步到GreenPlum上，用戶會發現數據仍是錯誤的。第二，對用戶來講，當他去作OLAP分析時，Tabluea是更適合作報表的工具，隨着咱們業務的擴展和數據驅動不斷的深刻，業務無論分析師仍是商務、運營、市場，他們會愈來愈多地想組合不一樣的指標和維度去觀察本身的數據，找本身運營的分析點。傳統的Tabluea報表已經不能知足他們。

咱們須要一個新的BI解決方案

對咱們來講數據不一樣步還能夠解決，畢竟是偶然發生的，處理一下就能夠了。可是BI工具備很大的問題，不能知足業務已經進化的需求。因此咱們須要一個新的BI解決方案：

1. 首先它要足夠靈活，不能發佈以後用戶什麼都不能作，只能看，咱們但願它的維度和指標能夠快速整合。
2. 第二，門檻要低，咱們不可能但願業務像BI工程師學習它的開發是怎麼作的，因此它要入門很是簡單。其次，要可以用語言描述本身的需求，而不是用SQL，讓商務這種感性思惟的人學SQL簡直是不可能的，因此要能用語言描述他們本身想要什麼。
3. 第三就是開發週期短，業務想看什麼，全部的數據都須要提需求，需求分析，排期實施，提變動又要排期實施，這時候雖說業務發展不是一天一變，但不少業務試錯的時間很是快，數據開發出來黃花菜都涼了。因此但願有一個新的BI方案解決這三個問題。

咱們看了一下市面上的商業工具並不適合，而且這樣靈活的方案須要咱們有更強的掌控性，因而咱們就開始走向了自研的道路。

第2階段

咱們進入了OLAP分析的第二個階段，這時前端開發了一個產品叫自助分析平臺，這個平臺上用戶能夠經過拖拉拽把左邊的維度指標本身組合拖到上面，組成本身想看的結果。結果查詢出來後能夠用表格也能夠圖形進行展現，包括折線、柱狀、條形圖，這裏面全部的分析結果都是可保存、可分享、可下載的。

利用這樣的工具能夠幫助分析師或者業務人員更好地自由的組合剛纔咱們所說的一切，而且靈活性、門檻低的問題其實也都迎刃而解了。並且像這樣拖拉拽是很是容易學習的，只要去學習怎麼把業務邏輯轉化成一個數據的邏輯描述，搞懂要怎麼轉化成什麼形式，行裏面顯示什麼，列顯示什麼，度量是什麼就能夠了，雖然有一點的學習曲線，但比起學習完整的BI工具，門檻下降了不少。

前端是這樣的產品，後端也要跟着它一塊兒變。首先前端是一個拖拉拽的UI組件，這個組件意味着用傳統的選擇SQL，直接造成報表的方式已經不可行了，由於全部的一切無論是維度指標都是用戶本身組合的，因此咱們須要一個SQL Parser幫助用戶把它的數據的描述轉化成SQL，還要進行性能的調優，保證以一個比較高的性能反饋數據。

因此咱們就開發了一個SQL Parser用來承接組件生成的數據結構，同時用SQL Parser直接去OLAP數據。仍是經過預計算的方式，把咱們須要的指標維度算好同步到SQL Parser。這樣的模型一旦創建，能夠屢次複用。

但咱們知道這個計算方案有幾個明顯的缺點：第一，全部的數據必須通過計算，計算範圍以外的不能組合；第二，仍是有數據同步的問題，第三是什麼？其實預計算的時候你們會常常發現咱們認爲這些組合是有效的，用戶可能不會查，但不去查此次計算就浪費掉了。是否是有更好的辦法去解決這種現狀？

咱們須要一個新的OLAP計算引擎

從這個角度來看GreenPlum已經不能知足咱們了，就算預先計算好也不能知足，須要一個新的OLAP計算引擎。這個新的引擎須要知足三個條件：

1. 沒有預計算的模型。由於預計算的缺點是沒有傳統意義上的數據彙總層，直接從DW層明細數據上的直接計算。並且咱們全部的業務場景化，只要DW層有這個數據就不用再開發了，直接拿來用就能夠了。以前咱們講到數據先彙總，有些緩慢變化是須要刷數據的，這個頭很疼，也要解決。
2. 速度要足夠快。數據平均10秒返回，看上去挺慢的，不是秒出，爲何當時定這樣的目標？由於剛纔講到以前的開發方式業務要排期等，這個週期很是長，若是如今經過一個能夠隨意組合的方式去知足它90%以上的需求，其實它在真正作的時候對性能的要求並無那麼嚴苛。咱們也不但願這邊查詢的時候由於等待數據把本身分析的思路或者日程打亂了，10秒多是比較合適的。而後，由於咱們的數據倉庫DW層用維度建模，因此這個OLAP引擎必須支持Join。
3. 最後是支持橫向擴展，計算能力可經過計算節點擴容得到提升，同時沒有DB同步的問題。這裏面東西仍是挺多的，怎麼解決這個問題呢？咱們把需求分解了一下。

首先查詢速度要快，咱們須要一個SQL內在的高併發。其次用純內存計算代替內存+硬盤的計算，內存+硬盤的計算講的就是Hive，Hive一個SQL啓動一下，包括實際計算過程都是很慢的。第二個是數據模型，剛纔講到數據倉庫纔是維度建模的，必須支持Join，像外面比較流行的Druid或者ES的方案其實不適用了。第三個就是數據不須要同步，意味着須要數據存在HDFS上，計算引擎要可以感知到Hive的Metadata。第四個是經過擴容提升計算能力，若是想作到徹底沒有服務降級的擴容，一個計算引擎沒有狀態是最好的，同時計算的節點互相無依賴。最後一點是方案成熟穩定，由於這是在嘗試新的OLAP方案，若是這個OLAP方案不穩定，直接影響到了用戶體驗，咱們但願線上出問題時咱們不至於手忙腳亂到沒辦法快速解決。

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

這時候Presto進入咱們的視野，它是Facebook貢獻的開源MPP OLAP引擎。這是一個紅酒的名字，由於開發組全部的人都喜歡喝這個牌子的紅酒，因此把它命名爲這個名字。做爲MPP引擎，它的處理方式是把全部的數據Scan出來，經過Hash的方法把數據變成更小的塊，讓不一樣的節點併發，處理完結果後快速地返回給用戶。咱們看到它的邏輯架構也是這樣，發起一個SQL，而後找這些數據在哪些HDFS節點上，而後分配後作具體的處理，最後再把數據返回。

爲何是Presto

從原理上來看，高併發查詢由於是MPP引擎的支持。純內存計算，它是純內存的，跟硬盤沒有任何交互。第三，由於它是一個SQL引擎，因此支持Join。另外數據沒有存儲，數據直接存儲在HDFS上。計算引擎沒有狀態，計算節點互相無依賴都是知足的。另外它也是一個成熟方案，Facebook自己也是大廠，國外有谷歌在用，國內京東也有本身的版本，因此這個東西其實仍是知足咱們需求的。

Presto性能測試

咱們在用以前作了POC。咱們作了一個嘗試，把在咱們平臺上經常使用的SQL（不用TPCH的緣由是咱們平臺的SQL更適合咱們的場景），在GP和Presto兩個計算引擎上，用相同的機器配置和節點數同時作了一次基準性能測試，能夠看到結果是很是使人歡喜的。

 

總體而言相同節點的Presto比GreenPlum的性能提高70%，並且SQL9到SQL16都從100多秒降低到10秒，可見它的提高是很是明顯的。

當咱們作完性能測試時，咱們一個專門作引擎開發的同窗叫了起來，說就你了，用Presto替代GreenPlum。

 

第3階段

在Presto引進來以後，咱們發現整個數據架構變得很是順暢，上層用拖拉拽的UI組件生成傳給SQL到Parser，而後傳給Presto執行。無論是流量數據，仍是埋點，仍是曝光數據返回很是快，同時咱們也把場景擴展到包括訂單、銷售之類的事務型分析上。用了以後中位數返回時間5秒鐘，平均返回時間15秒，基本上這段時間能夠返回全部的OLAP查詢。由於用了DW數據，維度更豐富，大多數的需求問題被解決。

用了Presto以後用戶的第一反應是爲何會這麼快，到底用了什麼黑科技。可是運行了一段時間後咱們觀察了用戶的行爲是什麼樣的，到底在查詢什麼樣的SQL，什麼維度和指標的組合，但願還能再作一些優化。

最快的計算方法是不計算

在這個時候咱們忽然發現，即便是用戶自由組合的指標也會發現不一樣業務在相同業務場景下會去查徹底相同的數據組合。好比不少用戶會查同一渠道的銷售流量轉化，如今的方案會有什麼問題呢？徹底相同的查詢也須要到上面真正執行一遍，實際上若是徹底相同的能夠直接返回結果不用計算了。因此咱們就在想怎麼解決這個問題？實際這裏有一個所謂的理論——就是最快的計算就是不計算，怎麼作呢？若是咱們可以模仿Oracle的BGA，把計算結果存儲下來，用戶查詢相同時能夠把數據取出來給用戶直接返回就行了。

因而這裏就講到了緩存複用。第一個階段徹底相同的直接返回，第二個階段更進一步，相對來講更復雜一些，若是說提出一個新的SQL，結果是上一個的，咱們也不結算，從上一個結果裏面直接作二次處理，把緩存的數據拿出來反饋給用戶。除了這個亮點以外，其實緩存很重要的就是生命週期管理，很是複雜，由於數據不斷地更新，緩存若是不更新可能查出來的數據不對，在數據庫會說這是髒讀或者幻影讀，咱們但願緩存的生命週期能夠本身管理，不但願是經過超時來管理緩存，咱們更但願緩存能夠管理本身的生命週期，跟源數據同步生命週期，這樣緩存使用效率會是最好的。

Redis：成熟的緩存方案

說到緩存要提到Redis，這是不少生產系統上大量使用的，它也很是適合OLAP。

首先咱們想要的是SQL跟結果一對一匹配，它是很是符合這個需求的。其次咱們但願緩存更快的返回，Redis是純內存的存儲，返回速度很是快，通常是毫秒級。第三個生命週期管理，它提供API，咱們作二次開發，跟咱們ETL調度系統打通，處理更新時就能夠通知什麼樣的數據能夠被用到。而緩存複用是不支持的，咱們能夠本身來作。

第3.5階段

因而這時就把Redis的方案引入進來。

引入Redis以後帶來一個新的挑戰，咱們不是隻有一個計算引擎，咱們暫時先把Redis稱爲一個計算引擎，由於數據可能在Redis，也可能須要經過Presto去把數據讀出來，這時咱們在剛纔生成SQL以後還加入了新的一個組件，Query Engine的目的就是在不一樣的引擎之間作路由，找到最快返回數據的匹配。好比說咱們一個SQL發下來，它會先去找Redis，看在Redis找有沒有這個SQL緩存的記錄，有就直接返回給用戶，沒有再到Presto上面查詢。上線了以後，咱們觀察告終果，結果也是很是不錯的，發現平均的緩存命中率達到15%，意味着這15%的查詢都是秒出。

由於咱們有不一樣的主題，流量主題、銷售、收藏、客戶，相似不一樣的主題，用戶查詢的組合不同，特殊的場景下，命中率達到60%，這樣除去緩存的返回速度很是快以外，緩存也有好處，就是釋放了Presto的計算能力，原先須要跑一次的查詢便不須要了。釋放出來的內存和CPU就能夠給其它的查詢提供計算能力了。

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

緩存的方案實施以後，看上去很不錯了，這時候咱們又引發了另外一次思考，緩存如今是在作第二次查詢的提速，但咱們想讓第一次的速度也能夠更快一些。說到第一次的查詢，咱們要走回老路了，咱們說空間換時間，是提高第一次查詢一個最顯而易見的辦法。

空間換時間，若是說OLAP ad-hoc查詢從事先計算好的結果裏查詢，那是否是返回速度也會很快？其次，空間換時間要支持維度建模，它也要支持Join。最後但願數據管理簡單一些，以前講到爲何淘汰了GreenPlum，是由於數據同步複雜，數據的預計算很差控制，因此但願數據管理能夠更簡單一些。預計算的過程和結果的同步不須要二次開發，最好由OLAP計算引擎本身管理。同時以前講到咱們會有一個預先設計存在過分設計的問題，這個問題怎麼解決？咱們目前的場景是有Presto來兜底的，若是沒有命中CUBE，那兜底的好處就是說咱們還能夠用Presto來承載計算，這讓設計預計算查詢的時候它的選擇餘地會更多。它不須要徹底根據用戶的需求或者業務需求把全部的設計在裏面，只要挑本身合適的就能夠，對於那些沒有命中的SQL，雖然慢了一點，但給咱們帶來的好處就是管理的成本大大下降了。

Kylin：eBay貢獻的開源MOLAP引擎

Kylin是由eBay開源的一個引擎，Kylin把數據讀出來作計算，結算的結果會被存在HBase裏，經過HBase作Ad-hoc的功能。HBase的好處是有索引的，因此作Ad-hoc的性能很是好。

爲何是Kylin

首先空間換時間，咱們在剛開始引入Kylin時跟Kylin開發聊過，他們借鑑了Oracle CUBE的概念，對傳統數據庫開發的人來講很容易理解概念和使用。支持維度建模天然支持也Join。預計算的過程是由Kylin本身管理的，也開放了API，與調度系統打通作數據刷新。另外Kylin是在eBay上很大的、美團也是投入了很大的精力的有成功經驗的產品，因此很容易地引進來了。

第4階段

因而，咱們進入了惟品會OLAP分析架構的第四階段：Hybird：Presto的ROLAP和Kylin的MOLAP結合發揮各自優點，Redis緩存進一步提高效率。

查詢在Query Engine根據Redis-> Kylin再到Presto的優先級進行路由探查，在找到第一個可命中的路徑以後，轉向對應的引擎進行計算並給用戶返回結果。Kylin的引入主要用於提高核心指標的OLAP分析的首次響應速度。這個狀態能夠看到Kylin的查詢覆蓋率平均15%，最高25%，大幅提高核心數據的查詢。同時流量幾十億、幾百億的數據從Kylin走也大大地減輕了Presto。雖說這樣的架構看起來挺複雜的，但這樣的一個架構出來以後，基本上知足了90%的OLAP分析了。

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

通過這麼長一段時間的演進和一些摸索以後，咱們以爲OLAP分析的技術是它的進化是一個迷宮，不是一個金字塔。過去說升級，像金字塔往上攀登，但實際上在剛纔的過程你們發現實際上它更是像走迷宮，每一個轉角實際上是都碰到了問題，在這個轉角，在當時的狀況下找最佳的方案。

不是作了大數據以後放棄了計算，也不是作了大數據再也不考慮數據同步的問題。其實能夠發現不少傳統數據倉庫或者RBDMS的索引、CUBE之類的概念慢慢從新回到了大數據的視野裏面。對咱們而言，咱們認爲更多的時候，咱們在作一些大數據的新技術演進時更多的是用更優秀的技術來作落地和實現，而不是去拒絕過去的一些你們感受好像比較陳舊的的邏輯或概念。因此說對每一個人來講，適合本身業務的場景方案纔是最好的方案。

 

惟品會在開源計算引擎上所作的改進

接下來說一下咱們在開源計算引擎上作的改進。Presto和Kylin的角度不同，因此咱們在優化的方向上也不一樣。Presto主要注重提高查詢性能，減小計算量，提高實時性。Kylin最主要優化維表查找，提升CUBE的利用率。

Presto上的改進

在提高查詢性能上：
新增Hint語法，首先作的也是最重要的改動是在Presto中增長了一個Hint的語法，能夠在SQL Join級別動態設置策略，經過編譯時讓讓join在replica和distribute二者之間設置，提升Join效率；
監控告警JOIN數據傾斜，經過減小數據傾斜提升執行效率；
增長多集羣LOAD BALANCE，可平衡不一樣集羣間計算量；
通過改造，Presto的查詢實時性大幅提高。

在減小計算量上：
新增Kylin Connector，經過CUBE探嗅自動匹配SQL子查詢中能夠命中Kylin CUBE的部分，從Kylin提取數據後作進一步的計算，下降查詢計算量；
通過改造，Presto升級爲Hybird OLAP引擎，同時支持ROLAP和MOLAP兩種模式。

在提升實時性上：
重寫Kafka Connector，支持熱更新Kafka中Topic、Message 和表/列的映射定義；
支持Kafka按offset讀取數據，支持PB格式，提升Kafka數據源的讀取效率；
通過改造，Presto不只是離線OLAP引擎，準實時數據處理的能力也獲得提升。

 

Kylin上的改進

在優化維表查找上：
經過引入Presto解決Kylin億級維表實時Lookup OOM的問題，經過Presto查詢替換了原有複雜的維表映射值查找機制;
通過改造，惟品會版的Kylin相比開源版本極大的擴展了對業務場景的支持程度.

在提高CUBE利用率上：
開發CUBE Advisor，經過統計分析總結合適的維度和指標組合輔助開發選擇判斷新建CUBE的策略，減小冗餘和經驗判斷上的偏差;
提供CUBE命中率監控，造成CUBE新建、使用到總結升級的閉環;
經此改造，CUBE命中率大幅提升，減小了資源的浪費提高了響應速度，通過這樣的改造，開發再也不只是根據本身的經驗或者盲目創建，而是有數據可依。
 
OLAP方案升級方向
 
最後咱們講一下OLAP升級方向。
對於Presto，咱們將探索如何用RowID級別的索引的存儲格式替換現有RowGroup級別索引的ORC File，在數據Scan級別儘量精確的獲取所需的數據，減小數據量，同時提升OLAP查詢的併發度，應對大量用戶併發OLAP分析場景。
對於Kylin，咱們會嘗試Streaming Cubing，使得Kylin OLAP分析從離線數據向實時數據遷移，以及探索Lamda Cubing，實現實時離線CUBE無縫融合。
最後，嘗試探索下一代的方案，須要有更強的實時離線融合，與更強的原始數據和彙總的數據的融合，以及更強的數據處理能力，短時間來說沒有更好的方案，但願跟你們一塊兒討論。

 

 

若是以爲本博客對您有幫助，請 贊助做者 。

轉載自：lxw的大數據田地 » 惟品會海量實時OLAP分析技術升級之路