自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

云上 OLAP 引擎查詢性能評(píng)估框架:設(shè)計(jì)與實(shí)現(xiàn)

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

背景

公有云是一種為用戶提供經(jīng)濟(jì)方便的計(jì)算資源的平臺(tái)。隨著云計(jì)算技術(shù)的快速發(fā)展,以及大數(shù)據(jù)查詢需求的日益增加,很多公有云的云計(jì)算應(yīng)用市場(chǎng)中,出現(xiàn)了越來越多云上 OLAP 引擎服務(wù)。為了能夠根據(jù)自己的業(yè)務(wù)需求選擇合適的 OLAP 引擎,并通過合適的配置使引擎在最佳狀態(tài)運(yùn)行,用戶需要對(duì)當(dāng)前使用的查詢引擎性能進(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ù)集、查詢集、查詢序列組成。傳統(tǒng)的性能評(píng)估框架通常采用固定的數(shù)據(jù)集和查詢級(jí),查詢序列也主要以線性序列為主?,F(xiàn)代 OLAP 查詢場(chǎng)景的復(fù)雜化,對(duì)特定場(chǎng)景下的數(shù)據(jù)集和查詢集的特征刻畫、高并發(fā)復(fù)雜場(chǎng)景支持等,提出了更高的要求。
  • 難以全面評(píng)估查詢性能與上云成本。傳統(tǒng)評(píng)估體系(如 TPC-H、TPC-DS)不體現(xiàn)成本因素,而在云上資源近乎無限的大環(huán)境里,不考慮成本的評(píng)估會(huì)造成很大的偏見,甚至得出錯(cuò)誤的結(jié)論。云計(jì)算具備自定義租用服務(wù)器規(guī)模的特性,因此云上成本是可變、可設(shè)置的,其單價(jià)也隨時(shí)間波動(dòng)。用戶既希望 OLAP 查詢能以最快的速度被執(zhí)行,又希望能盡可能節(jié)省成本,因此需要性能評(píng)估框架全面評(píng)估查詢性能與上云成本,根據(jù)用戶需求提供最具性價(jià)比的云服務(wù)器與 OLAP 引擎搭配方式。

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

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

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

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

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

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

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

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

  1. 用戶輸入性能測(cè)試配置信息,觸發(fā)性能測(cè)試啟動(dòng)模塊,該模塊負(fù)責(zé)根據(jù)用戶配置創(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ā)送查詢請(qǐng)求。
  4. OLAP 引擎向本地存儲(chǔ)或云存儲(chǔ)拉取數(shù)據(jù)集,執(zhí)行查詢。查詢執(zhí)行過程中,工作負(fù)載執(zhí)行模塊記錄查詢開始和結(jié)束的時(shí)間戳,并啟動(dòng)資源管理服務(wù),監(jiān)控 OLAP 引擎查詢期間的性能指標(biāo)。查詢結(jié)束時(shí),工作負(fù)載執(zhí)行模塊將時(shí)間戳和性能指標(biāo)信息輸出到云存儲(chǔ)中。
  5. 啟動(dòng)性能分析評(píng)分模塊,從遠(yuǎn)程云存儲(chǔ)中拉取時(shí)間戳和性能指標(biāo)信息,導(dǎo)入用戶自定義的評(píng)分模型,得到最終的性能評(píng)估結(jié)果。

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

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

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

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

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

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

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

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

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

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

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

  1. 啟動(dòng)第一個(gè)階段,加載工作負(fù)載配置、引擎配置等;
  2. 當(dāng)事件的計(jì)時(shí)器被觸發(fā)時(shí),將時(shí)間事件生成控制器,讀取該事件對(duì)應(yīng)的查詢語句或腳本內(nèi)容,進(jìn)入事件執(zhí)行隊(duì)列,等待執(zhí)行。
  3. 出事件執(zhí)行隊(duì)列后,進(jìn)入事件執(zhí)行控制器,開啟線程執(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ù)集和查詢集,允許用戶充分利用其業(yè)務(wù)特點(diǎn)進(jìn)行性能評(píng)估。
  • 支持預(yù)計(jì)算,允許用戶評(píng)估預(yù)計(jì)算和實(shí)際查詢的整體性能。
  • 帶時(shí)間戳的執(zhí)行方法和線程管理策略,支持高并發(fā)查詢,允許模擬 QPS 隨時(shí)間波動(dòng)的工作負(fù)載。

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

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

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

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

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

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

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

Raven 也為用戶提供了一系列模板函數(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)
  • 查詢效率模型:PTO=PoC×qmax+5q95%+94qavg100PTO=PoC×qmax+5q95%+94qavg100
  • 查詢阻塞模型: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% 表示查詢時(shí)間 95% 分位數(shù)。這里我們結(jié)合回顧下前文提出用戶需要關(guān)注的幾個(gè)際問題,不難看出,預(yù)算優(yōu)先模型主要用于評(píng)估和回答:哪個(gè) OLAP 引擎在云上運(yùn)行的 IT 成本更低?速度優(yōu)先模型、查詢效率模型、查詢阻塞模型主要用于評(píng)估和回答:在滿足不同查詢響應(yīng)等約束的情況下,哪個(gè) OLAP 引擎的云上運(yùn)行成本更低?綜合模型則是通過設(shè)置不同權(quán)重來綜合考慮成本預(yù)算和查詢響應(yīng)效率的評(píng)估 OLAP 引擎的云上性能模型。

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

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

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

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

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

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

未來展望

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

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

2024-02-26 07:43:10

大語言模型LLM推理框架

2010-04-02 17:35:21

云計(jì)算

2020-06-11 08:56:34

數(shù)據(jù)倉(cāng)庫(kù)數(shù)據(jù)庫(kù)數(shù)據(jù)

2022-09-12 07:17:20

redis命令redissynce

2017-03-15 15:45:33

MySQL存儲(chǔ)引擎設(shè)計(jì)與實(shí)現(xiàn)

2010-11-23 11:27:53

MySQL MyISA

2012-10-24 14:52:19

IBMdw

2010-09-08 11:26:02

2024-04-03 10:05:00

LLM性能基準(zhǔn)測(cè)試

2010-02-26 13:14:39

Java日志系統(tǒng)

2016-11-07 18:26:39

IT可視化

2009-11-23 15:41:44

Visual Stud

2012-04-13 10:00:04

LINQ

2017-04-27 10:07:52

框架設(shè)計(jì)實(shí)現(xiàn)

2023-02-28 11:06:59

亞馬遜云科技MarvellEDA

2023-01-05 09:33:38

低代碼高性能引擎

2022-04-03 15:44:55

Vue.js框架設(shè)計(jì)設(shè)計(jì)與實(shí)現(xiàn)
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)