雲上OLAP引擎查詢效能評估框架:設計與實現

語言: CN / TW / HK

作者:南京大學顧榮吳侗雨

背景

公有云是一種為使用者提供經濟方便的計算資源的平臺。隨著雲端計算技術的快速發展,以及大資料查詢需求的日益增加,很多公有云的雲端計算應用市場中,出現了越來越多雲上OLAP引擎服務。為了能夠根據自己的業務需求選擇合適的OLAP引擎,並通過合適的配置使引擎在最佳狀態執行,使用者需要對當前使用的查詢引擎效能進行評估。

當前OLAP引擎效能評估框架在雲上部署使用時面臨三個主要挑戰:

1、對雲環境適應能力弱。傳統效能評估框架誕生時,尚未具備雲上特有的PaaS、IaaS、SaaS特性,也不具備對存算分離的適配支援。使用雲上OLAP時,需要充分利用雲端計算特性分析OLAP引擎效能。

2、不具備複雜工作負載的復現能力。工作負載由資料集、查詢集、查詢序列組成。傳統的效能評估框架通常採用固定的資料集和查詢級,查詢序列也主要以線性序列為主。現代OLAP查詢場景的複雜化,對特定場景下的資料集和查詢集的特徵刻畫、高併發複雜場景支援等,提出了更高的要求。

3、難以全面評估查詢效能與上雲成本。傳統評估體系(如 TPC-H、TPC-DS)不體現成本因素,而在雲上資源近乎無限的大環境裡,不考慮成本的評估會造成很大的偏見,甚至得出錯誤的結論。雲端計算具備自定義租用伺服器規模的特性,因此雲上成本是可變、可設定的,其單價也隨時間波動。使用者既希望OLAP查詢能以最快的速度被執行,又希望能儘可能節省成本,因此需要效能評估框架全面評估查詢效能與上雲成本,根據使用者需求提供最具價效比的雲伺服器與OLAP引擎搭配方式。

針對上述問題,南京大學顧榮老師、吳侗雨博士等人與Apache Kylin社群團隊聯合研究,設計開發一套雲上OLAP引擎查詢效能評估框架,名為Raven。

Raven被設計來幫助使用者回答一些OLAP引擎上雲面臨的實際而又重要的問題:

  • 對於一份真實生產資料中的真實工作負載(資料載入+查詢),哪個OLAP引擎在雲上執行的IT成本更低?
  • 給定一個查詢速度的目標,在能達成的速度目標的前提下,哪個OLAP引擎在雲上能給出更低的IT成本?
  • 再加上考慮資料載入速度的因素,情況又會如何?

本文將介紹本團隊在設計與實現Raven時遇到的問題、對應的解決方案、以及當前的初步研究成果。

適應雲架構的效能評估框架設計

OLAP引擎查詢效能評估框架適配雲架構時,實際上是在適配雲上的PaaS、IaaS、SaaS特性。具體而言,雲伺服器的很多功能都以服務的方式呈現給使用者,使用者只需要呼叫對應服務的介面,即可實現不同的目的,如雲伺服器建立、檔案操作、效能指標獲取、應用程式執行等。在檔案操作中,由於雲伺服器採用計算儲存分離的架構,一些資料可能需要通過服務從遠端的雲端儲存服務上拉取。

圖1:基於公有云平臺的Raven效能評估框架

結合上述需求,Raven的框架如圖1所示。其執行步驟如下:

1、使用者輸入效能測試配置資訊,觸發效能測試啟動模組,該模組負責根據使用者配置建立啟動雲上OLAP效能測試所需的雲伺服器和計算環境。

2、效能測試啟動模組將工作負載、資料集、效能指標、引擎引數等資訊傳遞給配置控制與分發模組,該模組負責將上述資訊分發到對應的服務介面或模組上。

3、配置控制與分發模組觸發工作負載執行模組,工作負載執行模組啟動配置好的OLAP引擎,並根據工作負載設定隨時間向OLAP引擎傳送查詢請求。

4、OLAP引擎向本地儲存或雲端儲存拉取資料集,執行查詢。查詢執行過程中,工作負載執行模組記錄查詢開始和結束的時間戳,並啟動資源管理服務,監控OLAP引擎查詢期間的效能指標。查詢結束時,工作負載執行模組將時間戳和效能指標資訊輸出到雲端儲存中。

5、啟動效能分析評分模組,從遠端雲端儲存中拉取時間戳和效能指標資訊,匯入使用者自定義的評分模型,得到最終的效能評估結果。

上述設計的優點在於:

1、 充分利用可自定義的雲伺服器數量和配置,允許使用者自定義其希望建立的叢集環境。

2、支援向遠端的雲端儲存服務讀寫資料,適應雲環境的存算分離架構。

3、使用雲服務提供商的資源管理服務,得以獲取大量系統資源使用狀況的資訊。

4、支援可插拔的引擎介面,使用者可任意指定其所需測試的OLAP引擎及其配置。

實際使用時,使用者的輸入以一個.yaml檔案呈現,可仿照如下格式:

engine: kylin

workload: tpc-h

test_plan: one-pass

metrics: all

使用者需要的雲伺服器數量、每臺機器的配置、不同的引擎等,均可通過JSON檔案配置。

基於事件和時間戳的工作負載設計

傳統的OLAP查詢引擎通常採用固定的資料集和查詢集,並執行一系列的查詢,檢視OLAP引擎的查詢效能。然而,當前很多行業的工作負載正更加複雜。

1、越來越多的企業意識到自身資料及業務具有鮮明特徵,希望能夠在給定的資料特徵下獲得最佳的OLAP查詢方案。

2、除了傳統的OLAP查詢外,越來越多的預計算技術,如ETL、索引、Kylin的Cube等,亟待納入到OLAP引擎效能的考察中。

3、資料量的快速增長使得高併發查詢、QPS可變查詢的場景越來越多,傳統的線性查詢方法很難上述新場景進行準確評估。

Raven使用了一種基於時間線的事件機制描述複雜的OLAP工作場景。該機制下,一個工作負載由多個階段構成,一個階段由多個事件構成。在時間線上,一個工作負載被描述為若干個階段的順序執行。每個階段分為線上階段和線下階段兩種:線上階段執行實際的查詢請求,線下階段執行預計算等操作。事件是對工作負載中每一個原子執行單元的抽象,可以是查詢請求、shell命令,或用Python等程式語言編寫的指令碼。

圖2:Raven工作負載的執行過程

Raven的工作負載如圖2所示。其執行步驟如下:

1、啟動第一個階段,載入工作負載配置、引擎配置等;

2、當事件的計時器被觸發時,將時間事件生成控制器,讀取該事件對應的查詢語句或指令碼內容,進入事件執行佇列,等待執行。

3、出事件執行佇列後,進入事件執行控制器,開啟執行緒執行鉤子函式,與OLAP引擎或命令列執行互動操作,並等待響應,得到響應後將事件插入到資源收集佇列中。

4、出資源收集佇列後,進入事件資源收集控制器,將操作的時間戳資訊輸出到雲端儲存服務上。

5、當該階段內所有時間完成後,啟動下一個階段,然後按順序執行每個階段,直到整個工作負載結束。

上述設計的優點在於:

1、支援自定義資料集和查詢集,允許使用者充分利用其業務特點進行效能評估。

2、支援預計算,允許使用者評估預計算和實際查詢的整體效能。

3、帶時間戳的執行方法和執行緒管理策略,支援高併發查詢,允許模擬QPS隨時間波動的工作負載。

舉個例子,可以使用如下的 .yaml 配置檔案,在 AWS 上啟動一主四從的 EC2 叢集,並部署 Presto 引擎,指定資料集為 SSB(SF=100)且工作負載滿足泊松分佈(λ=3.0),工作負載持續時間為 600 秒:

Cloud:

Name: AWS

Description: Amazon Web Service.

Properties:

Region: ap-southeast-1

Ec2KeyName: key_raven

MasterInstaceCount: 1

MasterInstanceType: m5.xlarge

CoreInstanceCount: 4

CoreInstanceType: m5.4xlarge

Engine:

Name: presto

Description: Presto.

Properties:

host: localhost

port: 8080

user: hive

catalog: hive

concurrency: 1

Testplan:

Name: Timeline template.

Properties:

Type: Timeline

Path: config/testplan/template/timeline_template.yaml

Workload:

Name: SSB

Type: QPS

Parameters:

database: ssb_100

distribution: poisson

duration: 600

lam: 3.0

Raven預置了一些常見工作負載供使用者使用,如均勻分佈、突發高併發分佈等。

基於自定義多元函式的效能評估模型

在效能評估方面,雲上機器的一個特點是大小、配置可自定義調節。因此,如果只考慮查詢效能,理論上可以通過租用大量的高效能裝置提升效能。但是,這樣也會造成雲上計算成本飆升。因此,需要一套機制實現效能和成本的平衡和綜合考慮。

Raven的效能評估方法是高度自定義的,允許使用者根據可以獲取的引數指標,使用函式表示式組合起來,得到一個評估分數。

Raven中可獲取的引數指標主要有以下幾類:

1、查詢質量指標:包括所有查詢的總查詢時間、平均查詢時間、查詢時間95%分位數、最大查詢時間;

2、資源使用效率:記憶體和CPU的平均使用率、負載均衡、資源佔用率超過90%的時間佔總時間的比例;

3、雲上金錢成本:可直接通過雲服務商提供的應用服務獲取,主要包含四個部分的開銷:儲存、計算、服務呼叫、網路傳輸。

Raven給出的評分是相對的,只能在相同模型的評分之間進行比較。效能評估得分是雲上成本和雲上開銷的乘積,評分越低,OLAP引擎的效能越好。雲上開銷可使用線性模型,對上述引數賦予權重計算;也可使用非線性模型,將上述引數代入到一個函式表示式中。

Raven也為使用者提供了一系列模板函式:

1、綜合模型:\(P T O=10 \times \ln \left(P o C \times\left(r_{a v g}+q_{a v g}\right)\right)\).

2、速度優先模型:\(P T O=10 \times \ln \left(r_{a v g}+q_{a v g}\right) \)

3、預算優先模型:\(P T O=\frac{1}{1+e^{8(b-P o C)}} \times\left(r_{a v g}+q_{a v g}\right) \)

4、查詢效率模型:\(P T O=P o C \times \frac{q_{\max }+5 q_{95 \%}+94 q_{a v g}}{100}\)

5、查詢阻塞模型:\(P T O=P o C \times \ln \left(r_{\text {max }}\right) \) 

其中,PTO表示效能評分,PoC表示雲上成本,\(r_{avg}\)\(q_{avg}\)分別表示平均響應時間和平均執行時間,\(r_{max}\)\( q_{max}\)分別表示最大響應時間和最大執行時間,b表示預算金額,\(q_{95\%}\)表示查詢時間95%分位數。這裡我們結合回顧下前文提出使用者需要關注的幾個際問題,不難看出,預算優先模型主要用於評估和回答:哪個 OLAP引擎在雲上執行的IT成本更低?速度優先模型、查詢效率模型、查詢阻塞模型主要用於評估和回答:在滿足不同查詢響應等約束的情況下,哪個OLAP引擎的雲上執行成本更低?綜合模型則是通過設定不同權重來綜合考慮成本預算和查詢響應效率的評估OLAP引擎的雲上效能模型。

實現與效果驗證

我們在亞馬遜AWS上實現了Raven的上述設計,並使用該效能評估框架執行OLAP引擎,檢視不同引擎的查詢效果。

圖3:不同引擎在不同評分模型下,執行均勻查詢10分鐘的效能評分

圖4:在Presto和Kylin上執行突發高併發分佈的效能評分

從圖3中可以看出,執行均勻查詢時,Athena和Kylin是較好的解決方案。但是,使用不同模型會得到不同的評估結論。當綜合考慮查詢速度的雲上成本時,由於Athena直接通過呼叫服務執行查詢,因此雲上成本較低,評分也更低。但是,當優先考慮速度時,由於Kylin使用預計算技術實現了高速查詢,因此使用速度優先模型時,Kylin的評分更低。

從圖4可以看出,執行突發高併發分佈時,若採用查詢阻塞模型,隨著同時輸入的查詢數量增加,Presto的效能評分隨查詢數量增加線性增長;但是,Kylin並未受到查詢數量增加的影響,效能評分保持穩定。這是因為Kylin的預計算技術提升了計算效率,當查詢大量湧入時,Kylin能以更高的效率處理這些查詢,減少查詢在佇列中的阻塞,使效能評分更為出色。當然,如果使用者集中的查詢數量不大,Presto的效能評分更有優勢,因為其沒有預計算的相關開銷。

未來展望

未來的研究主要考慮以下方面:

1、應用實現更多引擎,嘗試相容雲原生引擎,以進行效能評估。

2、優化工作負載的表達形式,使使用者可以根據自己的業務需求,更容易地開發出多樣化、具代表性的工作負載。

3、形成更多標準化的評分模型,供不同工作負載之間的橫向對比。

4、結合當前評分結果,進一步分析不同OLAP引擎的效能優劣。