背景

公有云是一種為用戶(hù)提供經(jīng)濟(jì)方便的計(jì)算資源的平臺(tái)。隨著云計(jì)算技術(shù)的快速發(fā)展，以及大數(shù)據(jù)查詢(xún)需求的日益增加，很多公有云的云計(jì)算應(yīng)用市場(chǎng)中，出現(xiàn)了越來(lái)越多云上 OLAP 引擎服務(wù)。為了能夠根據(jù)自己的業(yè)務(wù)需求選擇合適的 OLAP 引擎，并通過(guò)合適的配置使引擎在最佳狀態(tài)運(yùn)行，用戶(hù)需要對(duì)當(dāng)前使用的查詢(xún)引擎性能進(jìn)行評(píng)估。

當(dāng)前 OLAP 引擎性能評(píng)估框架在云上部署使用時(shí)面臨三個(gè)主要挑戰(zhàn)：

• 對(duì)云環(huán)境適應(yīng)能力弱。傳統(tǒng)性能評(píng)估框架誕生時(shí)，尚未具備云上特有的 PaaS、IaaS、SaaS 特性，也不具備對(duì)存算分離的適配支持。使用云上 OLAP 時(shí)，需要充分利用云計(jì)算特性分析 OLAP 引擎性能。
• 不具備復(fù)雜工作負(fù)載的復(fù)現(xiàn)能力。工作負(fù)載由數(shù)據(jù)集、查詢(xún)集、查詢(xún)序列組成。傳統(tǒng)的性能評(píng)估框架通常采用固定的數(shù)據(jù)集和查詢(xún)級(jí)，查詢(xún)序列也主要以線(xiàn)性序列為主。現(xiàn)代 OLAP 查詢(xún)場(chǎng)景的復(fù)雜化，對(duì)特定場(chǎng)景下的數(shù)據(jù)集和查詢(xún)集的特征刻畫(huà)、高并發(fā)復(fù)雜場(chǎng)景支持等，提出了更高的要求。
• 難以全面評(píng)估查詢(xún)性能與上云成本。傳統(tǒng)評(píng)估體系（如 TPC-H、TPC-DS）不體現(xiàn)成本因素，而在云上資源近乎無(wú)限的大環(huán)境里，不考慮成本的評(píng)估會(huì)造成很大的偏見(jiàn)，甚至得出錯(cuò)誤的結(jié)論。云計(jì)算具備自定義租用服務(wù)器規(guī)模的特性，因此云上成本是可變、可設(shè)置的，其單價(jià)也隨時(shí)間波動(dòng)。用戶(hù)既希望 OLAP 查詢(xún)能以最快的速度被執(zhí)行，又希望能盡可能節(jié)省成本，因此需要性能評(píng)估框架全面評(píng)估查詢(xún)性能與上云成本，根據(jù)用戶(hù)需求提供最具性?xún)r(jià)比的云服務(wù)器與 OLAP 引擎搭配方式。

針對(duì)上述問(wèn)題，南京大學(xué)顧榮老師、吳侗雨博士等人與 Apache Kylin 社區(qū)團(tuán)隊(duì)聯(lián)合研究，設(shè)計(jì)開(kāi)發(fā)一套云上 OLAP 引擎查詢(xún)性能評(píng)估框架，名為 Raven。

Raven 被設(shè)計(jì)來(lái)幫助用戶(hù)回答一些 OLAP 引擎上云面臨的實(shí)際而又重要的問(wèn)題：

• 對(duì)于一份真實(shí)生產(chǎn)數(shù)據(jù)中的真實(shí)工作負(fù)載（數(shù)據(jù)載入 + 查詢(xún)），哪個(gè) OLAP 引擎在云上運(yùn)行的 IT 成本更低？
• 給定一個(gè)查詢(xún)速度的目標(biāo)，在能達(dá)成的速度目標(biāo)的前提下，哪個(gè) OLAP 引擎在云上能給出更低的 IT 成本？
• 再加上考慮數(shù)據(jù)載入速度的因素，情況又會(huì)如何？

本文將介紹本團(tuán)隊(duì)在設(shè)計(jì)與實(shí)現(xiàn) Raven 時(shí)遇到的問(wèn)題、對(duì)應(yīng)的解決方案、以及當(dāng)前的初步研究成果。

適應(yīng)云架構(gòu)的性能評(píng)估框架設(shè)計(jì)

OLAP 引擎查詢(xún)性能評(píng)估框架適配云架構(gòu)時(shí)，實(shí)際上是在適配云上的 PaaS、IaaS、SaaS 特性。具體而言，云服務(wù)器的很多功能都以服務(wù)的方式呈現(xiàn)給用戶(hù)，用戶(hù)只需要調(diào)用對(duì)應(yīng)服務(wù)的接口，即可實(shí)現(xiàn)不同的目的，如云服務(wù)器創(chuàng)建、文件操作、性能指標(biāo)獲取、應(yīng)用程序執(zhí)行等。在文件操作中，由于云服務(wù)器采用計(jì)算存儲(chǔ)分離的架構(gòu)，一些數(shù)據(jù)可能需要通過(guò)服務(wù)從遠(yuǎn)程的云存儲(chǔ)服務(wù)上拉取。

圖 1：基于公有云平臺(tái)的 Raven 性能評(píng)估框架

結(jié)合上述需求，Raven 的框架如圖 1 所示。其執(zhí)行步驟如下：

1. 用戶(hù)輸入性能測(cè)試配置信息，觸發(fā)性能測(cè)試啟動(dòng)模塊，該模塊負(fù)責(zé)根據(jù)用戶(hù)配置創(chuàng)建啟動(dòng)云上 OLAP 性能測(cè)試所需的云服務(wù)器和計(jì)算環(huán)境。
2. 性能測(cè)試啟動(dòng)模塊將工作負(fù)載、數(shù)據(jù)集、性能指標(biāo)、引擎參數(shù)等信息傳遞給配置控制與分發(fā)模塊，該模塊負(fù)責(zé)將上述信息分發(fā)到對(duì)應(yīng)的服務(wù)接口或模塊上。
3. 配置控制與分發(fā)模塊觸發(fā)工作負(fù)載執(zhí)行模塊，工作負(fù)載執(zhí)行模塊啟動(dòng)配置好的 OLAP 引擎，并根據(jù)工作負(fù)載設(shè)置隨時(shí)間向 OLAP 引擎發(fā)送查詢(xún)請(qǐng)求。
4. OLAP 引擎向本地存儲(chǔ)或云存儲(chǔ)拉取數(shù)據(jù)集，執(zhí)行查詢(xún)。查詢(xún)執(zhí)行過(guò)程中，工作負(fù)載執(zhí)行模塊記錄查詢(xún)開(kāi)始和結(jié)束的時(shí)間戳，并啟動(dòng)資源管理服務(wù)，監(jiān)控 OLAP 引擎查詢(xún)期間的性能指標(biāo)。查詢(xún)結(jié)束時(shí)，工作負(fù)載執(zhí)行模塊將時(shí)間戳和性能指標(biāo)信息輸出到云存儲(chǔ)中。
5. 啟動(dòng)性能分析評(píng)分模塊，從遠(yuǎn)程云存儲(chǔ)中拉取時(shí)間戳和性能指標(biāo)信息，導(dǎo)入用戶(hù)自定義的評(píng)分模型，得到最終的性能評(píng)估結(jié)果。

上述設(shè)計(jì)的優(yōu)點(diǎn)在于：

• 充分利用可自定義的云服務(wù)器數(shù)量和配置，允許用戶(hù)自定義其希望創(chuàng)建的集群環(huán)境。
• 支持向遠(yuǎn)程的云存儲(chǔ)服務(wù)讀寫(xiě)數(shù)據(jù)，適應(yīng)云環(huán)境的存算分離架構(gòu)。
• 使用云服務(wù)提供商的資源管理服務(wù)，得以獲取大量系統(tǒng)資源使用狀況的信息。
• 支持可插拔的引擎接口，用戶(hù)可任意指定其所需測(cè)試的 OLAP 引擎及其配置。

實(shí)際使用時(shí)，用戶(hù)的輸入以一個(gè).yaml 文件呈現(xiàn)，可仿照如下格式：

• engine: kylin
• workload: tpc-h
• test_plan: one-pass
• metrics: all

用戶(hù)需要的云服務(wù)器數(shù)量、每臺(tái)機(jī)器的配置、不同的引擎等，均可通過(guò) JSON 文件配置。

基于事件和時(shí)間戳的工作負(fù)載設(shè)計(jì)

傳統(tǒng)的 OLAP 查詢(xún)引擎通常采用固定的數(shù)據(jù)集和查詢(xún)集，并執(zhí)行一系列的查詢(xún)，查看 OLAP 引擎的查詢(xún)性能。然而，當(dāng)前很多行業(yè)的工作負(fù)載正更加復(fù)雜。

• 越來(lái)越多的企業(yè)意識(shí)到自身數(shù)據(jù)及業(yè)務(wù)具有鮮明特征，希望能夠在給定的數(shù)據(jù)特征下獲得最佳的 OLAP 查詢(xún)方案。
• 除了傳統(tǒng)的 OLAP 查詢(xún)外，越來(lái)越多的預(yù)計(jì)算技術(shù)，如 ETL、索引、Kylin 的 Cube 等，亟待納入到 OLAP 引擎性能的考察中。
• 數(shù)據(jù)量的快速增長(zhǎng)使得高并發(fā)查詢(xún)、QPS 可變查詢(xún)的場(chǎng)景越來(lái)越多，傳統(tǒng)的線(xiàn)性查詢(xún)方法很難上述新場(chǎng)景進(jìn)行準(zhǔn)確評(píng)估。

Raven 使用了一種基于時(shí)間線(xiàn)的事件機(jī)制描述復(fù)雜的 OLAP 工作場(chǎng)景。該機(jī)制下，一個(gè)工作負(fù)載由多個(gè)階段構(gòu)成，一個(gè)階段由多個(gè)事件構(gòu)成。在時(shí)間線(xiàn)上，一個(gè)工作負(fù)載被描述為若干個(gè)階段的順序執(zhí)行。每個(gè)階段分為線(xiàn)上階段和線(xiàn)下階段兩種：線(xiàn)上階段執(zhí)行實(shí)際的查詢(xún)請(qǐng)求，線(xiàn)下階段執(zhí)行預(yù)計(jì)算等操作。事件是對(duì)工作負(fù)載中每一個(gè)原子執(zhí)行單元的抽象，可以是查詢(xún)請(qǐng)求、shell 命令，或用 Python 等編程語(yǔ)言編寫(xiě)的腳本。

圖 2：Raven 工作負(fù)載的執(zhí)行過(guò)程

Raven 的工作負(fù)載如圖 2 所示。其執(zhí)行步驟如下：

1. 啟動(dòng)第一個(gè)階段，加載工作負(fù)載配置、引擎配置等；
2. 當(dāng)事件的計(jì)時(shí)器被觸發(fā)時(shí)，將時(shí)間事件生成控制器，讀取該事件對(duì)應(yīng)的查詢(xún)語(yǔ)句或腳本內(nèi)容，進(jìn)入事件執(zhí)行隊(duì)列，等待執(zhí)行。
3. 出事件執(zhí)行隊(duì)列后，進(jìn)入事件執(zhí)行控制器，開(kāi)啟線(xiàn)程執(zhí)行鉤子函數(shù)，與 OLAP 引擎或命令行執(zhí)行交互操作，并等待響應(yīng)，得到響應(yīng)后將事件插入到資源收集隊(duì)列中。
4. 出資源收集隊(duì)列后，進(jìn)入事件資源收集控制器，將操作的時(shí)間戳信息輸出到云存儲(chǔ)服務(wù)上。
5. 當(dāng)該階段內(nèi)所有時(shí)間完成后，啟動(dòng)下一個(gè)階段，然后按順序執(zhí)行每個(gè)階段，直到整個(gè)工作負(fù)載結(jié)束。

上述設(shè)計(jì)的優(yōu)點(diǎn)在于：

• 支持自定義數(shù)據(jù)集和查詢(xún)集，允許用戶(hù)充分利用其業(yè)務(wù)特點(diǎn)進(jìn)行性能評(píng)估。
• 支持預(yù)計(jì)算，允許用戶(hù)評(píng)估預(yù)計(jì)算和實(shí)際查詢(xún)的整體性能。
• 帶時(shí)間戳的執(zhí)行方法和線(xiàn)程管理策略，支持高并發(fā)查詢(xún)，允許模擬 QPS 隨時(shí)間波動(dòng)的工作負(fù)載。

舉個(gè)例子，可以使用如下的 .yaml 配置文件，在 AWS 上啟動(dòng)一主四從的 EC2 集群，并部署 Presto 引擎，指定數(shù)據(jù)集為 SSB（SF=100）且工作負(fù)載滿(mǎn)足泊松分布（λ=3.0），工作負(fù)載持續(xù)時(shí)間為 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 預(yù)置了一些常見(jiàn)工作負(fù)載供用戶(hù)使用，如均勻分布、突發(fā)高并發(fā)分布等。

基于自定義多元函數(shù)的性能評(píng)估模型

在性能評(píng)估方面，云上機(jī)器的一個(gè)特點(diǎn)是大小、配置可自定義調(diào)節(jié)。因此，如果只考慮查詢(xún)性能，理論上可以通過(guò)租用大量的高性能設(shè)備提升性能。但是，這樣也會(huì)造成云上計(jì)算成本飆升。因此，需要一套機(jī)制實(shí)現(xiàn)性能和成本的平衡和綜合考慮。

Raven 的性能評(píng)估方法是高度自定義的，允許用戶(hù)根據(jù)可以獲取的參數(shù)指標(biāo)，使用函數(shù)表達(dá)式組合起來(lái)，得到一個(gè)評(píng)估分?jǐn)?shù)。

Raven 中可獲取的參數(shù)指標(biāo)主要有以下幾類(lèi)：

• 查詢(xún)質(zhì)量指標(biāo)：包括所有查詢(xún)的總查詢(xún)時(shí)間、平均查詢(xún)時(shí)間、查詢(xún)時(shí)間 95% 分位數(shù)、最大查詢(xún)時(shí)間；
• 資源使用效率：內(nèi)存和 CPU 的平均使用率、負(fù)載均衡、資源占用率超過(guò) 90% 的時(shí)間占總時(shí)間的比例；
• 云上金錢(qián)成本：可直接通過(guò)云服務(wù)商提供的應(yīng)用服務(wù)獲取，主要包含四個(gè)部分的開(kāi)銷(xiāo)：存儲(chǔ)、計(jì)算、服務(wù)調(diào)用、網(wǎng)絡(luò)傳輸。

Raven 給出的評(píng)分是相對(duì)的，只能在相同模型的評(píng)分之間進(jìn)行比較。性能評(píng)估得分是云上成本和云上開(kāi)銷(xiāo)的乘積，評(píng)分越低，OLAP 引擎的性能越好。云上開(kāi)銷(xiāo)可使用線(xiàn)性模型，對(duì)上述參數(shù)賦予權(quán)重計(jì)算；也可使用非線(xiàn)性模型，將上述參數(shù)代入到一個(gè)函數(shù)表達(dá)式中。

Raven 也為用戶(hù)提供了一系列模板函數(shù)：

• 綜合模型：PTO=10×ln(PoC×(ravg+qavg))PTO=10×ln?(PoC×(ravg+qavg)).
• 速度優(yōu)先模型：PTO=10×ln(ravg+qavg)PTO=10×ln?(ravg+qavg)
• 預(yù)算優(yōu)先模型：PTO=11+e8(b?PoC)×(ravg+qavg)PTO=11+e8(b?PoC)×(ravg+qavg)
• 查詢(xún)效率模型：PTO=PoC×qmax+5q95%+94qavg100PTO=PoC×qmax+5q95%+94qavg100
• 查詢(xún)阻塞模型：PTO=PoC×ln(rmax )PTO=PoC×ln?(rmax ) 

其中，PTO 表示性能評(píng)分，PoC 表示云上成本，ravgravg、qavgqavg 分別表示平均響應(yīng)時(shí)間和平均執(zhí)行時(shí)間，rmaxrmax、qmaxqmax 分別表示最大響應(yīng)時(shí)間和最大執(zhí)行時(shí)間，b 表示預(yù)算金額，q95%q95% 表示查詢(xún)時(shí)間 95% 分位數(shù)。這里我們結(jié)合回顧下前文提出用戶(hù)需要關(guān)注的幾個(gè)際問(wèn)題，不難看出，預(yù)算優(yōu)先模型主要用于評(píng)估和回答：哪個(gè) OLAP 引擎在云上運(yùn)行的 IT 成本更低？速度優(yōu)先模型、查詢(xún)效率模型、查詢(xún)阻塞模型主要用于評(píng)估和回答：在滿(mǎn)足不同查詢(xún)響應(yīng)等約束的情況下，哪個(gè) OLAP 引擎的云上運(yùn)行成本更低？綜合模型則是通過(guò)設(shè)置不同權(quán)重來(lái)綜合考慮成本預(yù)算和查詢(xún)響應(yīng)效率的評(píng)估 OLAP 引擎的云上性能模型。

實(shí)現(xiàn)與效果驗(yàn)證

我們?cè)趤嗰R遜 AWS 上實(shí)現(xiàn)了 Raven 的上述設(shè)計(jì)，并使用該性能評(píng)估框架執(zhí)行 OLAP 引擎，查看不同引擎的查詢(xún)效果。

圖 3：不同引擎在不同評(píng)分模型下，運(yùn)行均勻查詢(xún) 10 分鐘的性能評(píng)分

圖 4：在 Presto 和 Kylin 上運(yùn)行突發(fā)高并發(fā)分布的性能評(píng)分

從圖 3 中可以看出，運(yùn)行均勻查詢(xún)時(shí)，Athena 和 Kylin 是較好的解決方案。但是，使用不同模型會(huì)得到不同的評(píng)估結(jié)論。當(dāng)綜合考慮查詢(xún)速度的云上成本時(shí)，由于 Athena 直接通過(guò)調(diào)用服務(wù)執(zhí)行查詢(xún)，因此云上成本較低，評(píng)分也更低。但是，當(dāng)優(yōu)先考慮速度時(shí)，由于 Kylin 使用預(yù)計(jì)算技術(shù)實(shí)現(xiàn)了高速查詢(xún)，因此使用速度優(yōu)先模型時(shí)，Kylin 的評(píng)分更低。

從圖 4 可以看出，運(yùn)行突發(fā)高并發(fā)分布時(shí)，若采用查詢(xún)阻塞模型，隨著同時(shí)輸入的查詢(xún)數(shù)量增加，Presto 的性能評(píng)分隨查詢(xún)數(shù)量增加線(xiàn)性增長(zhǎng)；但是，Kylin 并未受到查詢(xún)數(shù)量增加的影響，性能評(píng)分保持穩(wěn)定。這是因?yàn)?Kylin 的預(yù)計(jì)算技術(shù)提升了計(jì)算效率，當(dāng)查詢(xún)大量涌入時(shí)，Kylin 能以更高的效率處理這些查詢(xún)，減少查詢(xún)?cè)陉?duì)列中的阻塞，使性能評(píng)分更為出色。當(dāng)然，如果用戶(hù)集中的查詢(xún)數(shù)量不大，Presto 的性能評(píng)分更有優(yōu)勢(shì)，因?yàn)槠錄](méi)有預(yù)計(jì)算的相關(guān)開(kāi)銷(xiāo)。

未來(lái)展望

未來(lái)的研究主要考慮以下方面：

• 應(yīng)用實(shí)現(xiàn)更多引擎，嘗試兼容云原生引擎，以進(jìn)行性能評(píng)估。
• 優(yōu)化工作負(fù)載的表達(dá)形式，使用戶(hù)可以根據(jù)自己的業(yè)務(wù)需求，更容易地開(kāi)發(fā)出多樣化、具代表性的工作負(fù)載。
• 形成更多標(biāo)準(zhǔn)化的評(píng)分模型，供不同工作負(fù)載之間的橫向?qū)Ρ取?/li>
• 結(jié)合當(dāng)前評(píng)分結(jié)果，進(jìn)一步分析不同 OLAP 引擎的性能優(yōu)劣。