一、前言
數據庫管理系統（DBMS）是任何數據密集應用的關鍵部分。它們可以處理大量數據和複雜的工作負載，但同時也難以管理，因爲有成百上千個“旋鈕”（即配置變量）控制着各種要素，比如要使用多少內存做緩存和寫入磁盤的頻率。組織機構經常要僱傭專家來做調優，而專家對很多組織來說太過昂貴了。
卡耐基梅隆大學數據庫研究組的學生和研究人員在開發一個新的工具，名爲 OtterTune，可以自動爲 DBMS 的“旋鈕”找到合適的設置。工具的目的是讓任何人都可以部署 DBMS，即使沒有任何數據庫管理專長。OtterTune 跟其他 DBMS 設置工具不同，因爲它是利用對以前的 DBMS 調優知識來調優新的 DBMS，這顯著降低了所耗時間和資源。OtterTune 通過維護一個之前調優積累的知識庫來實現這一點，這些積累的數據用來構建機器學習（ML）模型，去捕獲 DBMS 對不同的設置的反應。OtterTune 利用這些模型指導新的應用程序實驗，對提升最終目標（比如降低延遲和增加吞吐量）給出建議的配置。
本文中，我們將討論 OtterTune 的每一個機器學習流水線組件，以及它們是如何互動以便調優 DBMS 的設置。然後，我們評估 OtterTune 在 MySQL 和 Postgres 上的調優表現，將它的最優配置與 DBA 和其他自動調優工具進行對比。OtterTune 是卡耐基梅隆大學數據庫研究組的學生和研究人員開發的開源工具，所有的代碼都託管在 Github 上，以 Apache License 2.0 許可證發佈。
二、OtterTune整體架構
OtterTune分爲客戶端和服務端。目標數據庫是用戶需要調優參數的數據庫：
1）OtterTune的客戶端安裝在目標數據庫所在機器上，收集目標數據庫的統計信息，並上傳到服務端。
2）服務端一般配置在雲上，它收到客戶端的數據，訓練機器學習模型並推薦參數文件。
客戶端接到推薦的參數文件後，配置到目標數據庫上，測量其性能。以上步驟可以重複進行直到用戶對OtterTune推薦的參數文件滿意。當用戶配置好OtterTune時，它能自動的持續推薦參數文件並把所得結果上傳到服務端可視化出來，而不需要DBA的干預。這樣能很大簡化DBA的工作，比如DBA可以配置好OtterTune後回家睡覺，第二天早上OtterTune可能就在一晚上的嘗試中找到了好的參數文件。而OtterTune嘗試的所有參數文件及對應的數據庫性能和統計信息都能在服務端的可視化界面上輕易找到。
上圖是OtterTune的整體架構：
1）客戶端中controller由Java實現，用JDBC訪問目標數據庫來收集其統計信息；driver則用了Python的fabric，主要與服務端交互。
2）服務端用了Django來構建網站，並用Celery來調度機器學習任務；機器學習則調了tensorflow和sklearn。
關於OtterTune架構更詳細的內容可以參考2018 VLDB的demo paper[4].
三、OtterTune客戶端
下圖是 OtterTune 客戶端的組件和工作流程
1、調優過程開始，用戶告知 OtterTune 要調優的最終目標（比如，延遲或吞吐量），客戶端控制器程序連接目標 DBMS，收集 Amazon EC2 實例類型和當前配置。
2、然後，控制器啓動首次觀察期，來觀察並記錄最終目標。觀察結束後，控制器收集 DBMS 的內部指標，比如 MySQL 磁盤頁讀取和寫入的計數。控制器將這些數據返回給調優管理器程序。
3、OtterTune 的調優管理器將接收到的指標數據保存到知識庫。OtterTune 用這些結果計算出目標 DBMS 的下一個配置，連同預估的性能提升，返回給控制器。用戶可以決定是否繼續或終止調優過程。
注：OtterTune 對每個支持的 DBMS 版本維護了一份“旋鈕”黑名單，包括了對調優無關緊要的部分（比如保存數據文件的路徑），或者那些會產生嚴重或隱性後果（比如丟數據）的部分。調優過程開始時，OtterTune 會向用戶提供這份黑名單，用戶可以添加他們希望 OtterTune 避開的其它“旋鈕”。OtterTune 有一些預定假設，對某些用戶可能會造成一定的限制。比如，它假設用戶擁有管理員權限，以便控制器來修改 DBMS 配置。否則，用戶必須在其他硬件上部署一份數據庫拷貝給 OtterTune 做調優實驗。這要求用戶或者重現工作負載，或者轉發生產 DBMS 的查詢。完整的預設和限制請看我們的論文 。
四、 OtterTune服務端原理
1、機器學習流水線
下圖是 OtterTune ML流水線處理數據的過程，所有的觀察結果都保存在知識庫中。OtterTune 先將觀察數據輸送到“工作流特徵化組件”（Workload Characterization component），這個組件可以識別一小部分 DBMS 指標，這些指標能最有效地捕捉到性能變化和不同工作負載的顯著特徵。下一步，“旋鈕識別組件”（Knob Identification component）生成一個旋鈕排序表，包含哪些對 DBMS 性能影響最大的旋鈕。OtterTune 接着把所有這些信息“喂”給自動調優器（Automatic Tuner），後者將目標 DBMS 的工作負載與知識庫裏最接近的負載進行映射，重新使用這份負載數據來生成更佳的配置。
我們來深入挖掘以下機器學習流水線的每個組件。
2、 工作負載識別
調優系統的第一步是發現最佳模型代表目標工作量的顯著方面，以便它可以識別存儲庫中之前看到的工作負載與它相似。這使OtterTune能夠利用它從以前調整會話收集的信息，以幫助指導爲新應用程序尋找一個好的參數配置。我們可能會考慮兩種方法來做到這一點。首先是分析邏輯級別的目標工作負載。這意味着檢查查詢和數據庫模式來計算指標，例如每個查詢訪問的表/列的數目和每個交易的讀/寫比率。可以使用以下方式進一步細化這些指標通過DBMS的“假設”優化器API(用於估計額外的運行時間信息)，比如最常訪問哪些索引。然而，這種方法的問題在於它是不可能確定改變某個特定參數的影響，因爲所有這些估計是基於邏輯數據庫而不是查詢的實際運行時的行爲。此外，DBMS如何執行查詢以及這個查詢與內部組件(受調優參數影響)的關係是取決於數據庫的許多因素（例如，大小，基數，工作集大小）。因此，這個信息不可以僅僅通過檢查工作量來捕獲。
更好的方法是使用DBMS的內部運行時指標表徵工作負載的行爲方式。 所有現代DBMS都公開有關係統的大量信息。 例如，MySQL的InnoDB引擎提供了有關數字的統計信息頁面讀/寫數，查詢緩存利用率和鎖開銷。OtterTune使用運行時統計信息來表徵工作負載執行時記錄。 這些指標提供了更多準確表示工作負載，因爲它們捕獲更多其運行時行爲的各個方面。 它們的另一個優點是它們直接受到參數設置的影響。 例如，如果控制DBMS分配的內存量的參數到它的緩衝池太低，那麼這些指標就表明了增加緩衝池緩存未命中數。所有DBMS
提供類似的信息，只是具有不同的名稱和不同的粒度。 但正如我們將展示的那樣，OtterTune的模型構建算法不需要標記指標。
2.1 統計收集
OtterTune的控制器支持模塊化架構它爲不同的DBMS執行適當的操作收集運行時統計信息。在每次觀察週期開始時，控制器首先重置目標DBMS的所有統計數據。然後它在這個週期結束時檢索新的統計數據。從那時起，OtterTune就不知道哪些指標實際上很有用，它收集DBMS的每個數字指標使其可用並將其作爲鍵/值對存儲在其存儲庫中。這個收集過程的主要挑戰是如何表達DBMS和數據庫的子元素的度量標準。一些系統，如MySQL，只報告整個統計數據。但是，其他數據庫系統提供單獨的統計數據針對表或數據庫。商業DBMS甚至保持獨立各個組件的統計信息（例如，IBM DB2對每個緩衝池實例跟蹤統計信息）。這種細粒度數據問題是DBMS提供多個具有相同名稱的指標。一種可能的解決方案是在子元素的名稱前加上前綴到度量標準的名稱。例如，Postgres的數字度量爲表“foo”讀取的塊存儲在存儲庫中如foo.heap_blks_read。但這種方法意味着它無法實現將此度量映射到其他數據庫，因爲它們的表會有所不同的名字。而 OtterTune存儲指標與單個標量值相同的名稱。這是有效的，因爲Otter-Tune目前只考慮全局旋鈕。我們推遲了這個問題調整表格或組件特定的參數作爲未來的工作。
2.2 修剪冗餘監控指標
下一步是自動刪除多餘的指標。刪除這些元素非常重要，因爲使用OtterTune必須考慮捕獲在性能和識別不同工作負載可變性的最小指標集。 減小此集的大小會減少ML算法的搜索空間，反過來加速整個過程和增加了模型適合OtterTune基於內存來調優的可能性。 我們將在後續章節中展示OtterTune可用的指標足以區分在同一硬件上部署的DBMS的不同工作負載。冗餘DBMS指標出於兩個原因。 首先是爲完全相同的度量標準提供不同粒度的那些系統。 例如，MySQL讀取數據量就innodb_data_read和innodb_pages_read而言。這兩個指標是相同的度量只是在不同的單位，因此沒有必要同時考慮他們。其他類型的冗餘指標就是那些指標表示DBMS的獨立組件但其值是強相關的。 例如，我們從實驗中發現更新了元組數量的Postgres度量標準pg_stat_database.tup_updated與衡量數量的指標pg_statio_user_tables.idx_blks_hit幾乎一致。
我們使用兩種經過充分研究的技術進行修剪。 首先是降維技術，稱爲因子分析，講高維DBMS指標轉換爲低維數據。 然後我們使用第二種技術，稱爲k-means ，用於聚類這種低維數據，成爲有意義的羣體。 使用降維技術是許多聚類算法的預處理步驟，因爲它們減少了數據中“噪音”的數量。 這個提高了聚類分析的穩健性和質量。
給定一組包含任意相關的實值變量，FA將這些變量減少到一組較小的因子來捕獲原始變量的相關模式。 每個因素是原始變量的線性組合; 因子係數類似於並且可以用相同的方式解釋線性迴歸中的係數。 此外，每個因素都有單位方差與所有其他因素無關。 這意味着人們可以通過多少變化來排序因子來解釋原始數據。 我們發現只有最初的幾個因素對於我們的DBMS指標數據而言意義重大，這意味着大部分數據可變性由前幾個因素捕獲。
|
|
Config 1 |
Config 2 |
…. |
Config n |
|
Mrtric 1 |
|
|
|
|
|
Mrtric 2 |
|
|
|
|
|
… |
|
|
|
|
|
Mrtric m |
|
|
|
|
然後，我們使用每個指標的一行作爲座標，通過k-means聚類。 我們爲每個類保留一個指標，即最靠近集羣中心的那個。 使用k-means方法的一個缺點是它需要最佳數量的聚類（K）作爲其輸入。 我們使用簡單的啓發式來完全自動化這個選擇過程和近似K.雖然這種方法不保證找到最佳解決方案，它不需要人類手動解釋問題的圖形表示確定最佳簇數。 我們比較了這種啓發式與其他技術[55,48]選擇K和發現他們選擇的值相差一到兩個最接近我們的近似值。 這種變化幾乎沒有差別在OtterTune生成的配置質量方面.
3、旋鈕識別：
DBMS 可以有幾百個旋鈕，但只有一部分影響性能。OtterTune 使用一種流行的“特性-選擇”技術，叫做 Lasso，來判斷哪些旋鈕對系統的整體性能影響最大。用這個技術處理知識庫中的數據，OtterTune 得以確定 DBMS 旋鈕的重要性順序。接着，OtterTune 必須決定在做出配置建議時使用多少個旋鈕，旋鈕用的太多會明顯增加 OtterTune 的調優時間，而旋鈕用的太少則難以找到最好的配置。OtterTune 用了一個增量方法來自動化這個過程，在一次調優過程中，逐步增加使用的旋鈕。這個方法讓 OtterTune 可以先用少量最重要的旋鈕來探索並調優配置，然後再擴大範圍考慮其他旋鈕。
注：lasso迴歸的特色就是在建立廣義線型模型的時候，這裏廣義線型模型包含一維連續因變量、多維連續因變量、非負次數因變量、二元離散因變量、多元離散因變，除此之外，無論因變量是連續的還是離散的，lasso都能處理，總的來說，lasso對於數據的要求是極其低的，所以應用程度較廣；除此之外，lasso還能夠對變量進行篩選和對模型的複雜程度進行降低。這裏的變量篩選是指不把所有的變量都放入模型中進行擬合，而是有選擇的把變量放入模型從而得到更好的性能參數。 複雜度調整是指通過一系列參數控制模型的複雜度，從而避免過度擬合(Overfitting)。 對於線性模型來說，複雜度與模型的變量數有直接關係，變量數越多，模型複雜度就越高。 更多的變量在擬合時往往可以給出一個看似更好的模型，但是同時也面臨過度擬合的危險 。
視頻講解lasso：https://www.bilibili.com/video/av36942687/?p=4
推導公式：Lasso迴歸公式推導
4、自動調優器：
現在，在這一點上，OtterTune有（1）非冗餘的集合指標，（2）最有影響力的配置參數，以及（3）來自先前調整會話的數據存儲在其存儲庫中。OtterTune重複分析了迄今爲止收集的數據會話然後給出下一個配置。 它在調優過程中的每次觀察期完成後執行兩步分析。 在第一步，系統識別來自先前調整會話的哪個工作負載與目標工作量的最相似。 它通過比較這個會話的指標與之前看到的工作負載的指標，來看看與之前哪個配置最相似。 曾經OtterTune已將目標工作負載與其存儲庫中最相似的工作負載相匹配，然後啓動第二步的分析，選擇一個參數配置以最大化目標。 我們現在更詳細地描述這些步驟。
自動調優器組件在每次觀察階段後，通過兩步分析法來決定推薦哪個配置。首先，系統使用工作負載特徵化組件找到的性能數據來確認與當前的目標 DBMS 工作負載最接近的歷史調優過程，比較兩者的度量值以確認哪些值對不同的旋鈕設置有相似的反應。然後，OtterTune 嘗試另一個旋鈕配置，將一個統計模型應用到收集的數據，以及知識庫中最貼近的工作負載數據。這個模型讓 OtterTune 預測 DBMS 在每個可能的配置下的表現。OtterTune 調優下一個配置，在探索（收集用來改進模型的信息）和利用（貪婪地接近目標度量值）之間交替進行。
4.1 工作負載映射
第一步的目標是匹配目標DBMS的工作負載基於所選指標組的值從在數據庫中找到最相似的工作負載。OtterTune所做的匹配質量隨着數目標工作負載收集的數據而增加，，這就是我們想要的期望。 因此，使用動態映射方案優於靜態映射（即在第一個觀察期結束後的一次映射）因爲它使OtterTune能夠做得更多隨着調整會話的進展。矩陣集合()有相同的行和列。n是指標的個數(前面通過因子分析降維和k-means聚類進一步修剪後的指標)。每個指標對應一個矩陣，每個元素含義：某個工作負載在某個參數配置下的該指標的值。如果有多個觀測值，就取中位數。某個指標在不同工作負載和不同配置下的值.
|
|
Config1 |
Config2 |
…. |
Confign |
|
工作負載1 |
|
|
|
|
|
工作負載2 |
|
|
|
|
|
… |
|
|
|
|
|
工作負載m |
|
|
|
|
工作負載映射算法：
1）目標工作負載表徵向量。計算到上面指標對應矩陣的距離，即對應指標到每個工作負載的距離
2）將第一步計算出的每個指標到每個工作負載的距離取平均值，得到目標工作負載到歷史工作負載的距離。
3） 取距離最小的那個的工作負載就是與目標工作負載最相似的
在計算得分之前，所有指標具有相同的數量級至關重要。 否則，得到的分數將是不公平的，因爲任何規模大得多的指標將主導平均距離計算。 OtterTune通過計算每個指標的十分位數，然後根據它們所屬的十進制值對值進行分箱，確保所有度量標準具有相同的數量級。 然後，我們用相應的bin編號替換矩陣中的每個條目。 通過這一額外步驟，我們可以爲Otter-Tune存儲庫中的每個工作負載計算準確且一致的分數。比如某指標值的範圍是1到1000，那麼分成10等份就是1-100,2-200，...,10-1000等。如果某指標值是160，那取值爲2.
5、 配置推薦
OtterTune使用高斯過程（GP）迴歸來推薦它認爲可以改進目標度量的配置。 GP迴歸是一種最先進的技術，其威力大約等於深度網絡的威力。 GP有許多吸引人的功能，使其成爲建模配置空間和提出建議的合適選擇。最重要的是，GP提供了一種理論上合理的方式來權衡探索（即獲取新知識）和利用（即製作） 基於現有知識做出的決定。另一個原因是GP默認情況下會提供置信區間。儘管可以使用自舉等方法來獲取深度網絡和其他不具有範圍的模型的置信區間。 雖然像bootstrapping（自助抽樣）這樣的方法可以用來獲得深度網絡和其他沒有給出它們的模型的置信區間，但它們的計算成本很高，因此對於在線調優服務來說是不可行的
OtterTune通過重用先前選擇的工作負載中的數據來訓練GP模型，從而開始推薦步驟。 它通過添加目前已觀察到的目標工作負載的指標來更新模型。 但由於映射的工作負載與未知工作負載不完全相同，因此係統不完全信任模型的預測。 我們通過增加OtterTune尚未嘗試進行此調整會話的GP模型中所有點的噪聲參數的方差來處理此問題。 也就是說，我們在協方差中添加一個脊項(ridge )。 我們還爲OtterTune選擇的每個配置添加了一個較小的脊線項(ridge )。 這對於“噪聲”虛擬化環境是有幫助的，其中外部DBMS度量（即，吞吐量和時延）從一個觀察週期到下一個觀察週期發生變化。
現在，對於此步驟中的每個觀察期，OtterTune嘗試找到比此會話中迄今爲止所見的最佳配置更好的配置。 它通過（1）搜索GP中的未知區域（即，其幾乎沒有數據的工作負載）或（2）選擇其GP中接近最佳配置的配置來完成此操作。 前一種策略被稱爲探索。 這有助於OtterTune查找配置，其中旋鈕設置爲超出其過去嘗試過的最小值或最大值的值。 這對於嘗試某些參數是有用的，其中上限可能取決於底層硬件（例如，可用的存儲量）。 第二種策略稱爲利用。 這是OtterTune找到了一個很好的配置，它嘗試對參數進行微調，以確定它是否可以進一步提高性能。
在選擇下一個配置時，OtterTune選擇的這兩種策略中的哪一個取決於其GP模型中數據點的方差。 它始終選擇具有最大預期改進的配置。 這種方法背後的直覺是，每次OtterTune嘗試配置時，它“更信任”來自該配置和類似配置的結果，並且其GP中這些數據點的方差減小。 預期的改進在採樣點處接近於零，並且在它們之間增加（儘管可能少量）。 因此，它總是會嘗試一種它認爲最佳的配置或者它的配置
知之甚少。 隨着時間的推移，隨着未知區域數量的減少，GP模型預測的預期改善會下降。 這意味着它將探索其解決方案空間中良好配置周圍的區域，以進一步優化它們。
初始值的選擇：
OtterTune使用梯度下降來找到GP模型預測的表面上的局部最優值，使用一組稱爲初始化集的配置作爲起始點。初始化集中有兩種類型的配置：第一種是在當前調整會話中已完成的最佳性能配置，第二種是在每個參數的有效值範圍內隨機選擇每個參數值的配置。具體地，最佳配置與隨機配置的比率是1比10。在梯度下降的每次迭代期間，優化器在局部最優方向上一步一步走直到它收斂或已經達到其可以採取的最大步數的極限。 OtterTune從優化配置集中選擇最大化潛在改進的配置，以便下次運行。這個搜索過程很快;在我們的實驗中，OtterTune的調優管理器需要10-20秒才能完成每個觀察期的梯度下降搜索。較長時間的搜索沒有產生更好的結果。
與我們在Otter-Tune中使用的其他基於迴歸的模型類似（參見Sects.5.1和6.1），我們採用預處理來確保特徵是連續的並且具有大致相同的比例和範圍。 我們使用虛擬變量對分類特徵進行編碼，並在將其作爲輸入傳遞給GP模型之前標準化所有數據。
一旦OtterTune選擇下一個配置，它就會返回此配置以及從運行此配置到客戶端的預期改進。 DBA可以使用預期的改進計算來確定他們是否滿足OtterTune迄今爲止生成的最佳配置。
6、隨機採樣
爲了敘述方便，我們不妨假設參數文件中有10個重要參數需要調優。我們將參數文件表示爲：X=(x1,x2,…x10)。對應的數據庫性能爲Y。Y可以是吞吐量，延遲時間，也可以是用戶自己定義的測量量。我們假設目標測量量是延遲時間。則我們需要做的是調整這10個數據庫參數的值，使得數據庫的延遲儘可能少。即找到合適的X，使Y儘可能小。一個好的參數文件會降低數據庫的延遲，即X對應的Y越小，我們說X越好。最簡單和直觀的方法便是隨機的進行嘗試，即給這10個要調的參數最大和最小值，在這範圍內隨機地選擇值進行嘗試。顯然這樣隨機的方法並不高效，可能需要試很多次才能得到好的參數文件。OtterTune也支持這種隨機方法以在沒有訓練數據時收集數據。
相比隨機採樣，還有一種更有效率的採樣方法叫做拉丁超立方採樣。比如在0到3之間隨機找3個數，簡單隨機抽樣可能找的三個數都在0到1之間。而拉丁超立方採樣則在0到1間找一個數，1到2間找一個數，2到3間找一個數，更加分散。
推到高維也是類似的情況。如下圖是二維的情形，x1和x2取值都在0到1之間，用拉丁超立方採樣來取5個樣本點，先將x1和x2分成不同的範圍，再取樣本點使得每一行中只有一個樣本點，每一列中也只有一個樣本點。這樣能避免多個樣本點出現在相近的範圍內，使其更加分散。
對於OtterTune來說，簡單隨機採樣嘗試的參數文件可能更集中和相似，而拉丁超立方採樣嘗試的參數文件更分散和不同。顯然後者能給我們更多的信息，因爲嘗試相似的參數文件很可能得到的數據庫性能也相似，信息量少，而嘗試很不同的參數文件能更快的找到效果好的一個。
7、高斯過程迴歸
上述的採樣方法並沒有利用機器學習模型對參數文件的效果進行預測。
1）當OtterTune沒有數據來訓練模型時，可以利用上述方法收集初始數據。
2）當我們有足夠的數據（X,Y）時，OtterTune訓練機器學習模型進行迴歸，即估計出函數f：X→Y，使得對於參數文件X，用f（X）來估計數據庫延遲Y的值。則問題變爲尋找合適的X，使f（X）的值儘量小。這樣我們在f上面做梯度下降即可找出合適的X。
如下圖所示，橫座標是兩個參數——緩存大小和日誌文件大小，縱座標是數據庫延遲（越低越好）：
OtterTune用迴歸模型估計出了f，即給定這兩個參數值，估計出其對應的數據庫延遲。接着用梯度下降找到合適的參數值使延遲儘可能低。 OtterTune用高斯過程迴歸來估計上述的函數f。用高斯迴歸的好處之一是它不僅能在給定X時估計對應的Y值，還能估計它的置信區間。這能恰當的刻畫調參的情況：對於同樣的參數文件X, 在數據庫上多次跑相同的查詢時，由於誤差緣故，每次得到的數據庫性能也可能不一樣。比如同樣的參數文件和查詢語句，這次執行的數據庫延遲是1.8秒，下次執行的延遲可能是2秒，但每次得到的延遲很大概率是相近的。高斯過程迴歸能估計出均值m（X）和標準差s（X），進而能求出置信區間。比如上述例子中，通過迴歸我們估計其延遲的均值是1.9秒，標準差是0.1秒，則其95%的概率在1.7秒和2.1秒之間。
再來說說探索（exploration）和利用（exploitation）：
1）探索即在數據點不多的未知區域探索新的點；
2）利用即在數據點足夠多的已知區域利用這些數據訓練機器學習模型進行估計，再找出好的點。
比如說我們已知10個數據點（X，Y），有9個點的X在0到1之間，有1個點的X在1到2之間。X在0到1之間的數據點較多，可以利用這些數據點進行迴歸來估計f：X->Y，再利用f來找到合適的X使估計的Y值儘量好，這個過程即爲利用。而探索則是嘗試未知區域新的點，如X在1到2間的點只有一個已知點，信息很少，很難估計f。我們在1到2間選一個X點進行嘗試，雖然可能得到的效果不好，但能增加該區域內的信息量。當該區域內已知點足夠多時便能利用迴歸找到好的點了。OtterTune推薦的過程中，既要探索新的區域，也要利用已知區域的數據進行推薦。即需要平衡探索和利用，否則可能會陷入局部最優而無法找到全局最優的點。比如一直利用已知區域的數據來推薦，雖然能找到這個區域最好的點，但未知區域可能有效果更好的點未被發現。如何很好的平衡探索和利用一直是個複雜的問題，既要求能儘量找到好的點，又要求用盡量少的次數找到這個點。而OtterTune採用的高斯過程迴歸能很好的解決這個問題。核心思想是當數據足夠多時，我們利用這些數據推薦；而當缺少數據時，我們在點最少的區域進行探索，探索最未知的區域能給我們最大的信息量。
以上利用了高斯過程迴歸的特性：它會估計出均值m（X）和標準差s（X），若X周圍的數據不多，則它估計的標準差s（X）會偏大，直觀的理解是若數據不多，則不確定性會大，體現在標準差偏大。反之，數據足夠時，標準差會偏小，因爲不確定性減少。而OtterTune用置信區間上界Upper Confidence Bound來平衡探索和利用。不妨假設我們需要找X使Y值儘可能大。則U（X） = m（X） + k*s（X）, 其中k > 0是可調的係數。我們只要找X使U（X）儘可能大即可。
1）若U（X）大，則可能m（X）大，也可能s（X）大。
2）若s（X）大，則說明X周圍數據不多，OtterTune在探索未知區域新的點。
3）若m（X）大，即估計的Y值均值大， 則OtterTune在利用已知數據找到效果好的點。公式中係數k影響着探索和利用的比例，k越大，越鼓勵探索新的區域。
8、有數據和沒數據
OtterTune用來訓練模型的數據好壞很大程度上影響了其最終效果。只要有合適的訓練數據，一般OtterTune前幾次推薦的參數文件就能得到理想的效果。而當缺少訓練數據（或數據集中），甚至沒有任何之前的數據時，OtterTune又該如何處理?當OtterTune沒有任何數據時，高斯過程迴歸也能有效的在儘量少的次數內找到好的參數文件。當數據少時，OtterTune傾向探索而非利用，而每次探索新的參數文件時都能儘量的增加信息量，從而減少探索的次數。這種方法比隨機採樣和拉丁超立方採樣都要高效。同時OtterTune也可先用拉丁超立方採樣選取少量的一些參數文件進行嘗試作爲初始數據，之後再用高斯過程迴歸進行推薦。其實在OtterTune之前，有系統iTuned[5]就用高斯過程迴歸在沒有數據時推薦參數文件。而OtterTune的最大的改進是利用之前收集的數據進行推薦以大幅度減少嘗試的次數和等待時間，提高推薦效果。想想看當OtterTune的一個服務端配置到雲上，而多個客戶端進行訪問時，OtterTune會將所有用戶嘗試的參數文件和對應的性能數據存下來進行利用。這意味着用OtterTune的人越多，用的時間越長，它收集的訓練數據越多，推薦效果越好。
除此之外，OtterTune還利用Lasso迴歸來自動的選取需要調整的重要參數。數據庫有成百上千的參數，而我們只要調其中重要的幾個，需要調整哪些參數可以根據DBA的經驗，同時OtterTune也利用機器學習將參數的重要性排序，從而選出最重要的幾個參數。另外對於不同的工作負載，對應的最優參數文件也不同。如OLTP工作負載通常是很多個簡單的查詢（如insert，delete），而OLAP工作負載通常是幾個複雜查詢（通常有多個表的join）。對於OLAP和OLTP，他們需要調整的參數和最優的值都不相同。OtterTune現在的做法是用一些系統的統計量（如讀/寫的字節數）來刻畫工作負載，在已有數據中找到和用戶工作負載最相似的一個，然後用最相似的工作負載對應的數據進行推薦。
9、深度強化學習
在OtterTune最新的進展中，我們嘗試了深度強化學習的方法來進行數據庫調參，因爲我們發現數據庫調參的過程能很好的刻畫成強化學習的問題。強化學習問題中有狀態、動作，以及環境所給予的反饋。如下圖所示，整個過程是在當前狀態(st)和環境的反饋(rt)下做動作(at)，然後環境會產生下一狀態(st+1)和反饋(rt+1)，再進行下一個動作(at+1)。
數據庫調參過程中，狀態即是參數文件，動作即是調整某個參數的值，而反饋即是參數文件下數據庫的性能。所以我們對於當前的參數文件，調整某個參數的值，而得到新的參數文件，對這個新的參數文件做測試得到對應的數據庫性能，再根據性能的好壞繼續調整參數的值。這樣數據庫調參的過程就被很好的刻畫成強化學習的問題，而深度強化學習即是其中的狀態或動作由神經網絡來表示。我們用了Deep Deterministic Policy Gradient （DDPG）算法，主要是因爲DDPG能允許動作可以在連續的區間上取值。對於調參來說，動作即是調整某個參數的值，比如調整內存容量，DDPG允許我們嘗試128MB到16GB的任意值，這個區間是連續的。而很多別的算法只允許動作在離散區間上，比如只允許取幾個值中的一個值。通過實現和優化DDPG，最終深度強化學習推薦出的參數文件與高斯過程迴歸推薦出的效果相似。但我們發現之前的高斯過程迴歸（GPR）更有優勢，能用更少的時間和次數找到滿意的參數文件。如下圖中所示，我們跑了TPC-H基準中的一條查詢（Query 13），OtterTune一次次的推薦參數文件直到其達到好的效果（即對應的數據庫延遲變低）。
該圖橫座標是推薦的次數，縱座標是數據庫的延遲，延遲越低越好。藍線是深度強化學習，而黃線代表高斯過程迴歸模型。可見兩個模型最終推薦出的文件效果相似，但高斯過程迴歸用了更少的次數便收斂，推薦出了好的參數文件。而深度強化學習需要嘗試更多的次數才能達到類似效果。
我們發現：
1）DDPG算法模型有一些參數也需要調整，而這些參數對效果的影響很大。調整算法模型的參數也是個費時費力的過程。這樣就陷入尷尬的局面，OtterTune是用來自動調整數據庫參數的工具，而OtterTune自己算法模型的參數也需要調整。相比而言，GPR的模型參數可以自動的進行調整，從而實現OtterTune真正的自動化。
2）GPR能用Upper Confidence Bound更好的平衡探索（exploration）和利用（exploitation），相比DDPG更加高效。 這在沒有或缺少數據的情況下，GPR能用更少的次數找到好的參數文件。
3）DDPG是更加複雜的模型，其中還有神經網絡，可解釋性差。需要更多的數據和更長的時間來訓練和收斂。雖然最後能達到和GPR一樣的推薦效果，但往往需要更多的次數和更長的時間，意味着用戶需要等更久才能得到滿意的參數文件。
五、代碼實現
OtterTune 用 Python 編寫。對於工作負載特徵化和旋鈕識別組件，運行時性能不是着重考慮的，所以我們用 scikit-learn實現對應的機器學習算法。這些算法運行在後臺進程中，把新生成的數據吸收到知識庫裏。對於自動調優組件，機器學習算法就非常關鍵了。每次觀察階段完成後就需要運行，吸收新數據以便 OtterTune 挑選下一個旋鈕來進行測試。由於需要考慮性能，我們用 TensorFlow來實現。爲了收集 DBMS 的硬件、旋鈕配置和運行時性能指標，我們把 OLTP-Bench 基準測試框架集成到 OtterTune 的控制器內。代碼結構參見文章：https://blog.csdn.net/weixin_40449300/article/details/87881045
六、實驗設計
我們比較了 OtterTune 對 MySQL 和 Postgres 做出的最佳配置與如下配置方案進行了比較，以便評估：
- 默認： DBMS 初始配置
- 調優腳本： 一個開源調優建議工具做出的配置
- DBA： 人類 DBA 選擇的配置
- RDS： 將亞馬遜開發人員管理的 DBMS 的定製配置應用到相同的 EC2 實例類型。
我們在亞馬遜 EC2 競價實例上執行了所有的實驗。每個實驗運行在兩個實例上，分別是m4.large 和 m3.xlarge 類型：一個用於 OtterTune 控制器，一個用於目標 DBMS 部署。OtterTune 調優管理器和知識庫部署在本地一臺 20 核 128G 內存的服務器上。工作負載用的是 TPC-C，這是評估聯機交易系統性能的工業標準。
實驗環境搭建參見文章：https://blog.csdn.net/weixin_40449300/article/details/87904128
七、評估
我們給每個實驗中的數據庫 —— MySQL 和 Postgres —— 測量了延遲和吞吐量，下面的圖表顯示了結果。第一個圖表顯示了“第99百分位延遲”的數量，代表“最差情況下”完成一個事務的時長。第二個圖表顯示了吞吐量結果，以平均每秒執行的事務數來衡量。
1、mysql實驗結果
OtterTune 生成的最佳配置與調優腳本和 RDS 的配置相比，OtterTune 讓 MySQL 的延遲下降了大約 60%，吞吐量提升了 22% 到 35%。OtterTune 還生成了一份幾乎跟 DBA 一樣好的配置。在 TPC-C 負載下，只有幾個 MySQL 的旋鈕顯著影響性能。OtterTune 和 DBA 的配置給這幾個旋鈕設置了很好的值。RDS 表現略遜一籌，因爲給一個旋鈕配置了欠佳的值。調優腳本表現最差，因爲只修改一個旋鈕。
2、Postgres 實驗結果
在延遲方面，相比 Postgres 默認配置，OtterTune、調優工具、DBA 和 RDS 的配置獲得了近似的提升。我們大概可以把這歸於 OLTP-Bench 客戶端和 DBMS 之間的網絡開銷。吞吐量方面，Postgres 在 OtterTune 的配置下比 DBA 和調優腳本要高 12%，比 RDS 要高 32%。
八、結束語
對於數據庫來說，有很多部分都能嘗試與機器學習結合。比如預測數據庫一段時間的工作負載，如通過挖掘數據庫的日誌來做自動預警，再到更核心的部分，如學習數據庫索引，甚至幫助優化器做查詢優化。
我們發現這個通用模型在業界的很多地方都有真實的應用，不僅能調優數據庫的參數，還能夠調優操作系統內核的參數，甚至可以嘗試調優機器學習模型的參數。比如以下場景：
1）某歐洲銀行需要自動化調優數據庫集羣的參數以提高性能，減少人工成本。
2）某大型雲廠商需要在不影響性能的前提下儘量調低分配的資源（如內存）, 減少硬件成本。
3）某紐約高頻交易公司需要調優機器的操作系統參數以優化機器性能，減少延遲，從而增加利潤。
OtterTune專注的參數文件調優只是其中的一部分。由於OtterTune和數據庫的交互只是一個參數文件，這使得該工具更加通用，理論上能適用於所有的數據庫。當要調參一個新的數據庫時，我們只需要給OtterTune該數據庫的一些參數和統計量信息即可，不需要去改動這個數據庫的任何代碼。再者，OtterTune的通用框架也可以用於其他系統的調參，如我們嘗試用OtterTune來調優操作系統的內核參數也取得了不錯的效果。現在的OtterTune仍有要改進的地方：
1）比如假定了硬件配置需要一樣，而我們希望OtterTune能利用在不同的硬件配置上的數據來訓練模型進行推薦。
2）再比如現在OtterTune每次只推薦一個文件，當有多個相同機器時，我們希望一次推薦多個文件並行的去嘗試，這樣能加快推薦速度。
另外還可以嘗試與其他部分的機器學習方法結合，比如可以先用機器學習方法預測工作負載，再根據預測的工作負載提前調優參數文件。用機器學習來優化系統是最近很火很前沿的一個話題，無論是在工業界還是在學術界。
全球最大數據庫廠商Oracle如今的最大賣點便是autonomous database[6] ，即自適應性數據庫，利用機器學習來自動優化數據庫來減少DBA的干預，要知道在美國僱一個資深的DBA是多麼困難的一件事。Oracle投入大量的專家和資金來做這件事便證明了它的工業價值。學術上，一些ML和系統的大佬在前兩年開了一個新的會議叫SysML[7]，專注於機器學習和系統的交叉領域。更不用說越來越多的相關論文，比如卡內基梅隆大學的OtterTune，再如MIT和谷歌開發的用神經網絡學習數據庫的索引[8]。
OtterTune 將尋找 DBMS 配置旋鈕的最優值這一過程自動化了。它通過重用之前的調優過程收集的訓練數據，來調優新部署的 DBMS。因爲 OtterTune 不需要生成初始化數據集來訓練它的機器學習模型，調優時間得以大大減少。下一步會怎麼樣？ 爲了順應的越來越流行的 DBaaS （遠程登錄 DBMS 主機是不可能的），OtterTune 會很快能夠自動探查目標 DBMS 的硬件能力，而不需要遠程登錄。
【參考文章】
[1] 伯樂在線 - Panblack 翻譯。譯文：http://blog.jobbole.com/111486/
[2] https://github.com/cmu-db/ottertune
[3] Automatic Database Management System Tuning Through Large-scale Machine Learning. Dana Van Aken, Andrew Pavlo, Geoffrey J. Gordon, Bohan Zhang. SIGMOD 2017
[4] A Demonstration of the OtterTune Automatic Database Management System Tuning Service. Bohan Zhang, Dana Van Aken, Justin Wang, Tao Dai, Shuli Jiang, Jacky Lao, Siyuan Sheng, Andrew Pavlo, Geoffrey J. Gordon. VLDB 2018
[5] Tuning Database Configuration Parameters with iTuned. Songyun Duan, Vamsidhar Thummala, Shivnath Babu. VLDB 2009
[6] https://www.oracle.com/database/what-is-autonomous-database.html
[8] The Case for Learned Index Structures. Tim Kraska, Alex Beutel, Ed H. Chi, Jeffrey Dean, Neoklis Polyzotis. SIGMOD 2018
[9] http://learningsys.org/nips17/assets/slides/dean-nips17.pdf
[11] https://mp.weixin.qq.com/s/y8VIieK0LO37SjRRyPhtrw
[12] https://blog.csdn.net/u013385018/article/details/84028360