作者簡介：
達娜·範·阿肯（Dana Van Aken）是卡內基·梅隆大學的計算機學博士生，導師是安德魯·帕夫洛博士。
安迪·帕夫洛（Andy Pavlo）是卡內基·梅隆大學的計算機學系資料庫學助理教授。
傑夫·戈登（Geoff Gordon）是卡內基·梅隆大學的副教授兼機器學習系教育部副主任。

本文是由卡內基·梅隆大學的三位嘉賓達娜·範·阿肯（Dana Van Aken）、安迪·帕夫洛（Andy Pavlo）和傑夫·戈登（Geoff Gordon）共同撰寫的文章。該專案演示了學術研究人員如何可以使用AWS Cloud Credits for Research Program（https://aws.amazon.com/research-credits/）來支援其科研突破。

資料庫管理系統（DBMS）是任何資料密集型應用系統中最重要的一個部分。它們可以處理大量的資料和複雜的工作負載。但是由於它們有成百上千個配置“按鈕”（knob），這些配置按鈕控制著諸多因素，比如用於快取的記憶體容量和資料寫入到儲存裝置的頻次，因而管理起來很難。企業組織常常聘請專家幫助調優活動，不過對許多企業來說專家的成本高得離譜。

OtterTune是由卡內基·梅隆大學資料庫小組（http://db.cs.cmu.edu/projects/autotune/）的學生和研究人員開發的一種新工具，它能自動為DBMS的配置按鈕找到合適的設定。目的在於讓任何人都更容易部署DBMS，甚至是資料庫管理方面毫無專長的那些人。

OtterTune有別於其他的DBMS配置工具，原因在於它充分利用從調優之前部署的DBMS獲得的知識來調優新部署的DBMS。這大大減少了調優新部署的DBMS所需要的時間和資源。為此，OtterTune維護一個資料庫，包含從之前的調優會話收集而來的調優資料。它使用該資料來構建機器學習模型，這些模型採集了DBMS對不同配置作出反應的資訊。OtterTune使用這些模型來指導使用者針對新的應用程式進行嘗試，建議使用改善特定目標（比如縮短延遲或提高吞吐量）的設定。

我們在本文中探討了OtterTune的機器學習管道的每個元件，並演示了它們彼此如何聯絡，從而調優DBMS的配置。之後，我們評估了OtterTune對MySQL和Postgres的調優效果：將其最佳配置的效能與資料庫管理員（DBA）及其他自動調優工具選擇的配置作了一番比較。

OtterTune是由卡內基·梅隆大學資料庫小組的學生和研究人員開發的一種開源工具。所有程式碼都放在GitHub上（https://github.com/cmu-db/ottertune），採用了Apache License 2.0這種許可證來發行。

OtterTune的工作原理

下面這張圖顯示了OtterTune的元件及工作流程。

在新的調優會話的開始階段，使用者告訴OtterTune優化哪個特定目標（比如延遲或吞吐量）。客戶端控制器連線至目標DBMS，並收集Amazon EC2例項型別和當前目標。

然後，控制器開始了第一個觀察期，在此期間它觀察DBMS，並記錄特定目標。觀察期結束後，控制器收集來自DBMS的內部度量指標，比如MySQL針對從磁碟讀取的頁面和寫入到磁碟的頁面的計數。控制器將特定目標和內部度量指標都返回給調優管理器。

OtterTune的調優管理器收到度量指標後，將它們儲存在資料庫中。OtterTune使用結果來計算控制器應安裝到目標DBMS上的下一個配置。調優管理器將該配置返回給控制器，並通過實際執行來估計預期的改進。使用者可以決定繼續調優會話，還是終結調優會話。

說明

OtterTune為它支援的每個DBMS版本維護一份按鈕黑名單。該黑名單包括沒必要調優的按鈕（比如DBMS儲存檔案的路徑名稱），或者可能有嚴重後果或隱性後果的按鈕（比如可能會引起DBMS丟失資料）。在每次調優會話的開始階段，OtterTune向用戶提供黑名單，那樣使用者就能新增他們想要OtterTune避免調優的其他任何按鈕。

OtterTune作出某些假設，可能會限制其對一些使用者而言的用處。比如說，它假設使用者擁有管理員許可權，讓控制器可以修改DBMS的配置。如果使用者沒有管理員許可權，那麼他們可以將資料庫的第二個副本部署到其他硬體上，以便OtterTune的調優試驗。這要求使用者重放工作負載跟蹤，或者轉發來自生產級DBMS的查詢。想了解假設和限制方面的完整討論，請參閱我們的論文（http://db.cs.cmu.edu/papers/2017/tuning-sigmod2017.pdf）。

機器學習管道

下面這張圖顯示了資料在通過OtterTune的機器學習管道傳輸時如何加以處理。所有觀察結果都放在OtterTune的資料庫中。

OtterTune先把觀察結果傳送到Workload Characterization元件。該元件識別一小批最準確地採集效能變化和不同工作負載獨特特點的DBMS度量指標。

接下來，Knob Identification元件生成一份按鈕排序表，列出了對DBMS的效能影響最大的按鈕。然後，OtterTune將所有這些資訊饋送給Automatic Tuner。該元件將目標DBMS的工作負載與資料資料庫中最相似的工作負載對應起來，並重復使用該工作負載資料，生成更合適的配置。

現在不妨深入探究機器學習管道中的每一個元件。

Workload Characterization：OtterTune使用DBMS的內部執行時度量指標來描述工作負載的行為特點。這些度量指標準確地表述了工作負載，因為它們採集了執行時行為的許多方面。然而，許多度量指標是冗餘的：一些是以不同單位記錄的同一個度量值，另一些表示DBMS中數值高度關聯的獨立部分。精簡冗餘的度量指標很重要，因為這降低了使用它們的機器學習模型的複雜性。為此，我們基於關聯模式，將DBMS的度量指標分成聚類（cluster）。然後，我們從每個聚類中選擇一個代表性度量指標，具體來說是最靠近聚類中心的那個度量指標。機器學習管道中的後續元件使用這些度量指標。

Knob Identification：DBMS可能有數百個按鈕，但只有一小批按鈕影響DBMS的效能。OtterTune使用一種流行的特徵選擇技術（名為Lasso），決定哪些按鈕顯著影響系統的整體效能。通過將這種技術運用於資料庫中的資料，OtterTune可識別DBMS的按鈕重要性次序。

隨後，OtterTune得決定在建議配置時使用多少個按鈕。使用太多的按鈕大大增加了OtterTune的優化時間。使用太少的按鈕又讓OtterTune無法找到最佳配置。為了使這個過程實現自動化，OtterTune使用了一種增量方法。它逐步增加用於調優會話中的按鈕數量。這種方法讓OtterTune得以為一小批最重要的按鈕探究和優化配置，然後擴大範圍、考慮其他按鈕。

Automatic Tuner：Automated Tuning元件通過在每個觀察期之後執行分兩步走的分析，決定OtterTune應該建議使用哪個配置。

首先，系統使用針對Workload Characterization元件中識別的度量指標的效能資料，從最能表示目標DBMS工作負載的之前調優會話識別工作負載。它將會話的度量指標與來自之前工作負載的度量指標進行比較，看看哪些對不同的按鈕設定有類似的反應。

然後，OtterTune選擇另一個按鈕配置來試一試。它使統計模型適合已收集的資料，以及來自資料庫中最相似的工作負載的資料。該模型讓OtterTune可以預測DBMS使用每一種可能的配置會有怎樣的效能。OtterTune優化下一個配置，在探索（收集資訊來改善模型）和利用（儘可能在特定度量指標方面表現不俗）之間求得平衡。

實現

OtterTune是用Python編寫的。

就Workload Characterization和Knob Identification這兩個元件而言，執行時效能並不是擔心的主要問題，於是我們用scikit-learn實現了對應的機器學習演算法。這些演算法在後臺程序中執行，一旦OtterTune的資料庫中有了新的資料，就會整合新資料。

至於Automatic Tuner，機器學習演算法位於關鍵路徑上。它們在每次觀察期後執行，整合新資料，那樣OtterTune可以選擇一個按鈕配置接下來嘗試。由於效能是個考量因素，我們使用TensorFlow實現了這些演算法。

為了收集DBMS硬體方面的資料、按鈕配置和執行時效能度量指標，我們將OtterTune的控制器與OLTP-Bench基準測試框架整合起來。

嘗試設計

為了評估，我們針對MySQL和Postgres的效能，將OtterTune選擇的最佳配置與下列配置進行了比較：

• 預設：DBMS提供的配置
• 調優指令碼：開源調優顧問工具生成的配置
• DBA：資料庫管理員生成的配置
• RDS：為DBMS定製的配置，由Amazon RD管理，部署在同樣型別的EC2例項上。

我們在Amazon EC2 Spot Instances（現貨例項）上進行了所有的試驗。我們在兩個例項上進行了每次試驗：一個例項用於OtterTune的控制器，另一個用於部署的目標DBMS系統。我們分別使用了m4.large和m3.xlarge例項型別。我們將OtterTune的調優管理器和資料資料庫部署在了搭載20個核心、128GB記憶體的本地伺服器上。

我們使用了TPC-C工作負載，這是評估聯機事務處理（OLTP）系統性能的行業標準。

評估

針對我們在試驗中使用的每個資料庫：MySQL和Postgres，我們測量了延遲和吞吐量。下面幾張圖顯示了結果。第一張圖顯示了第99個百分位延遲的數量，這表示“在最糟糕情況下”事務完成所花的時間。第二張圖顯示了吞吐量的結果，以每秒完成的事務平均數量來測量。

MySQL的結果：

將OtterTune生成的最佳配置與調優指令碼和RDS生成的配置進行比較，就會發現：如果使用OtterTune配置，MySQL的延遲縮短了約60%，吞吐量提升了35%。OtterTune還生成了結果與資料庫管理員選擇的配置一樣好的配置。

少數幾個MySQL的按鈕對TPC-C工作負載的效能有重大影響。OtterTune和資料庫管理員生成的配置為這每一個按鈕提供了很好的設定。由於為一個按鈕提供了未達最佳標準的設定，RDS的表現要遜色一點。由於只修改了一個按鈕，調優指令碼的配置表現最差。

Postgres的結果：

就延遲而言，OtterTune、調優工具、資料庫管理和RDS生成的配置都比Postgres的預設設定有了相似的改進。我們也許可以將這歸因於網路上OLTP-Bench的客戶機和DBMS之間的往返所需要的開銷。至於吞吐量，如果使用OtterTune建議的配置，Postgres的效能比資料庫管理員和調優指令碼選擇的配置高出了約12%，比RDS更是高出了約32%。

類似MySQL，只有少數幾個按鈕對Postgres的效能有重大影響。OtterTune、資料庫管理員、調優指令碼和RDS生成的配置都修改了這些按鈕，大多數提供了相當好的設定。

結束語

OtterTune使得為DBMS的配置按鈕找到合適的設定這個過程實現了自動化。為了調優新部署的DBMS，它重複使用從之前的調優會話收集而來的訓練資料。由於OtterTune不需要生成用於訓練機器學習模型的初始資料集，因而顯著縮短了調優時間。

接下來是什麼？為了適應部署的DBaaS越來越流行這個形勢（無法遠端訪問DBMS的主機系統），OtterTune很快就能夠自動檢測目標DMBS的硬體功能，而不需要遠端訪問。

想了解OtterTune方面的更多細節，請參閱我們的論文或放在GitHub上的程式碼。敬請關注這個網站（http://ottertune.cs.cmu.edu/），我們很快就會推出OtterTune這項線上調優服務。

原文來自微信公眾號：雲頭條