一種面向分布式數(shù)據(jù)庫的多并發(fā)OLAP型查詢性能預(yù)測方法

劉驥超，杜建華，謝寒生，劉霄燕，謝召干

(1.海南省氣象信息中心，海口 570203；2.海南省南海氣象防災(zāi)減災(zāi)重點(diǎn)實(shí)驗(yàn)室，海口 570203；3.海南省澄邁縣氣象局，海南 澄邁 571900)

0 引言

數(shù)據(jù)庫中并行執(zhí)行查詢能夠帶來許多優(yōu)勢。例如，它能夠縮短多個(gè)查詢的整體運(yùn)行時(shí)間并且提高硬件的利用率，但是，對于并發(fā)查詢中的某一個(gè)查詢，相較于其單獨(dú)執(zhí)行，它的執(zhí)行時(shí)間可能會(huì)延長或縮短。主要原因是多個(gè)查詢之間相互影響[1]，有些查詢能夠促進(jìn)該查詢的執(zhí)行，有些則由于與該查詢存在資源競爭而延長查詢執(zhí)行。

并發(fā)查詢性能預(yù)測對于查詢調(diào)度控制[2-6]等具有很大的應(yīng)用價(jià)值，例如，如果事先能夠知道查詢執(zhí)行時(shí)間，那么就可以改變多個(gè)查詢的順序，繼而達(dá)到用戶SLA要求。準(zhǔn)確的查詢性能預(yù)測技術(shù)還能夠用于查詢進(jìn)度顯示[7]，以便了解當(dāng)前查詢的執(zhí)行進(jìn)度，然后DBA就可以做下一步的決策，等待該查詢執(zhí)行完畢或殺死該查詢。查詢性能預(yù)測還對查詢優(yōu)化器具有一定的指導(dǎo)作用，比如：查詢優(yōu)化器可以更好地創(chuàng)建并發(fā)查詢感知的查詢計(jì)劃，以此來縮短查詢的整體執(zhí)行時(shí)間。

由于查詢性能預(yù)測技術(shù)具有很大價(jià)值，所以，針對該方面有很多研究，這些研究主要面向兩類查詢，一是OLTP型查詢[8]，OLTP主要指在關(guān)系型數(shù)據(jù)庫中一些對時(shí)間要求比較高的事務(wù)型查詢，通常該類查詢的執(zhí)行時(shí)間較短；二是OLAP型查詢[9]，OLAP型查詢主要運(yùn)用于數(shù)據(jù)倉庫，這種類型的查詢面對的數(shù)據(jù)量比較大，執(zhí)行時(shí)間比較長。本文主要面向OLAP型查詢。當(dāng)前已經(jīng)有一些技術(shù)能夠?qū)Ψ治鲂筒樵冏鲂阅茴A(yù)測[10]，但這些技術(shù)在實(shí)用性和擴(kuò)展性方面存在一定的局限。

本文提出了一種能夠量化多個(gè)查詢之間的資源競爭并根據(jù)資源競爭情況預(yù)測并發(fā)查詢的延遲時(shí)間的方法。在現(xiàn)實(shí)情況中，同一個(gè)查詢在不同的并發(fā)查詢組合下，執(zhí)行時(shí)間等性能指標(biāo)將產(chǎn)生差異，主要原因在于多個(gè)查詢要競爭使用I/O和網(wǎng)絡(luò)等資源。在I/O資源方面，分析型查詢通常包含許多表連接操作，每個(gè)表的數(shù)據(jù)都需要從磁盤中讀取，這會(huì)引發(fā)大量的I/O操作，而且若幾個(gè)查詢掃描不同的數(shù)據(jù)表，則會(huì)爭用I/O，導(dǎo)致 I/O時(shí)間變長，繼而使得查詢變慢。對于網(wǎng)絡(luò)資源，數(shù)據(jù)存放在分布式數(shù)據(jù)庫集群的各個(gè)節(jié)點(diǎn)中，這些節(jié)點(diǎn)位于不同的物理機(jī)器上，在執(zhí)行查詢時(shí)，數(shù)據(jù)需要通過網(wǎng)絡(luò)在節(jié)點(diǎn)間遷移，因此，網(wǎng)絡(luò)帶寬資源的爭用也是影響性能的重要元素。模型能夠根據(jù)不同的查詢組合情況，量化資源(I/O、網(wǎng)絡(luò))的使用和爭用情況，從而預(yù)測查詢延遲時(shí)間。

本文提出了兩個(gè)模型，分別是：查詢干擾度(CQI,concurrent query interference)和查詢敏感度(QS, query sensitivity)。查詢干擾度是指多個(gè)并發(fā)查詢對主查詢(要預(yù)測的查詢)的干擾程度，干擾度越大說明資源競爭越激烈,主查詢的執(zhí)行延遲也越大。查詢敏感度是指主查詢在不同的查詢資源競爭情況下所表現(xiàn)出來的敏感程度即查詢性能，不同的查詢組合會(huì)引起不同程度的資源競爭。本文利用CQI和QS模型預(yù)測分布式數(shù)據(jù)庫中并發(fā)OLAP型查詢延遲。

1 相關(guān)工作

當(dāng)前已有一些針對查詢性能預(yù)測的研究，并且有較好的效果。另外，查詢進(jìn)度顯示通常也需要預(yù)測執(zhí)行時(shí)間。所以，接下來，本文將介紹關(guān)于這兩面的研究并比較與本文技術(shù)的區(qū)別。

1.1 查詢進(jìn)度指示器

查詢進(jìn)度指示器(QPI, query progress indicators)用于指示一個(gè)查詢的進(jìn)度，這樣可以直觀地了解查詢已經(jīng)花費(fèi)了多少時(shí)間和還需要多少時(shí)間能夠執(zhí)行完畢。當(dāng)前，針對QPI已經(jīng)有了一些研究，Surajit等人[11]對查詢完成的比例建模，他們沒有考慮并發(fā)查詢的情況，只是針對單個(gè)查。G.Luo等人[12-13]把磁盤I/O、運(yùn)行時(shí)間、消息字節(jié)數(shù)等作為度量，運(yùn)用機(jī)器學(xué)習(xí)預(yù)測長查詢的進(jìn)度，但是他們在預(yù)測查詢的延遲時(shí)間時(shí)，該查詢必須是在運(yùn)行中，而本文的方法在查詢執(zhí)行前就能夠得知查詢需要多少時(shí)間，且主要考慮并發(fā)查詢的情況，相對機(jī)器學(xué)習(xí)方法來說，更加簡單。

1.2 查詢性能預(yù)測

文獻(xiàn)[14-16]都是運(yùn)用機(jī)器學(xué)習(xí)的方法來預(yù)測查詢性能，但都沒有處理并發(fā)查詢的情形。對于多并發(fā)查詢，文獻(xiàn)[9,17-19]首先對性能預(yù)測技術(shù)進(jìn)行了研究，他們的共同點(diǎn)都是針對分析型查詢，而且考慮查詢之間的交互作用并建立回歸模型，即能夠預(yù)測不同并發(fā)度下的查詢性能。Mumtaz等人[20-21]擴(kuò)展了上述的研究，他們考慮了不同組合中查詢的相互影響，根據(jù)實(shí)驗(yàn)數(shù)據(jù)建立模型，從而得到了較高的準(zhǔn)確率。Muhammad等人[7]對運(yùn)行中的查詢進(jìn)行預(yù)測，而Barzan等人[8]主要對OLAP型的查詢進(jìn)行預(yù)測。Chetan等人[22]主要研究在數(shù)據(jù)倉庫中，查詢延遲如何隨著工作負(fù)載的改變而改變。Jennie等人[23]對并發(fā)查詢的資源競爭建模，使得預(yù)測的誤差較低。文獻(xiàn)[24]預(yù)測了在查詢在大數(shù)據(jù)量下的單獨(dú)執(zhí)行時(shí)間，它把SQL查詢映射為一系列基礎(chǔ)操作符并計(jì)算操作符消耗時(shí)間之和來計(jì)算總執(zhí)行時(shí)間。文獻(xiàn)[25]主要針對OLTP型并發(fā)查詢，運(yùn)行機(jī)器學(xué)習(xí)方法以系統(tǒng)狀態(tài)的36個(gè)指標(biāo)為基礎(chǔ)進(jìn)行性能預(yù)測。

上述研究既有對OLAP型查詢的研究，也有對OLTP型查詢的研究，在OLAP型并發(fā)查詢的情形下，都是基于單機(jī)數(shù)據(jù)庫，并沒有考慮分布式數(shù)據(jù)庫的環(huán)境，即查詢分布在多個(gè)機(jī)器上的情形，這種查詢有網(wǎng)絡(luò)開銷。本文提出的查詢干擾度模型考慮了網(wǎng)絡(luò)資源開銷，能更準(zhǔn)確地預(yù)測分布式數(shù)據(jù)庫并發(fā)查詢的性能。

2 分析型任務(wù)

2.1 分布式數(shù)據(jù)庫

本文使用分布式數(shù)據(jù)庫Greenplum存儲(chǔ)數(shù)據(jù)并查詢。分布式數(shù)據(jù)庫和單機(jī)數(shù)據(jù)庫最大的區(qū)別在于分布式數(shù)據(jù)庫是一個(gè)集群，集群中有多個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)分為主節(jié)點(diǎn)和從節(jié)點(diǎn)，主節(jié)點(diǎn)用來管理從節(jié)點(diǎn)并生成查詢計(jì)劃，從節(jié)點(diǎn)存放數(shù)據(jù)并按照查詢計(jì)劃查詢數(shù)據(jù)。當(dāng)客戶端提交一個(gè)SQL查詢到Greenplum后，Greenplum中的主節(jié)點(diǎn)首先解析查詢語句并生成一個(gè)代價(jià)最小的查詢計(jì)劃，然后，發(fā)送給各從節(jié)點(diǎn)，從節(jié)點(diǎn)根據(jù)查詢計(jì)劃執(zhí)行查詢，并將得到的結(jié)果返回給主節(jié)點(diǎn)，最后，主節(jié)點(diǎn)得到從各從節(jié)點(diǎn)發(fā)送來的結(jié)果，匯總結(jié)果并返回給客戶端。

分布式數(shù)據(jù)庫能夠存儲(chǔ)海量的數(shù)據(jù)，且能夠通過增加節(jié)點(diǎn)來擴(kuò)展存儲(chǔ)量，但由于數(shù)據(jù)分布在多個(gè)節(jié)點(diǎn)上，執(zhí)行表連接查詢時(shí)，通常需要遷移數(shù)據(jù)，所以，相較于單機(jī)數(shù)據(jù)庫，影響查詢性能的因素不僅包含從節(jié)點(diǎn)的CPU，內(nèi)存和I/O性能，還包括節(jié)點(diǎn)間網(wǎng)絡(luò)的性能。

2.2 分析型任務(wù)特征

分布式數(shù)據(jù)庫執(zhí)行查詢時(shí)，影響查詢性能有4個(gè)重要的因素，分別為：CPU、內(nèi)存、I/O和網(wǎng)絡(luò)，在這4個(gè)因素當(dāng)中，CPU和內(nèi)存相較于I/O和網(wǎng)絡(luò)，影響較小，因?yàn)橥ㄟ^實(shí)驗(yàn)觀察到，在多個(gè)查詢并行執(zhí)行的時(shí)候，集群中各個(gè)節(jié)都有足夠的CPU資源。另外，對于每個(gè)數(shù)據(jù)庫實(shí)例，配置充足的內(nèi)存。當(dāng)有多個(gè)查詢執(zhí)行時(shí)，如果分配給該實(shí)例的內(nèi)存耗盡，操作系統(tǒng)會(huì)將內(nèi)存中的部分?jǐn)?shù)據(jù)移到磁盤中，也就是發(fā)生頁置換，引起I/O操作。分布式數(shù)據(jù)庫最耗時(shí)的操作是掃描表，即發(fā)生I/O，其次是節(jié)點(diǎn)間數(shù)據(jù)傳輸。所以，本文主要研究磁盤I/O和節(jié)點(diǎn)間網(wǎng)絡(luò)因素對查詢性能的影響。

在本文的研究中，主要針對分析型查詢，其特點(diǎn)是包含大量的join操作，每個(gè)join需要通過I/O和網(wǎng)絡(luò)讀寫數(shù)據(jù)和傳輸數(shù)據(jù)，其查詢時(shí)間一般較長。多個(gè)查詢爭用I/O和網(wǎng)絡(luò)資源，這必然會(huì)對查詢產(chǎn)生影響。

本文用到的查詢是由TPC-DS中的10個(gè)模板生成[26]。選取的查詢模板分別：17，20、25、26、32、33、61、62、65、71，它們都為IO敏感型查詢，即花在I/O上的時(shí)間較多或占整個(gè)查詢時(shí)間的比例較大，有些查詢的I/O時(shí)間占整個(gè)執(zhí)行時(shí)間的90%以上。

2.3 取樣

本文定義MPL(multi-programming level)為同時(shí)運(yùn)行的查詢個(gè)數(shù)，當(dāng)MPL=3時(shí)，表示當(dāng)前有3個(gè)查詢同時(shí)執(zhí)行，且這3個(gè)查詢構(gòu)成一個(gè)查詢組合。由于一共有10個(gè)查詢，當(dāng)MPL為2時(shí)，可以兩兩結(jié)合組成查詢組合，但當(dāng)MPL等于大于3時(shí)，手工設(shè)計(jì)查詢組合會(huì)變得越來越復(fù)雜，所以，選用LHS(latin hypercube sampling)技術(shù)取樣，下面以一個(gè)例子說明如何使用該方法構(gòu)建查詢組合。以MPL等于3為例，在python中，運(yùn)行X=lhs(3,10)生成抽樣矩陣X：

矩陣X中的元素都位于0～1之間，然后把這些元素化為整數(shù)。變換的過程是將矩陣X中的每個(gè)元素?cái)U(kuò)大10倍，然后再向上取整得到整數(shù)矩陣Y：

Y包含10種整數(shù)，并且Y中的每行每列的數(shù)字都不重復(fù)，接下來把這10個(gè)數(shù)字映射成具體的查詢ID，映射的關(guān)系如下：

根據(jù)映射表最終得到在MPL為3下的查詢組合為：

在矩陣Z中，每一行代表一個(gè)查詢組合，每一行的第一個(gè)查詢代表該查詢組合的主查詢，其余都是并發(fā)查詢。在每個(gè)查詢組合中，每個(gè)查詢構(gòu)成一個(gè)查詢流，查詢流就是讓每個(gè)查詢運(yùn)行n次，這樣就得到n個(gè)樣本數(shù)據(jù)，這里只取后n-1次的數(shù)據(jù)。

2.4 預(yù)測評價(jià)

為了測量預(yù)測模型質(zhì)量，本文使用平均相對誤差MRE(mean relative error)來衡量，該度量的定義如下：

(1)

observedi為實(shí)際運(yùn)行的時(shí)間，predictedi為預(yù)測的時(shí)間，MRE越低，說明預(yù)測模型越準(zhǔn)確。

3 預(yù)測模型

該部分講述如何對主查詢和并發(fā)查詢的I/O和網(wǎng)絡(luò)資源爭用進(jìn)行建模。本文提出了查詢干擾度和查詢敏感度兩個(gè)模型，查詢干擾度用來描述主查詢當(dāng)前執(zhí)行環(huán)境的優(yōu)劣，也即描述資源的爭用情況，而查詢敏感度是描述主查詢在不同并發(fā)查詢執(zhí)行時(shí)，它的性能如何變化。

3.1 查詢干擾度

I/O和網(wǎng)絡(luò)是影響數(shù)據(jù)庫查詢性能最重要的兩個(gè)因素，在一定程度上能夠決定查詢總延遲。假定一個(gè)查詢組合為m，它包括主查詢q和與主查詢并行執(zhí)行的查詢C={c1,c2,…,cn}，并發(fā)查詢的個(gè)數(shù)為n。首先，得到每個(gè)并發(fā)查詢ci單獨(dú)運(yùn)行時(shí)需要的I/O和網(wǎng)絡(luò)資源，此時(shí)，沒有發(fā)生資源競爭。然后，估計(jì)每個(gè)并發(fā)查詢與主查詢爭用資源對主查詢的影響。最后，評估由于并發(fā)查詢之間爭用資源對主查詢的影響。定義變量如表2所示。

表2 主要符號含義

3.1.1 Baseline I/O

Baseline I/O指的是查詢的基準(zhǔn)I/O，即當(dāng)一個(gè)查詢獨(dú)立執(zhí)行時(shí)，它的I/O時(shí)間占用執(zhí)行總時(shí)間的百分比，所占百分比越大，則表示此查詢需要越多的I/O資源。用表示一個(gè)并發(fā)查詢中I/O所占的百分比。

3.1.2 Positive I/O

當(dāng)主查詢與并發(fā)查詢共同執(zhí)行時(shí)，如果一個(gè)并發(fā)查詢與主查詢掃描不同的表，并發(fā)查詢會(huì)對主查詢產(chǎn)生“干擾”，這是因?yàn)椴煌樵儠?huì)爭用I/O。當(dāng)并發(fā)查詢與主查詢掃描相同的表時(shí)，這種“干擾”會(huì)大大減小，甚至?xí)χ鞑樵儺a(chǎn)生“促進(jìn)”作用，因?yàn)樵跀?shù)據(jù)庫中，當(dāng)頻繁掃描一個(gè)表時(shí)，會(huì)把這個(gè)表的數(shù)據(jù)存入到共享緩存中，此后再請求這個(gè)表的數(shù)據(jù)，會(huì)直接從共享緩存中取，從而避免了重復(fù)性的I/O操作。下面通過模型來量化并發(fā)查詢與主查詢的相互作用。

假設(shè)表t是主查詢q與并發(fā)查詢ci共同掃描的表。定義如下值：

(2)

可以看到htci取值只有0和1，下面計(jì)算共享的I/O時(shí)間。

(3)

上述公式中，n表示主查詢和并發(fā)查詢需要掃描表的總個(gè)數(shù)，St表示掃描表t花費(fèi)的時(shí)間。本文用select * from[table]形式的查詢語句獲取掃描表[table]花費(fèi)的總時(shí)間，即該查詢語句執(zhí)行時(shí)間中的掃描表的時(shí)間。在Greenplum中，表的數(shù)據(jù)分布到各個(gè)節(jié)點(diǎn)中，查詢在各個(gè)節(jié)點(diǎn)中執(zhí)行，所以，多個(gè)查詢?nèi)绻餐谋?，則可“省去”重復(fù)在磁盤上掃描表的時(shí)間。公式(3)計(jì)算由于共享I/O的而節(jié)省的時(shí)間。

3.1.3 Concurrent I/O

除了考慮主查詢和并發(fā)查詢的共享I/O之外，還需要度量并發(fā)查詢之間的I/O影響。即主查詢與兩個(gè)并發(fā)查詢a和b共同執(zhí)行時(shí)，a和b由于并發(fā)執(zhí)行所節(jié)省的I/O時(shí)間。首先定義表t為并發(fā)查詢和其他非主查詢共同掃描的表：

(4)

定義dt為掃描表t的并發(fā)查詢的個(gè)數(shù)，這里dt必須大于1。另外，由于只考慮并發(fā)查詢之間的表掃描情況，所以這里的表t不能出現(xiàn)在主查詢當(dāng)中。計(jì)算由于并發(fā)查詢共享I/O而節(jié)省的時(shí)間為：

(5)

上面公式中的n同樣是主查詢和并發(fā)查詢需要掃描表的總數(shù)。

3.1.4 網(wǎng)絡(luò)爭用

本文面向的是分布式數(shù)據(jù)庫，數(shù)據(jù)分布在集群中的各個(gè)節(jié)點(diǎn)中，SQL查詢中的表連接操作一定會(huì)發(fā)生數(shù)據(jù)傳輸，即把在一個(gè)節(jié)點(diǎn)上的數(shù)據(jù)遷移到另一個(gè)節(jié)點(diǎn)上。Greenplum中數(shù)據(jù)遷移的方式有兩種：廣播和重分布。廣播就是把一個(gè)節(jié)點(diǎn)上的數(shù)據(jù)傳輸給其他所有節(jié)點(diǎn)，從而每個(gè)節(jié)點(diǎn)都有一個(gè)表的完整數(shù)據(jù)。重分布就是把表的數(shù)據(jù)根據(jù)關(guān)聯(lián)鍵計(jì)算哈希值，然后再重新分布到各個(gè)節(jié)點(diǎn)上。假設(shè)一個(gè)表的記錄數(shù)為N，那么重分布的數(shù)據(jù)量為N，廣播的數(shù)據(jù)量為N*節(jié)點(diǎn)數(shù)，通過上述的方式就可以計(jì)算一個(gè)連接操作的數(shù)據(jù)遷移量。主查詢的數(shù)據(jù)遷移總量為tq，并發(fā)查詢的遷移數(shù)據(jù)量為，tci定義并發(fā)查詢對主查詢的網(wǎng)絡(luò)干擾為：

(6)

從上式可以看出，并發(fā)查詢ci的數(shù)據(jù)遷移量越大，對主查詢的干擾就越大；反之，則越小。這是由于系統(tǒng)的網(wǎng)絡(luò)帶寬是一定的，當(dāng)網(wǎng)絡(luò)中有其他查詢傳輸數(shù)據(jù)時(shí)，必然會(huì)影響主查詢的數(shù)據(jù)傳輸。

3.1.5 查詢干擾度模型

得到上述各個(gè)變量以后，就可以定義并發(fā)查詢對主查詢的影響。

(7)

公式(7)可以理解為并發(fā)查詢ci與主查詢直接競爭I/O和網(wǎng)絡(luò)的激烈程度，公式(7)的前半部分是主查詢減去了并發(fā)查詢與主查詢共享I/O的時(shí)間，在網(wǎng)絡(luò)爭用確定的情況下，當(dāng)γci越大，則表示并發(fā)查詢與主查詢共享I/O的時(shí)間越短，競爭I/O的時(shí)間越長，在這種情況下，會(huì)延長主查詢的查詢延遲。當(dāng)γci越小，則表示并發(fā)查詢與主查詢的資源競爭越小，對主查詢的延遲影響越小。

在一個(gè)查詢組合中，定義主查詢的CQI值為γq,m，計(jì)算公式如下：

(8)

上述公式即取各并發(fā)查詢的γci平均值。

3.2 查詢敏感度

查詢敏感度是指主查詢對不同執(zhí)行環(huán)境的敏感程度，這里不同的執(zhí)行環(huán)境就是不同的MPL以及在相同MPL下的不同查詢組合。敏感程度指主查詢的性能變化，不同的執(zhí)行環(huán)境會(huì)引起不同的資源競爭，進(jìn)而導(dǎo)致主查詢的性能變化。下面詳細(xì)介紹該模型。

3.2.1 查詢性能區(qū)間

查詢性能區(qū)間PR(performance range)指的是一個(gè)查詢延遲時(shí)間范圍，這個(gè)區(qū)間中的值表示查詢在不同環(huán)境中的執(zhí)行時(shí)間，區(qū)間的最大值為τmaxci，表示查詢在最惡劣的資源環(huán)境下的執(zhí)行時(shí)間。本文通過不斷讀取大文件并在不同節(jié)點(diǎn)間交換傳輸這些文件模擬最差的環(huán)境。最小值為τminci，表示在當(dāng)前環(huán)境中，只有這個(gè)查詢在執(zhí)行時(shí)的延遲時(shí)間。上述兩個(gè)值表示在極端執(zhí)行環(huán)境中的執(zhí)行查詢，在其余環(huán)境下的查詢執(zhí)行時(shí)間都位于該查詢性能區(qū)間中，主查詢的PRP(performance range point)值定義如下：

(9)

當(dāng)知道了cq,m的值以后，將該值代入公式(9)反推可得到τq,m，即主查詢的查詢延遲。接下來，介紹如何預(yù)測cq,m的值。

3.2.2 查詢敏感度模型

在3.1節(jié)介紹了CQI模型，該模型可以用于預(yù)測查詢延遲(后面通過實(shí)驗(yàn)具體驗(yàn)證)。這意味著，給定一個(gè)查詢組合m和一個(gè)主查詢q，可以利用公式(8)來計(jì)算CQI值，然后使用線性回歸模型預(yù)測查詢的性能。為了進(jìn)一步說明查詢性能和CQI之間的線性關(guān)系，本文引入查詢敏感度QS(query sensitivity)。

假定CQI和PRP存在線性的關(guān)系，定義如下公式：

cq,m=μq*γq,m+bq

(10)

上述公式中，μq為斜率，bq為截距，cq,m與γq,m是一種線性關(guān)系。

3.2.3 預(yù)測流程

在Greenplum中，利用QS模型預(yù)測查詢q的流程如圖1所示。

圖1 利用QS預(yù)測查詢延遲

4 實(shí)驗(yàn)評估

4.1 實(shí)驗(yàn)環(huán)境

實(shí)驗(yàn)的環(huán)境為Greenplum分布式集群，Greenplum版本為5.0.0-alpha+79a3598。集群中共有4個(gè)節(jié)點(diǎn)，一個(gè)主節(jié)點(diǎn)和3個(gè)從節(jié)點(diǎn)，從節(jié)點(diǎn)主要用來存放數(shù)據(jù)并執(zhí)行查詢，主節(jié)點(diǎn)則負(fù)責(zé)分配查詢和匯總結(jié)果。主節(jié)點(diǎn)的硬件配置為32 GB的內(nèi)存，CPU為4核Intel(R)Xeon(R)CPU E5-2630 v2 @ 2.60 GHz，從節(jié)點(diǎn)的內(nèi)存16 GB，CPU的核數(shù)和型號與主節(jié)點(diǎn)相同，在每個(gè)從節(jié)點(diǎn)中有4個(gè)數(shù)據(jù)庫實(shí)例，每個(gè)數(shù)據(jù)庫實(shí)例相當(dāng)于一個(gè)完整PostgreSQL的數(shù)據(jù)庫，用于處理一部分的數(shù)據(jù)。主節(jié)點(diǎn)和從節(jié)點(diǎn)的操作系統(tǒng)均為CentOS 7.4，linux內(nèi)核版本為3.10。

表和數(shù)據(jù)通過TPC-DS生成，TPC-DS是一個(gè)決策支持的benchmark。實(shí)驗(yàn)所用數(shù)據(jù)量大小為50 G，選取TPC-DS中的10個(gè)模板生成10個(gè)查詢用于訓(xùn)練和測試模型，這10個(gè)查詢主要是I/O敏感型查詢，執(zhí)行時(shí)間較長，有利于提高預(yù)測模型的精度。

4.2 實(shí)驗(yàn)過程

在第3節(jié)詳細(xì)講述了如何利用查詢干擾度和查詢敏感度模型預(yù)測一個(gè)查詢的延遲時(shí)間，下面通過實(shí)驗(yàn)驗(yàn)證上述的模型方法。具體實(shí)驗(yàn)過程說明如下：

在實(shí)驗(yàn)環(huán)境中，基于Greenplum數(shù)據(jù)庫集群的默認(rèn)配置，執(zhí)行TPC-DS基準(zhǔn)測試。并通過設(shè)置Greenplum的并行度參數(shù)，控制同時(shí)執(zhí)行的查詢數(shù)分別指定的MPL(例如：1-5)。與此同時(shí)，通過性能監(jiān)控工具Telegraf采集服務(wù)器的各項(xiàng)資源開銷數(shù)據(jù)，并結(jié)合Greenplum返回的查詢執(zhí)行時(shí)間等性能數(shù)據(jù)，構(gòu)建下述提到的查詢干擾度模型和查詢敏感度模型，并據(jù)此進(jìn)行分析型查詢的性能預(yù)測。

4.2.1 查詢干擾度模型

3.1節(jié)介紹了主查詢q在查詢組合m中的查詢干擾度，接下來，通過實(shí)驗(yàn)驗(yàn)證通過該模型預(yù)測查詢延遲是否有效。

1)查詢干擾度模型分量：

查詢干擾度評估了并發(fā)查詢對主查詢的干擾程度，干擾程度越大，對主查詢的延遲也就越大。在查詢干擾度模型中，下面分別對干擾度模型中的4個(gè)分量進(jìn)行驗(yàn)證。

首先是基準(zhǔn)I/O(baseline I/O)，當(dāng)模型中只有baseline I/O時(shí)，計(jì)算一個(gè)并發(fā)查詢的干擾度會(huì)變成如下形式：

γci=(τminci*Pci)/τminci

(11)

公式只計(jì)算了并發(fā)查詢與主查詢競爭的I/O帶寬，相當(dāng)于并發(fā)查詢與主查詢是完全競爭的關(guān)系。

其次，在基準(zhǔn)I/O的基礎(chǔ)上，加入并發(fā)查詢與主查詢的正向交互作用因素,即positive I/O，得到如下形式：

γci=(τminci*Pci-ρci)/τminci

(12)

式(12)從爭用的I/O時(shí)間中減去了由于共享表掃描所節(jié)省的時(shí)間，該公式主要考慮了并發(fā)查詢對主查詢的影響。

然后，再進(jìn)一步考慮并發(fā)查詢之間的交互,即concurrent I/O，所得模型如下：

γci=(τminci*Pci-ρci-φci)/τminci

(13)

式(13)即在式(12)的基礎(chǔ)上加入了在一個(gè)查詢組合中，并發(fā)查詢之間的共享I/O時(shí)間。并發(fā)查詢之間的作用會(huì)間接影響主查詢的I/O操作。

最后，再加入網(wǎng)絡(luò)爭用的因素，得到CQI模型：

(14)

2)查詢干擾度模型驗(yàn)證：

首先評估CQI的各個(gè)分量對誤差率的影響，然后利用CQI預(yù)測查詢延遲。當(dāng)MPL為3時(shí)，上述各個(gè)變量對查詢延遲的預(yù)測誤差如下：

從圖2可以看到，只利用baseline I/O(對應(yīng)公式(11))預(yù)測查詢延遲的時(shí)候，它的誤差較大，當(dāng)加入并發(fā)查詢交互(對應(yīng)公式(12))的因素后，對誤差率有明顯的降低?？紤]concurrent I/O(對應(yīng)公式(13))和網(wǎng)絡(luò)爭用因素(對應(yīng)公式(14))，對預(yù)測的準(zhǔn)確率沒有明顯提高，說明positive I/O是影響預(yù)測模型準(zhǔn)確率的主要因素，其他因素能夠小幅度的提升準(zhǔn)確率。綜上，CQI考慮了并發(fā)查詢之間的主要影響因素，是一個(gè)較好的預(yù)測模型。接下來，驗(yàn)證CQI模型對各個(gè)查詢的誤差。

圖2 各個(gè)查詢在不同度量下的誤差

對于一個(gè)給定的查詢組合，其中有一個(gè)主查詢，其他查詢?yōu)椴l(fā)查詢。實(shí)驗(yàn)產(chǎn)生的數(shù)據(jù)分為訓(xùn)練集和測試集。假設(shè)主查詢的查詢延遲和CQI存在線性關(guān)系，則通過訓(xùn)練集能夠得到這個(gè)線性關(guān)系，然后，利用該線性模型對主查詢進(jìn)行預(yù)測，再與測試集數(shù)據(jù)比較并計(jì)算誤差，從而得到圖3。

圖3 各個(gè)查詢在MPL等于3時(shí)的誤差

圖3為10個(gè)查詢在MPL為3時(shí)的預(yù)測情況，從圖中可以看到，查詢延遲預(yù)測的誤差大部分在25%以下。此處的誤差是平均相對誤差(MRE),其定義已經(jīng)在公式(1)中給出。查詢61和62的誤差相對較高，這是由于這兩個(gè)查詢相對較為簡單，查詢時(shí)間較短，因而其它因素查詢預(yù)測的干擾較大，導(dǎo)致誤差相對較大。在實(shí)驗(yàn)中，查詢71的誤差也相對較高。該查詢較為復(fù)雜，主要用于“對于指定的經(jīng)理及其關(guān)聯(lián)的所有3個(gè)銷售渠道，找出其一個(gè)月內(nèi)在早餐或晚餐時(shí)間段營收最高的產(chǎn)品”，其執(zhí)行時(shí)間較長，因而誤差相對率偏高。該查詢的標(biāo)準(zhǔn)SQL形式如下：

select i_brand_id brand_id, i_brand brand,t_hour,t_minute,

sum(ext_price)ext_price

from item,(select ws_ext_sales_price as ext_price,

ws_sold_date_sk as sold_date_sk,

ws_item_sk as sold_item_sk,

ws_sold_time_sk as time_sk

from web_sales,date_dim

where d_date_sk = ws_sold_date_sk

and d_moy=12

and d_year=2002

union all

select cs_ext_sales_price as ext_price,

cs_sold_date_sk as sold_date_sk,

cs_item_sk as sold_item_sk,

cs_sold_time_sk as time_sk

from catalog_sales,date_dim

where d_date_sk = cs_sold_date_sk

and d_moy=12

and d_year=2002

union all

select ss_ext_sales_price as ext_price,

ss_sold_date_sk as sold_date_sk,

ss_item_sk as sold_item_sk,

ss_sold_time_sk as time_sk

from store_sales,date_dim

where d_date_sk = ss_sold_date_sk

and d_moy=12

and d_year=2002

)tmp,time_dim

where

sold_item_sk = i_item_sk

and i_manager_id=1

and time_sk = t_time_sk

and(t_meal_time = ‘breakfast’ or t_meal_time = ‘dinner’)

group by i_brand, i_brand_id,t_hour,t_minute

order by ext_price desc, i_brand_id

總體而言，除去類似于查詢61和查詢62這類因查詢?nèi)蝿?wù)簡單、執(zhí)行時(shí)間短，易受干擾的查詢，以及查詢71這類非常復(fù)雜的查詢，TPC-DS的代表性查詢在MPL為2、4和5時(shí)的資源預(yù)測情況與MPL為3時(shí)類似，大部分查詢誤差率仍在25%以下。

4.2.2 查詢敏感度模型

前面的實(shí)驗(yàn)驗(yàn)證了CQI可以較準(zhǔn)確地預(yù)測查詢延遲，而CQI是針對特定的查詢組合，為此，本文提出了QS模型，它能夠感知查詢所處的不同環(huán)境(不同的查詢組合)，并做出預(yù)測。

對于一個(gè)特定的查詢q，找到包含這個(gè)查詢的查詢組合，然后以q為主查詢構(gòu)建QS模型，利用該模型預(yù)測執(zhí)行時(shí)間，并與實(shí)際執(zhí)行時(shí)間比較，得到結(jié)果如圖4所示。

圖4 各個(gè)查詢在不同MPL時(shí)的誤差

從圖4可以看出，不同的MPL，除去查詢61和62，查詢的誤差都在25%以下，有的甚至能夠達(dá)到20%以下。同樣的，查詢61和62的誤差較高的原因在于它們的執(zhí)行時(shí)間較短，從而造成誤差較大。由此實(shí)驗(yàn)結(jié)果表明，QS模型能夠適應(yīng)不同的查詢執(zhí)行環(huán)境(不同MPL下的不同查詢組合)，從而能夠較準(zhǔn)確地預(yù)測查詢的執(zhí)行延遲。

5 結(jié)束語

本文主要研究在分布式數(shù)據(jù)庫中預(yù)測一個(gè)查詢在多個(gè)其他查詢并行執(zhí)行的情況下其執(zhí)行時(shí)間的技術(shù)，考慮了I/O和網(wǎng)絡(luò)因素，這與其他基于機(jī)器學(xué)習(xí)的在單機(jī)數(shù)據(jù)庫上的性能預(yù)測技術(shù)有明顯不同。

本文主要提出了兩個(gè)模型，分別為：查詢干擾度和查詢敏感度。查詢干擾度(CQI)用于建立資源競爭的衡量模型，而查詢敏感度(QS)用于衡量主查詢對其他并發(fā)查詢的感知度。查詢敏感度是建立在查詢干擾度的基礎(chǔ)上，通過實(shí)驗(yàn)發(fā)現(xiàn)CQI與查詢延遲存在線性關(guān)系，而QS則在CQI的基礎(chǔ)上建立這種線性模型，從而利用QS預(yù)測查詢延遲。

最后，實(shí)驗(yàn)結(jié)果表明模型的預(yù)測誤差率大部分能夠維持在25%以下，能夠較準(zhǔn)確地預(yù)測查詢的延遲時(shí)間。在此后的工作中，可以考慮如何使用更有效的指標(biāo)來量化資源的競爭，以及如何利用查詢執(zhí)行計(jì)劃輔助來建立預(yù)測模型。