運維要失業了？機器學習可自動優化你的資料庫管理系統

作者簡介：

達娜·范·阿肯（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的硬體功能，而不需要遠程訪問。

雲頭條編譯、未經授權謝絕轉載

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！