亞馬遜推出機(jī)器學(xué)習(xí)工具給數(shù)據(jù)庫(kù)調(diào)優(yōu),DBA要失業(yè)了?

責(zé)任編輯:editor004

作者:核子可樂(lè)

2017-06-08 11:43:31

摘自:INFOQ

數(shù)據(jù)庫(kù)管理系統(tǒng)(簡(jiǎn)稱 DBMS)無(wú)疑是任何數(shù)據(jù)密集型應(yīng)用程序當(dāng)中最為重要的組成部分,其肩負(fù)著處理大量數(shù)據(jù)以及高復(fù)雜性工作負(fù)載的重任。

數(shù)據(jù)庫(kù)管理系統(tǒng)(簡(jiǎn)稱 DBMS)無(wú)疑是任何數(shù)據(jù)密集型應(yīng)用程序當(dāng)中最為重要的組成部分,其肩負(fù)著處理大量數(shù)據(jù)以及高復(fù)雜性工作負(fù)載的重任。然而,數(shù)據(jù)庫(kù)管理系統(tǒng)本身卻往往難于管理,因?yàn)槠渲型ǔ0瑪?shù)百種配置“旋鈕”,用于控制諸如緩存內(nèi)存分配量以及存儲(chǔ)介質(zhì)數(shù)據(jù)寫(xiě)入頻率等要素。各類企業(yè)一般需要聘請(qǐng)專業(yè)人士以協(xié)助相關(guān)調(diào)配工作,但對(duì)于大多數(shù)企業(yè)而言,此類專業(yè)人才的開(kāi)價(jià)亦相當(dāng)高昂。

面對(duì)這一難題,卡耐基 - 梅隆大學(xué)數(shù)據(jù)庫(kù)小組(Carnegie Mellon Database Group)的學(xué)生及研究人員們共同開(kāi)發(fā)出一款名為 OtterTune 的新型工具,其能夠以自動(dòng)化方式識(shí)別出最適當(dāng)當(dāng)前數(shù)據(jù)庫(kù)管理系統(tǒng)配置需求的設(shè)置組合。其目標(biāo)在于有效簡(jiǎn)化用戶對(duì) DBMS 的部署流程,確保那些在數(shù)據(jù)庫(kù)管理層面不具備任何專業(yè)知識(shí)的朋友亦能輕松完成任務(wù)。

OtterTune 與其它 DBMS 配置工具之間的主要差別在于,其能夠利用自此前 DBMS 部署工作當(dāng)中積累到的知識(shí)指導(dǎo)新系統(tǒng)的配置工作。這一設(shè)計(jì)思路顯然降低了新 DBMS 部署方案在調(diào)整當(dāng)中所需要的時(shí)間與資源投入。而為了實(shí)現(xiàn)這一目標(biāo),OtterTune 專門建立起一套數(shù)據(jù)庫(kù),用以收集從此前調(diào)節(jié)會(huì)話中提取到的重要信息。其利用這部分?jǐn)?shù)據(jù)建立機(jī)器學(xué)習(xí)(簡(jiǎn)稱 ML)模型,用以捕捉 DBMS 在面對(duì)不同配置方案時(shí)作出怎樣的響應(yīng)。OtterTune 還利用這些模型以指導(dǎo)新型應(yīng)用程序的配置實(shí)驗(yàn),并提供推薦設(shè)置以提升目標(biāo)運(yùn)作效果(例如減少延遲或者提高數(shù)據(jù)吞吐量)。

在今天的文章中,我們將探討 OtterTune 機(jī)器學(xué)習(xí)管道當(dāng)中的每個(gè)組成部分,同時(shí)展示其如何彼此交互以實(shí)現(xiàn) DBMS 配置調(diào)節(jié)。在此之后,我們還將立足 MySQL 與 PostgreSQL 評(píng)估 OtterTune 的調(diào)節(jié)效果,包括將其最佳配置方案與數(shù)據(jù)庫(kù)管理員(簡(jiǎn)稱 DBA)以及其它自動(dòng)化調(diào)節(jié)工具給出的答案進(jìn)行比對(duì)。

OtterTune 是一款開(kāi)源工具,由卡耐基 - 梅隆大學(xué)數(shù)據(jù)庫(kù)小組的學(xué)生及研究人員們共同開(kāi)發(fā)而成。其全部代碼皆可點(diǎn)擊此處通過(guò) GitHub 訪問(wèn),且基于 Apache License 2.0 許可。

OtterTune 工作原理解析

以下示意圖用于解釋 OtterTune 中的各組件與工作流。

在開(kāi)始一輪新的調(diào)節(jié)會(huì)話時(shí),用戶首先需要告知 OtterTune 此番優(yōu)化的具體目標(biāo)(例如面向延遲抑或數(shù)據(jù)吞吐量)。其客戶端控制器將接入目標(biāo) DBMS 并收集其 Amazon EC2 實(shí)例類型與當(dāng)前配置等相關(guān)信息。

在此之后,該控制器會(huì)開(kāi)始第一輪觀察周期,在此期間其將觀察 DBMS 以及與既定目標(biāo)相關(guān)之各項(xiàng)記錄。在此輪觀察周期結(jié)束后,控制器將從 DBMS 當(dāng)中收集各類內(nèi)部指標(biāo),例如 MySQL 自磁盤(pán)處讀取之頁(yè)面以及向磁盤(pán)中寫(xiě)入之頁(yè)面計(jì)數(shù)。該控制器隨后會(huì)將目標(biāo)信息與內(nèi)部指標(biāo)發(fā)送回調(diào)節(jié)管理器當(dāng)中。

當(dāng) OtterTune 的調(diào)節(jié)管理器接收到這些指標(biāo)后,其會(huì)將相關(guān)數(shù)據(jù)存儲(chǔ)在自有存儲(chǔ)庫(kù)內(nèi)。OtterTune 利用這些結(jié)果計(jì)算出控制器應(yīng)在目標(biāo) DBMS 上安裝的下一套配置方案。具體配置方案由調(diào)節(jié)管理器交付至控制器處,同時(shí)確定運(yùn)行后的預(yù)期改進(jìn)效果。這時(shí),用戶即可決定繼續(xù)抑或中止當(dāng)前調(diào)節(jié)會(huì)話。

注意事項(xiàng)

OtterTune 為其支持的每個(gè) DBMS 版本皆設(shè)立有一套調(diào)節(jié)黑名單。此份黑名單中囊括了各類無(wú)法調(diào)整的項(xiàng)目(例如 DBMS 存儲(chǔ)文件的路徑名稱)或者可能引發(fā)嚴(yán)重乃至隱藏后果的選項(xiàng)(例如可能導(dǎo)致 DBMS 遭遇潛在數(shù)據(jù)丟失)。每開(kāi)始一項(xiàng)調(diào)節(jié)會(huì)話時(shí),OtterTune 即可彈出黑名單提示,用以提醒用戶添加各項(xiàng)不希望由 OtterTune 進(jìn)行調(diào)節(jié)的具體條目。

OtterTune 做出的某些假設(shè)可能會(huì)對(duì)部分用戶產(chǎn)生一定的不利影響。舉例來(lái)說(shuō),其假設(shè)用戶擁有允許控制器對(duì) DBMS 配置進(jìn)行修改的管理權(quán)限。如果用戶不具備此權(quán)限,則可在其它硬件之上部署一套數(shù)據(jù)庫(kù)副本以執(zhí)行 OtterTune 調(diào)節(jié)實(shí)驗(yàn)——但這亦要求用戶重播工作負(fù)載追蹤流程或立足生產(chǎn) DBMS 進(jìn)行查詢轉(zhuǎn)發(fā)。

機(jī)器學(xué)習(xí)管道

以下示意圖介紹了數(shù)據(jù)如何經(jīng)由 OtterTune 的機(jī)器學(xué)習(xí)管道實(shí)現(xiàn)移動(dòng)與處理。全部觀察結(jié)果皆被保留在 OtterTune 的存儲(chǔ)庫(kù)當(dāng)中。

OtterTune 首先會(huì)將觀察結(jié)果交付至 Workload Characterization 組件當(dāng)中。此組件負(fù)責(zé)識(shí)別其中一小部分 DBMS 指標(biāo),從而更好地把握性能差異以及不同工作負(fù)載之間的區(qū)別性特征。

接下來(lái),Knob Indetification 組件會(huì)生成一份與可調(diào)節(jié)項(xiàng)目相關(guān)之排名清單,其具體排序根據(jù)對(duì) DBMS 性能之影響力而定。OtterTune 隨后會(huì)將全部信息饋送至 Automatic Tuner 當(dāng)中。此組件負(fù)責(zé)將目標(biāo) DBMS 的工作負(fù)載與現(xiàn)有數(shù)據(jù)存儲(chǔ)庫(kù)內(nèi)最為相似的工作負(fù)載進(jìn)行映射,而后利用對(duì)應(yīng)工作負(fù)載數(shù)據(jù)以生成更適用的配置方案。

  下面讓我們深入了解機(jī)器學(xué)習(xí)管道當(dāng)中所涉及的每一個(gè)組件。

Workload Characterization: OtterTune 利用 DBMS 的各內(nèi)部運(yùn)行時(shí)指標(biāo)以表征某一工作負(fù)載的行為方式。這些指標(biāo)能夠?qū)ぷ髫?fù)載作出準(zhǔn)確表示,因?yàn)槠淠軌虼_切捕捉到其運(yùn)行時(shí)行為當(dāng)中的各項(xiàng)細(xì)節(jié)。然而,亦有許多度量完全不必要存在:其中一部分屬于不同單元記錄當(dāng)中的同一量度結(jié)果,另一些不必要指標(biāo)則代表著某些數(shù)值存在高度互關(guān)聯(lián)性的 DBMS 獨(dú)立組件。因此,對(duì)其中的冗余度量進(jìn)行排除將非常重要,這將有效幫助我們降低機(jī)器學(xué)習(xí)模型的復(fù)雜性水平。為此,我們將面向 DBMS 對(duì)相關(guān)模型的度量進(jìn)行收斂。此后,我們將從每個(gè)群集當(dāng)中選擇出一個(gè)代表性度量,并確保其為最靠近群集中心的度量。機(jī)器學(xué)習(xí)管道當(dāng)中的后續(xù)組件將對(duì)這些度量加以使用。

Knob Identification: DBMS 可以擁有數(shù)百項(xiàng)可調(diào)節(jié)項(xiàng)目,但其中只有一個(gè)子集會(huì)對(duì) DBMS 性能造成實(shí)際影響。OtterTune 利用當(dāng)前流行趨勢(shì) 特性選擇技術(shù) Lasso 以確保哪個(gè)條目會(huì)對(duì)系統(tǒng)的整體性能造成嚴(yán)重影響。通過(guò)此項(xiàng)技術(shù),OtterTune 將能夠利用其存儲(chǔ)庫(kù)內(nèi)的數(shù)據(jù)對(duì)各 DBMS 可調(diào)節(jié)項(xiàng)目的重要性進(jìn)行排序。

除此之外,OtterTune 還必須決定在配置建議當(dāng)中具體包含多少個(gè)可調(diào)節(jié)項(xiàng)目。很明顯,包含太多可調(diào)節(jié)項(xiàng)目將顯著增加 OtterTune 的優(yōu)化時(shí)長(zhǎng),但太少則可能導(dǎo)致 OtterTune 找不到最佳配置方案。為了以自動(dòng)化方式實(shí)現(xiàn)此流程,OtterTune 采取了增量式方法。其會(huì)逐漸增加調(diào)節(jié)會(huì)話當(dāng)中所使用的條目數(shù)量。此種方法能夠確保 OtterTune 在擴(kuò)展其調(diào)節(jié)范圍之前,首先識(shí)別并優(yōu)化一小部分最為重要的配置調(diào)節(jié)項(xiàng)目。

Automatic Tuner: Automated Tuning 組件通過(guò)在每輪觀察周期之后執(zhí)行兩項(xiàng)分析步驟以確定 OtterTune 的推薦配置方案。

首先,該系統(tǒng)利用確定自 Workload Characterization 組件中識(shí)別指標(biāo)的性能數(shù)據(jù)從原有存儲(chǔ)庫(kù)內(nèi)找到最能體現(xiàn)目標(biāo) DBMS 工作負(fù)載特征的原有調(diào)節(jié)會(huì)話。其會(huì)將兩項(xiàng)會(huì)話間的指標(biāo)進(jìn)行比較,旨在了解如何對(duì)不同調(diào)節(jié)選項(xiàng)進(jìn)行變動(dòng)以實(shí)現(xiàn)類似的工作負(fù)載指標(biāo)量化結(jié)果。

在此之后,OtterTune 會(huì)選擇另一套調(diào)節(jié)配置進(jìn)行嘗試。這套新的配置方案切合當(dāng)前統(tǒng)計(jì)模型所收集到的實(shí)際數(shù)據(jù),即以此數(shù)據(jù)為基礎(chǔ)從存儲(chǔ)庫(kù)當(dāng)中查找類似的工作負(fù)載。這套模型允許 OtterTune 預(yù)測(cè) DBMS 在各類潛在配置下的實(shí)際運(yùn)行效果 OtterTune 會(huì)對(duì)下一套配置進(jìn)行優(yōu)化,從而將探索(即收集集團(tuán)以改進(jìn)模型)轉(zhuǎn)化為實(shí)際利用(盡可能帶來(lái)更出色的目標(biāo)度量)。

具體實(shí)現(xiàn)

OtterTune 以 Python 語(yǔ)言編寫(xiě)而成。

對(duì)于 Workload Characterization 與 Knob Identification 兩種組件,運(yùn)行時(shí)性能并非我們的關(guān)注重點(diǎn),因此我們使用 scikit 以實(shí)現(xiàn)相應(yīng)的機(jī)器學(xué)習(xí)算法。這些算法在后臺(tái)進(jìn)程當(dāng)中運(yùn)行,并使用來(lái)自 OtterTune 存儲(chǔ)庫(kù)的新數(shù)據(jù)。

對(duì)于 Automatic Tuner,這些機(jī)器學(xué)習(xí)算法則變得更為關(guān)鍵。其需要在每一輪觀察周期后運(yùn)行,同時(shí)結(jié)合新數(shù)據(jù)以確保 OtterTune 能夠選擇一項(xiàng)對(duì)應(yīng)調(diào)節(jié)條目進(jìn)行下一步嘗試。在這一流程中,由于性能成為更加重要的考量因素,因此我們使用 TensorFlow 以實(shí)現(xiàn)這些算法。

為了收集與 DBMS 硬件、調(diào)節(jié)配置以及運(yùn)行時(shí)性能指標(biāo)相關(guān)的數(shù)據(jù),我們將 OtterTune 控制器同 OLTP-Bench 基準(zhǔn)測(cè)試框架進(jìn)行了整合。

實(shí)驗(yàn)性設(shè)計(jì)

為了完成評(píng)估,我們利用 OtterTune 所給出的以下最佳配置選項(xiàng)對(duì) MySQL 及 Postgres 性能進(jìn)行了比較:

Default: DBMS 所提供的配置方案Tuning script: 由一款開(kāi)源調(diào)節(jié)建議工具生成的配置方案DBA: 由人類數(shù)據(jù)庫(kù)管理員選定的配置方案RDS: 針對(duì) Amazon RDS 管理并部署在同一 EC2 實(shí)例類型之上的 DBMS 進(jìn)行定制化的配置方案

我們?cè)?Amazon EC2 現(xiàn)貨實(shí)例之上進(jìn)行了全部實(shí)驗(yàn)。我們分別在兩套實(shí)例之上執(zhí)行實(shí)驗(yàn)過(guò)程:其一作為 OtterTune 控制器,其二則作為目標(biāo) DBMS 部署系統(tǒng)。我們?cè)谶@里分別使用了 m4.large 與 m3.xlarge 實(shí)例類型。我們將 OtterTune 的調(diào)節(jié)管理器與數(shù)據(jù)存儲(chǔ)庫(kù)部署在一套本地服務(wù)器之上,其配置為 20 計(jì)算核心與 128 GB 內(nèi)存。

我們還用到了 TPC-C 工作負(fù)載,其屬于業(yè)界標(biāo)準(zhǔn)的在線事務(wù)處理(簡(jiǎn)稱 OLTP)系統(tǒng)性能評(píng)估工作負(fù)載類型。

評(píng)估方式

對(duì)于我們?cè)趯?shí)驗(yàn)當(dāng)中所使用的 MySQL 與 Postgres 兩套數(shù)據(jù)庫(kù),我們分別對(duì)其延遲水平與數(shù)據(jù)吞吐量進(jìn)行了觀察。以下圖表給出了對(duì)應(yīng)結(jié)果。第一份圖表所示為第 99 百分位處的延遲水平,意味著“最壞情況”下完成事務(wù)處理所需要的時(shí)長(zhǎng)。第二份圖表則顯示了數(shù)據(jù)吞吐量結(jié)果,即每秒完成的平均事務(wù)數(shù)量。

MySQL 測(cè)試結(jié)果

將 OtterTune 所生成的最佳配置與 Tuning Script 以及 RDS 相關(guān)配置進(jìn)行比較可以發(fā)現(xiàn),MySQL 在延遲水平方面降低了約 60%,而數(shù)據(jù)吞吐量則在 OtterTune 配置的幫助下提升 22% 到 35% 之間。與此同時(shí),OtterTune 的生成的配置方案在實(shí)際效果上與人類數(shù)據(jù)庫(kù)管理員幾乎不相上下。

一部分特定 MySQL 調(diào)節(jié)項(xiàng)目對(duì)其 TPC-C 工作負(fù)載性能表現(xiàn)產(chǎn)生了顯著影響。OtterTune 與數(shù)據(jù)庫(kù)管理員提供的配置方案可為每一調(diào)節(jié)選項(xiàng)帶來(lái)良好的設(shè)置效果。RDS 的執(zhí)行水平稍差一點(diǎn),在設(shè)置效果上略遜一籌。而 Tuning Script 的配置效果最差——因?yàn)槠渲粚?duì)其中一個(gè)調(diào)節(jié)選項(xiàng)作出了變更。

Postgres 測(cè)試結(jié)果

在延遲方面,OtterTune、調(diào)節(jié)工具、數(shù)據(jù)庫(kù)管理員以及 RDS 所給出的配置建議全部?jī)?yōu)于 Postgres 的默認(rèn)設(shè)置,且提升效果基本類似。我們可以將這一結(jié)果歸結(jié)于 OLTP-Bench 客戶端與 DBMS 之間的往返路由造成了巨大的性能影響。在數(shù)據(jù)吞吐量方面,Postgres 在使用 OtterTune 建議配置時(shí),實(shí)際效果較數(shù)據(jù)庫(kù)管理員及 Tuning Script 配置選項(xiàng)大約提升 12%,而與 RDS 間的比較優(yōu)勢(shì)更是達(dá)到 32%。

與 MySQL 類似,只有少數(shù)幾個(gè)調(diào)節(jié)選項(xiàng)會(huì)對(duì) Postgres 性能產(chǎn)生顯著影響。OtterTune、數(shù)據(jù)庫(kù)管理員、Tuning Script 以及 RDS 所生成的配置都對(duì)這些條目進(jìn)行了修改,且其中多數(shù)能夠帶來(lái)相當(dāng)不錯(cuò)的設(shè)置效果。

總結(jié)意見(jiàn)

OtterTune 能夠以自動(dòng)化方式為 DBMS 各配置選項(xiàng)找到良好的設(shè)置方式。為了對(duì)新的 DBMS 部署系統(tǒng)進(jìn)行調(diào)整,OtterTune 會(huì)使用以往調(diào)優(yōu)會(huì)話當(dāng)中收集到的訓(xùn)練數(shù)據(jù)。由于 OtterTune 并不需要在每次生成操作當(dāng)中再次利用初始數(shù)據(jù)集進(jìn)行機(jī)器學(xué)習(xí)模型訓(xùn)練,因此整個(gè)調(diào)節(jié)時(shí)間周期得到大幅縮減。

未來(lái)的發(fā)展目標(biāo)是什么?為了進(jìn)一步適應(yīng)日益普及的 DBaaS 部署場(chǎng)景(此類場(chǎng)景下,將無(wú)法以遠(yuǎn)程方式訪問(wèn) DBMS 主機(jī)設(shè)備),OtterTune 將很快能夠自動(dòng)檢測(cè)目標(biāo) DBMS 的硬件功能,且無(wú)需進(jìn)行任何遠(yuǎn)程訪問(wèn)。

欲了解更多與 OtterTune 項(xiàng)目相關(guān)的細(xì)節(jié)信息,請(qǐng)點(diǎn)擊此處參閱我們的論文(英文原文)或者 GitHub 上的代碼。亦歡迎大家關(guān)注我們的網(wǎng)站,我們將盡快通過(guò)本網(wǎng)站以在線調(diào)優(yōu)服務(wù)的形式將 OtterTune 交付到您的手中。

鏈接已復(fù)制,快去分享吧

企業(yè)網(wǎng)版權(quán)所有?2010-2024 京ICP備09108050號(hào)-6京公網(wǎng)安備 11010502049343號(hào)