本文是由卡內(nèi)基·梅隆大學(xué)的三位嘉賓達(dá)娜·范·阿肯（Dana Van Aken）、安迪·帕夫洛（Andy Pavlo）和杰夫·戈登（Geoff Gordon）共同撰寫(xiě)的文章。該項(xiàng)目演示了學(xué)術(shù)研究人員如何可以使用AWS Cloud Credits for Research Program（）來(lái)支持其科研突破。
OtterTune是由卡內(nèi)基·梅隆大學(xué)數(shù)據(jù)庫(kù)小組（）的學(xué)生和研究人員開(kāi)發(fā)的一種新工具，它能自動(dòng)為DBMS的配置按鈕找到合適的設(shè)置。目的在于讓任何人都更容易部署DBMS，甚至是數(shù)據(jù)庫(kù)管理方面毫無(wú)專長(zhǎng)的那些人。
OtterTune有別于其他的DBMS配置工具，原因在于它充分利用從調(diào)優(yōu)之前部署的DBMS獲得的知識(shí)來(lái)調(diào)優(yōu)新部署的DBMS。這大大減少了調(diào)優(yōu)新部署的DBMS所需要的時(shí)間和資源。為此，OtterTune維護(hù)一個(gè)資料庫(kù)，包含從之前的調(diào)優(yōu)會(huì)話收集而來(lái)的調(diào)優(yōu)數(shù)據(jù)。它使用該數(shù)據(jù)來(lái)構(gòu)建機(jī)器學(xué)習(xí)模型，這些模型采集了DBMS對(duì)不同配置作出反應(yīng)的信息。OtterTune使用這些模型來(lái)指導(dǎo)用戶針對(duì)新的應(yīng)用程序進(jìn)行嘗試，建議使用改善特定目標(biāo)（比如縮短延遲或提高吞吐量）的設(shè)置。
我們?cè)诒疚闹刑接懥薕tterTune的機(jī)器學(xué)習(xí)管道的每個(gè)組件，并演示了它們彼此如何聯(lián)系，從而調(diào)優(yōu)DBMS的配置。之后，我們?cè)u(píng)估了OtterTune對(duì)MySQL和Postgres的調(diào)優(yōu)效果：將其配置的性能與數(shù)據(jù)庫(kù)管理員（DBA）及其他自動(dòng)調(diào)優(yōu)工具選擇的配置作了一番比較。
OtterTune是由卡內(nèi)基·梅隆大學(xué)數(shù)據(jù)庫(kù)小組的學(xué)生和研究人員開(kāi)發(fā)的一種開(kāi)源工具。所有代碼都放在GitHub上（），采用了Apache License 2.0這種許可證來(lái)發(fā)行。
工作原理下面這張圖顯示了OtterTune的組件及工作流程。
在新的調(diào)優(yōu)會(huì)話的開(kāi)始階段，用戶告訴OtterTune優(yōu)化哪個(gè)特定目標(biāo)（比如延遲或吞吐量）。客戶端控制器連接至目標(biāo)DBMS，并收集Amazon EC2實(shí)例類型和當(dāng)前目標(biāo)。
然后，控制器開(kāi)始了第一個(gè)觀察期，在此期間它觀察DBMS，并記錄特定目標(biāo)。觀察期結(jié)束后，控制器收集來(lái)自DBMS的內(nèi)部度量指標(biāo)，比如MySQL針對(duì)從磁盤(pán)讀取的頁(yè)面和寫(xiě)入到磁盤(pán)的頁(yè)面的計(jì)數(shù)。控制器將特定目標(biāo)和內(nèi)部度量指標(biāo)都返回給調(diào)優(yōu)管理器。
OtterTune的調(diào)優(yōu)管理器收到度量指標(biāo)后，將它們存儲(chǔ)在資料庫(kù)中。OtterTune使用結(jié)果來(lái)計(jì)算控制器應(yīng)安裝到目標(biāo)DBMS上的下一個(gè)配置。調(diào)優(yōu)管理器將該配置返回給控制器，并通過(guò)實(shí)際運(yùn)行來(lái)估計(jì)預(yù)期的改進(jìn)。用戶可以決定繼續(xù)調(diào)優(yōu)會(huì)話，還是終結(jié)調(diào)優(yōu)會(huì)話。
說(shuō)明OtterTune為它支持的每個(gè)DBMS版本維護(hù)一份按鈕黑名單。該黑名單包括沒(méi)必要調(diào)優(yōu)的按鈕（比如DBMS存儲(chǔ)文件的路徑名稱），或者可能有嚴(yán)重后果或隱性后果的按鈕（比如可能會(huì)引起DBMS丟失數(shù)據(jù)）。在每次調(diào)優(yōu)會(huì)話的開(kāi)始階段，OtterTune向用戶提供黑名單，那樣用戶就能添加他們想要OtterTune避免調(diào)優(yōu)的其他任何按鈕。
OtterTune作出某些假設(shè)，可能會(huì)限制其對(duì)一些用戶而言的用處。比如說(shuō)，它假設(shè)用戶擁有管理員權(quán)限，讓控制器可以修改DBMS的配置。如果用戶沒(méi)有管理員權(quán)限，那么他們可以將數(shù)據(jù)庫(kù)的第二個(gè)副本部署到其他硬件上，以便OtterTune的調(diào)優(yōu)試驗(yàn)。這要求用戶重放工作負(fù)載跟蹤，或者轉(zhuǎn)發(fā)來(lái)自生產(chǎn)級(jí)DBMS的查詢。想了解假設(shè)和限制方面的完整討論，請(qǐng)參閱我們的論文（）。
機(jī)器學(xué)習(xí)管道下面這張圖顯示了數(shù)據(jù)在通過(guò)OtterTune的機(jī)器學(xué)習(xí)管道傳輸時(shí)如何加以處理。所有觀察結(jié)果都放在OtterTune的資料庫(kù)中。
OtterTune先把觀察結(jié)果傳送到Workload Characterization組件。該組件識(shí)別一小批最準(zhǔn)確地采集性能變化和不同工作負(fù)載獨(dú)特特點(diǎn)的DBMS度量指標(biāo)。
接下來(lái)，Knob Identification組件生成一份按鈕排序表，列出了對(duì)DBMS的性能影響最大的按鈕。然后，OtterTune將所有這些信息饋送給Automatic Tuner。該組件將目標(biāo)DBMS的工作負(fù)載與數(shù)據(jù)資料庫(kù)中最相似的工作負(fù)載對(duì)應(yīng)起來(lái)，并重復(fù)使用該工作負(fù)載數(shù)據(jù)，生成更合適的配置。
現(xiàn)在不妨深入探究機(jī)器學(xué)習(xí)管道中的每一個(gè)組件。
Workload Characterization：OtterTune使用DBMS的內(nèi)部運(yùn)行時(shí)度量指標(biāo)來(lái)描述工作負(fù)載的行為特點(diǎn)。這些度量指標(biāo)準(zhǔn)確地表述了工作負(fù)載，因?yàn)樗鼈儾杉诉\(yùn)行時(shí)行為的許多方面。然而，許多度量指標(biāo)是冗余的：一些是以不同單位記錄的同一個(gè)度量值，另一些表示DBMS中數(shù)值高度關(guān)聯(lián)的獨(dú)立部分。精簡(jiǎn)冗余的度量指標(biāo)很重要，因?yàn)檫@降低了使用它們的機(jī)器學(xué)習(xí)模型的復(fù)雜性。為此，我們基于關(guān)聯(lián)模式，將DBMS的度量指標(biāo)分成聚類（cluster）。然后，我們從每個(gè)聚類中選擇一個(gè)代表性度量指標(biāo)，具體來(lái)說(shuō)是最靠近聚類中心的那個(gè)度量指標(biāo)。機(jī)器學(xué)習(xí)管道中的后續(xù)組件使用這些度量指標(biāo)。
Knob Identification：DBMS可能有數(shù)百個(gè)按鈕，但只有一小批按鈕影響DBMS的性能。OtterTune使用一種流行的特征選擇技術(shù)（名為L(zhǎng)asso），決定哪些按鈕顯著影響系統(tǒng)的整體性能。通過(guò)將這種技術(shù)運(yùn)用于資料庫(kù)中的數(shù)據(jù)，OtterTune可識(shí)別DBMS的按鈕重要性次序。
隨后，OtterTune得決定在建議配置時(shí)使用多少個(gè)按鈕。使用太多的按鈕大大增加了OtterTune的優(yōu)化時(shí)間。使用太少的按鈕又讓OtterTune無(wú)法找到配置。為了使這個(gè)過(guò)程實(shí)現(xiàn)自動(dòng)化，OtterTune使用了一種增量方法。它逐步增加用于調(diào)優(yōu)會(huì)話中的按鈕數(shù)量。這種方法讓OtterTune得以為一小批最重要的按鈕探究和優(yōu)化配置，然后擴(kuò)大范圍、考慮其他按鈕。
Automatic Tuner：Automated Tuning組件通過(guò)在每個(gè)觀察期之后執(zhí)行分兩步走的分析，決定OtterTune應(yīng)該建議使用哪個(gè)配置。
首先，系統(tǒng)使用針對(duì)Workload Characterization組件中識(shí)別的度量指標(biāo)的性能數(shù)據(jù)，從最能表示目標(biāo)DBMS工作負(fù)載的之前調(diào)優(yōu)會(huì)話識(shí)別工作負(fù)載。它將會(huì)話的度量指標(biāo)與來(lái)自之前工作負(fù)載的度量指標(biāo)進(jìn)行比較，看看哪些對(duì)不同的按鈕設(shè)置有類似的反應(yīng)。
然后，OtterTune選擇另一個(gè)按鈕配置來(lái)試一試。它使統(tǒng)計(jì)模型適合已收集的數(shù)據(jù)，以及來(lái)自資料庫(kù)中最相似的工作負(fù)載的數(shù)據(jù)。該模型讓OtterTune可以預(yù)測(cè)DBMS使用每一種可能的配置會(huì)有怎樣的性能。OtterTune優(yōu)化下一個(gè)配置，在探索（收集信息來(lái)改善模型）和利用（盡可能在特定度量指標(biāo)方面表現(xiàn)不俗）之間求得平衡。
實(shí)現(xiàn)OtterTune是用Python編寫(xiě)的。
就Workload Characterization和Knob Identification這兩個(gè)組件而言，運(yùn)行時(shí)性能并不是擔(dān)心的主要問(wèn)題，于是我們用scikit-learn實(shí)現(xiàn)了對(duì)應(yīng)的機(jī)器學(xué)習(xí)算法。這些算法在后臺(tái)進(jìn)程中運(yùn)行，一旦OtterTune的資料庫(kù)中有了新的數(shù)據(jù)，就會(huì)整合新數(shù)據(jù)。
至于Automatic Tuner，機(jī)器學(xué)習(xí)算法位于關(guān)鍵路徑上。它們?cè)诿看斡^察期后運(yùn)行，整合新數(shù)據(jù)，那樣OtterTune可以選擇一個(gè)按鈕配置接下來(lái)嘗試。由于性能是個(gè)考量因素，我們使用TensorFlow實(shí)現(xiàn)了這些算法。
為了收集DBMS硬件方面的數(shù)據(jù)、按鈕配置和運(yùn)行時(shí)性能度量指標(biāo)，我們將OtterTune的控制器與OLTP-Bench基準(zhǔn)測(cè)試框架整合起來(lái)。
評(píng)估為了評(píng)估，我們針對(duì)MySQL和Postgres的性能，將OtterTune選擇的配置與下列配置進(jìn)行了比較：
- 默認(rèn)：DBMS提供的配置
- 調(diào)優(yōu) ：開(kāi)源調(diào)優(yōu)顧問(wèn)工具生成的配置
- DBA：數(shù)據(jù)庫(kù)管理員生成的配置
- RDS：為DBMS定制的配置，由Amazon RD管理，部署在同樣類型的EC2實(shí)例上。
我們?cè)贏mazon EC2 Spot Instances（現(xiàn)貨實(shí)例）上進(jìn)行了所有的試驗(yàn)。我們?cè)趦蓚€(gè)實(shí)例上進(jìn)行了每次試驗(yàn)：一個(gè)實(shí)例用于OtterTune的控制器，另一個(gè)用于部署的目標(biāo)DBMS系統(tǒng)。我們分別使用了m4.large和m3.xlarge實(shí)例類型。我們將OtterTune的調(diào)優(yōu)管理器和數(shù)據(jù)資料庫(kù)部署在了搭載20個(gè)核心、128GB內(nèi)存的本地服務(wù)器上。
我們使用了TPC-C工作負(fù)載，這是評(píng)估聯(lián)機(jī)事務(wù)處理（OLTP）系統(tǒng)性能的行業(yè)標(biāo)準(zhǔn)。
針對(duì)我們?cè)谠囼?yàn)中使用的每個(gè)數(shù)據(jù)庫(kù)：MySQL和Postgres，我們測(cè)量了延遲和吞吐量。下面幾張圖顯示了結(jié)果。第一張圖顯示了第99個(gè)百分位延遲的數(shù)量，這表示“在最糟糕情況下”事務(wù)完成所花的時(shí)間。第二張圖顯示了吞吐量的結(jié)果，以每秒完成的事務(wù)平均數(shù)量來(lái)測(cè)量。
MySQL的結(jié)果：
將OtterTune生成的配置與調(diào)優(yōu)和RDS生成的配置進(jìn)行比較，就會(huì)發(fā)現(xiàn)：如果使用OtterTune配置，MySQL的延遲縮短了約60%，吞吐量提升了35%。OtterTune還生成了結(jié)果與數(shù)據(jù)庫(kù)管理員選擇的配置一樣好的配置。
少數(shù)幾個(gè)MySQL的按鈕對(duì)TPC-C工作負(fù)載的性能有重大影響。OtterTune和數(shù)據(jù)庫(kù)管理員生成的配置為這每一個(gè)按鈕提供了很好的設(shè)置。由于為一個(gè)按鈕提供了未達(dá)標(biāo)準(zhǔn)的設(shè)置，RDS的表現(xiàn)要遜色一點(diǎn)。由于只修改了一個(gè)按鈕，調(diào)優(yōu)腳本的配置表現(xiàn)最差。
Postgres的結(jié)果：
就延遲而言，OtterTune、調(diào)優(yōu)工具、數(shù)據(jù)庫(kù)管理和RDS生成的配置都比Postgres的默認(rèn)設(shè)置有了相似的改進(jìn)。我們也許可以將這歸因于網(wǎng)絡(luò)上OLTP-Bench的客戶機(jī)和DBMS之間的往返所需要的開(kāi)銷。至于吞吐量，如果使用OtterTune建議的配置，Postgres的性能比數(shù)據(jù)庫(kù)管理員和調(diào)優(yōu)腳本選擇的配置高出了約12%，比RDS更是高出了約32%。
類似MySQL，只有少數(shù)幾個(gè)按鈕對(duì)Postgres的性能有重大影響。OtterTune、數(shù)據(jù)庫(kù)管理員、調(diào)優(yōu)腳本和RDS生成的配置都修改了這些按鈕，大多數(shù)提供了相當(dāng)好的設(shè)置。
結(jié)束語(yǔ)OtterTune使得為DBMS的配置按鈕找到合適的設(shè)置這個(gè)過(guò)程實(shí)現(xiàn)了自動(dòng)化。為了調(diào)優(yōu)新部署的DBMS，它重復(fù)使用從之前的調(diào)優(yōu)會(huì)話收集而來(lái)的訓(xùn)練數(shù)據(jù)。由于OtterTune不需要生成用于訓(xùn)練機(jī)器學(xué)習(xí)模型的初始數(shù)據(jù)集，因而顯著縮短了調(diào)優(yōu)時(shí)間。
接下來(lái)是什么？為了適應(yīng)部署的DBaaS越來(lái)越流行這個(gè)形勢(shì)（無(wú)法遠(yuǎn)程訪問(wèn)DBMS的主機(jī)系統(tǒng)），OtterTune很快就能夠自動(dòng)檢測(cè)目標(biāo)DMBS的硬件功能，而不需要遠(yuǎn)程訪問(wèn)。
想了解OtterTune方面的更多細(xì)節(jié)，請(qǐng)參閱我們的論文或放在GitHub上的代碼。敬請(qǐng)關(guān)注這個(gè)網(wǎng)站（），我們很快就會(huì)推出OtterTune這項(xiàng)在線調(diào)優(yōu)服務(wù)。
