概述
最近幾年，特别是随着雲計算的發展，出現了行業向後重疊和推動的情況。資料庫龍頭企業Oracle最近幾年重點轉而向雲的變革，它全力以赴在做的一件事情就是把所有的産品和服務轉移到雲上來。雲技術改變了資料庫領領域的競争格局，而雲時代的DBA，則面臨着自後向前置的運維變化。
資料庫管理系統（簡稱 DBMS）無疑是任何資料密集型應用程式當中最為重要的組成部分，其肩負着處理大量資料以及高複雜性工作負載的重任。然而，資料庫管理系統本身卻往往難于管理，因為其中通常包含數百種配置“旋鈕”，用于控制諸如緩存記憶體配置設定量以及存儲媒體資料寫入頻率等要素。各類企業一般需要聘請專業人士以協助相關調配工作，但對于大多數企業而言，此類專業人才的開價亦相當高昂。而實際上，DBA所面臨的挑戰還遠不止這些。
而今天一則名為“OtterTune”的機器學習DBMS系統刷爆了朋友圈。那麼，這個由亞馬遜和卡内基梅隆大學一起開發的DBMS系統究竟是什麼呢？能提供什麼服務呢？其實OtterTune并不是多麼驚奇的系統，不過是自動化方式識别出最适當目前資料庫管理系統配置需求的設定組合。OtterTune 與其它 DBMS 配置工具之間的主要差别在于，其能夠利用自此前 DBMS 部署工作當中積累到的知識指導新系統的配置工作。這一設計思路顯然降低了新 DBMS 部署方案在調整當中所需要的時間與資源投入。而為了實作這一目标，OtterTune 專門建立起一套資料庫，用以收集從此前調節會話中提取到的重要資訊。其利用這部分資料建立機器學習（簡稱 ML）模型，用以捕捉 DBMS 在面對不同配置方案時作出怎樣的響應。OtterTune 還利用這些模型以指導新型應用程式的配置實驗，并提供推薦設定以提升目标運作效果（例如減少延遲或者提高資料吞吐量）。
雖然OtterTune隻是一個結合了機器學習(模組化、調參數、擷取系統反應、學習、産生最優參數；典型的臨床學)，可用于參數優化的小軟體(實際上DBA的工作遠不止這些)，但是已經代表了一個方向，未來越來越多的活（枯燥的活）可能會被AI取代。但是現階段很多DBA很多離不開人的幹預。
人類DBA VS機器DBA
首先，我們看看DBA的工作有哪些？DBA的工作實際上都是圍繞資料庫展開，包含但不限于這些工作：
- 資料庫、主機、作業系統、交換機、存儲選型，預算，架構設計，部署，參數優化；
- 資料庫備份、恢複、容災、HA、新老硬體更替；
- 資料庫SQL審計、SQL優化、異常問題診斷、性能優化、巡檢、健康診斷；
- 資料庫擴容、縮容、遷移；
- 資料庫版本更新、更新檔修複；
- 資料庫開發規範、管理規範的指定和執行；
- 資料庫監控、專家、稽核系統的開發與建立；
- 資料庫代碼覆寫率測試、功能測試、模組化、壓測、profiling；
- 資料庫讀寫分離、sharding、MPP系統的建構；
- 資料庫開發、管理、設計、規範教育訓練；
- 資料庫在垂直行業應用的架構設計（例如OLAP、GIS、時序、流計算、圖式搜尋、文本搜尋、圖搜尋、化學、基因、等）；
- 異構資料、同構資料源的資料同步、ETL；
- 資料庫與其他系統的關聯；
- 資料庫雲産品化、DOCKER化、虛拟化等相關的工作；
- 資料庫核心的研究、BUG上報、結合業務提出對核心的功能、性能提升等需求；
- 關注不同資料庫産品的roadmap、優缺點、适應場景、不适應場景；
- 關注資料庫行業的發展，進行預研性研究，儲備技術；
- 與技術社群保持緊密聯系，從參與、了解同行、到分享，從商業産品到開源社群；
- 技術為業務服務，從本質觸發，深入行業，了解業務、行業的發展，抓住核心點，更好的服務于業務。
可以看到DBA的工作還是有蠻多的，AI要完全取代這些工作，還有非常漫長的過程。
OtterTune工作原理
以下示意圖用于解釋 OtterTune 中的各元件與工作流：
在開始一輪新的調節會話時，使用者首先需要告知 OtterTune 此番優化的具體目标（例如面向延遲抑或資料吞吐量）。其用戶端控制器将接入目标 DBMS 并收集其 Amazon EC2 執行個體類型與目前配置等相關資訊。
在此之後，該控制器會開始第一輪觀察周期，在此期間其将觀察 DBMS 以及與既定目标相關之各項記錄。在此輪觀察周期結束後，控制器将從 DBMS 當中收集各類内部名額，例如 MySQL 自磁盤處讀取之頁面以及向磁盤中寫入之頁面計數。該控制器随後會将目标資訊與内部名額發送回調節管理器當中。
當 OtterTune 的調節管理器接收到這些名額後，其會将相關資料存儲在自有存儲庫内。OtterTune 利用這些結果計算出控制器應在目标 DBMS 上安裝的下一套配置方案。具體配置方案由調節管理器傳遞至控制器處，同時确定運作後的預期改進效果。這時，使用者即可決定繼續抑或中止目前調節會話。
OtterTune 為其支援的每個 DBMS 版本皆設立有一套調節黑名單。此份黑名單中囊括了各類無法調整的項目（例如 DBMS 存儲檔案的路徑名稱）或者可能引發嚴重乃至隐藏後果的選項（例如可能導緻 DBMS 遭遇潛在資料丢失）。每開始一項調節會話時，OtterTune 即可彈出黑名單提示，用以提醒使用者添加各項不希望由 OtterTune 進行調節的具體條目。
機器學習管道
上圖顯示了，資料在通過OtterTune的機器學習管道傳輸時如何加以處理。
OtterTune 首先會将觀察結果傳遞至 Workload Characterization 元件當中。此元件負責識别其中一小部分 DBMS 名額，進而更好地把握性能差異以及不同工作負載之間的差別性特征。
接下來，Knob Indetification 元件會生成一份與可調節項目相關之排名清單，其具體排序根據對 DBMS 性能之影響力而定。OtterTune 随後會将全部資訊饋送至 Automatic Tuner 當中。此元件負責将目标 DBMS 的工作負載與現有資料存儲庫内最為相似的工作負載進行映射，而後利用對應工作負載資料以生成更适用的配置方案。
下面讓我們深入了解機器學習管道中的元件。
Workload Characterization: OtterTune 利用 DBMS 的各内部運作時名額以表征某一工作負載的行為方式。這些名額能夠對工作負載作出準确表示，因為其能夠确切捕捉到其運作時行為當中的各項細節。然而，亦有許多度量完全不必要存在：其中一部分屬于不同單元記錄當中的同一量度結果，另一些不必要名額則代表着某些數值存在高度互關聯性的 DBMS 獨立元件。是以，對其中的備援度量進行排除将非常重要，這将有效幫助我們降低機器學習模型的複雜性水準。為此，我們将面向 DBMS 對相關模型的度量進行收斂。此後，我們将從每個群集當中選擇出一個代表性度量，并確定其為最靠近群集中心的度量。機器學習管道當中的後續元件将對這些度量加以使用。
Knob Identification: DBMS 可以擁有數百項可調節項目，但其中隻有一個子集會對 DBMS 性能造成實際影響。OtterTune 利用目前流行趨勢 特性選擇技術 Lasso 以確定哪個條目會對系統的整體性能造成嚴重影響。通過此項技術，OtterTune 将能夠利用其存儲庫内的資料對各 DBMS 可調節項目的重要性進行排序。
Automatic Tuner: Automated Tuning 元件通過在每輪觀察周期之後執行兩項分析步驟以确定 OtterTune 的推薦配置方案。
首先，該系統利用确定自 Workload Characterization 元件中識别名額的性能資料從原有存儲庫内找到最能展現目标 DBMS 工作負載特征的原有調節會話。其會将兩項會話間的名額進行比較，旨在了解如何對不同調節選項進行變動以實作類似的工作負載名額量化結果。
在此之後，OtterTune 會選擇另一套調節配置進行嘗試。這套新的配置方案切合目前統計模型所收集到的實際資料，即以此資料為基礎從存儲庫當中查找類似的工作負載。這套模型允許 OtterTune 預測 DBMS 在各類潛在配置下的實際運作效果 OtterTune 會對下一套配置進行優化，進而将探索（即收集集團以改進模型）轉化為實際利用（盡可能帶來更出色的目标度量）。
實作
OtterTune 以 Python 語言編寫而成。對于 Workload Characterization 與 Knob Identification 兩種元件，運作時性能并非我們的關注重點，是以我們使用 scikit 以實作相應的機器學習算法。這些算法在背景程序當中運作，并使用來自 OtterTune 存儲庫的新資料。
對于 Automatic Tuner，這些機器學習算法則變得更為關鍵。其需要在每一輪觀察周期後運作，同時結合新資料以確定 OtterTune 能夠選擇一項對應調節條目進行下一步嘗試。在這一流程中，由于性能成為更加重要的考量因素，是以我們使用 TensorFlow 以實作這些算法。
為了收集與 DBMS 硬體、調節配置以及運作時性能名額相關的資料，我們将 OtterTune 控制器同 OLTP-Bench 基準測試架構進行了整合。
實驗評估
為了完成評估，我們利用 OtterTune 所給出的以下最佳配置選項對 MySQL 及 Postgres 性能進行了比較。在評估前我們要滿足以下條件：
Default: DBMS 所提供的配置方案
Tuning : 由一款開源調節建議工具生成的配置方案
DBA: 由人類資料庫管理者標明的配置方案
RDS: 針對 Amazon RDS 管理并部署在同一 EC2 執行個體類型之上的
DBMS 進行定制化的配置方案
我們在 Amazon EC2 現貨執行個體之上進行了全部實驗。我們分别在兩套執行個體之上執行實驗過程：其一作為 OtterTune 控制器，其二則作為目标 DBMS 部署系統。我們在這裡分别使用了 m4.large 與 m3.xlarge 執行個體類型。我們将 OtterTune 的調節管理器與資料存儲庫部署在一套本地伺服器之上，其配置為 20 計算核心與 128 GB 記憶體。
我們還用到了 TPC-C 工作負載，其屬于業界标準的線上事務處理（簡稱 OLTP）系統性能評估工作負載類型。
評估方式
對于我們在實驗當中所使用的 MySQL 與 Postgres 兩套資料庫，我們分别對其延遲水準與資料吞吐量進行了觀察。以下圖表給出了對應結果。第一份圖表所示為第 99 百分位處的延遲水準，意味着“最壞情況”下完成事務處理所需要的時長。第二份圖表則顯示了資料吞吐量結果，即每秒完成的平均事務數量。
MySQL 測試結果
将 OtterTune 所生成的最佳配置與 Tuning 以及 RDS 相關配置進行比較可以發現，MySQL 在延遲水準方面降低了約 60%，而資料吞吐量則在 OtterTune 配置的幫助下提升 22% 到 35% 之間。與此同時，OtterTune 的生成的配置方案在實際效果上與人類資料庫管理者幾乎不相上下。
Postgres 測試結果