數據庫頂會VLDB論文解讀：阿里巴巴數據庫智能參數優化的創新與實踐

前言

一年一度的數據庫領域頂級會議VLDB 2019於美國當地時間8月26日-8月30日在洛杉磯召開。在本屆大會上，阿里雲數據庫產品團隊多篇論文入選Research Track和Industrial Track。

本文將對入圍Research Track的論文《iBTune: Individualized Buffer Tuning for Largescale Cloud Databases》進行詳細解讀，以饗讀者。

注：本文由阿里雲智能事業羣艾奧、池院、洪林、譚劍、祺星、鐵贏共同撰寫。

一、背景

大概五六年前，阿里數據庫團隊開始嘗試如何將DBA的經驗轉換成產品，爲業務開發提供更高效，更智能的數據庫服務。從14年CloudDBA開始爲用戶提供自助式智能診斷優化服務，通過四年的持續探索和努力，18年進化到CloudDBA下一代產品 —— 自治數據庫平臺SDDP(Self-Driving Database Platform)。

SDDP是一個賦予多種數據庫無人駕駛能力的智能數據庫平臺，讓運行於該平臺的數據庫具有自感知、自決策、自恢復、自優化的能力，爲用戶提供無感知的不間斷服務。自治數據庫平臺涵蓋了很是多的能力，包括物理資源管理，實例生命週期管理，診斷優化，安全，彈性伸縮等，而其中自動異常診斷與恢復和自動優化是自治數據庫平臺最核心的能力之一。

2017年末，SDDP開始對全網數據庫實例進行端到端的全自動優化，除了常見的自動慢SQL優化和自動空間優化外，還包含了本文重點介紹的大規模數據庫自動參數優化。

基於數據驅動和機器學習算法的數據庫參數優化是近年來數據庫智能優化的一個熱點方向，但也面臨着很大的技術挑戰。要解決的問題是在大規模數據庫場景下，如何對百萬級別運行不一樣業務的數據庫實例完成自動配置，同時權衡性能和成本，在知足SLA的前提下資源成本最低，該技術對於CSP(Cloud Service Provider)有重要價值。

學術界近一兩年在該方向有一些研究(好比CMU的OtterTune)，但該算法依賴於一些人工先驗經驗且在大規模場景下不具有可擴展性。據瞭解, 其餘雲廠商Azure SQL Database以及AWS該方向都有投入，目前還沒有看到相關論文或產品發佈。

從18年初開始咱們開始數據庫智能參數優化的探索，從問題定義，關鍵算法設計，算法評估及改進，到最終端到端自動化流程落地，多個團隊通力合做完成了技術突破且實現了大規模落地。

由譚劍、鐵贏、飛刀、艾奧、祺星、池院、洪林、石悅、鳴嵩、張瑞共同撰寫的論文《iBTune: Individualized Buffer Tuning for Largescale Cloud Databases》被VLDB 2019 Research Track接受，這是阿里巴巴在數據庫智能化方向的重要里程碑事件。

這項工做不只在數據庫智能參數優化理論方面提出了創新想法，並且目前已經在阿里集團~10000實例上實現了規模化落地，累計節省~12%內存資源，是目前業界惟一一家真正實現數據庫智能參數優化大規模落地的公司。

二、問題定義

參數優化是數據庫優化的重要手段，而數據庫參數之多也增長了參數調優的難度，好比最新版本的MySQL參數超過500，PostgreSQL參數也超過290。一般數據庫調優化主要關心性能相關的參數，而其中對性能影響最大的是Buffer Pool的設置。

目前集團環境多個數據庫實例共享主機的部署方式致使常常出現主機內存嚴重不足，但CPU和存儲資源還有較多剩餘，形成了機器資源浪費，所以內存資源緊張成爲影響數據庫實例部署密度的關鍵瓶頸。

Buffer Pool是內存資源消耗的最大頭，如何實現Buffer Pool最優配置是影響全網機器成本的關鍵，同時也是影響數據庫實例性能的關鍵，所以咱們將智能參數優化重點放在了Buffer Pool參數優化。

對於大規模數據庫場景，挑戰在於如何爲每一個數據庫實例配置合理的Buffer Pool Size，能夠在不影響實例性能的前提下，Buffer Pool Size最小。傳統大規模數據庫場景爲了方便統一管控，一般採用靜態配置模板的配置數據庫實例參數。

以阿里集團數據庫場景爲例，集團內提供了10種BufferPool規格的數據庫實例供業務方選擇。開發同窗在申請實例時，因爲不清楚本身的業務對BP的需求是什麼，一般會選用默認配置規格或者較高配置規格。這種資源分配方式，帶來了嚴重的資源浪費。

另外業務多樣性和持續可變性使得傳統依賴DBA手工調優方式在大規模場景下徹底不可行，所以基於數據驅動和機器學習算法來根據數據庫負載和性能變化動態調整數據庫Buffer Pool成爲一個重要的研究問題。

三、問題分析

從問題自己來看，緩存的大小（BP）與緩存命中率（hit ratio）是存在直接關係的。設想一下，若是能夠找到一個公式BP=Function(hit_ratio)，而後從業務方或者DBA的視角找到一個業務可接受的緩存命中率，就能夠下調BP且不影響業務。

通過調研，咱們發如今操做系統的Cache研究領域中，研究者已經對buffer size和hit ratio的對應關係有了不少研究，其中有研究代表在數據長尾部分這兩者的關係服從Power Law分佈，即：

在集團DBA同窗開發的Frodo工具幫助下，咱們針對集團內的幾個重要OLTP場景（例如購物車場景、交易支付場景）進行了不一樣BP配置的壓測實驗。實驗結果也印證了前面的理論結果，在長尾部分MySQL的緩存確實是符合Power Law分佈假設的。

尋找合適的miss ratio

阿里巴巴集團中有3w+的數據庫實例主節點，咱們考慮從這3w+的數據庫中尋找與待調整實例類似的實例，而後利用這些類似實例的miss ratio來找到待調整實例的目標miss ratio.

特徵選擇上，咱們選用了CPU usage, logical read, io read, miss ratio, response time 等性能指標來描述一個業務workload，並對這些特徵選取了幾個統計量（如mean、media、70th percentile、90th percentile）做爲具體的特徵數值。

爲了下降工做日、週末對數據的影響，咱們選取了跨度4周的性能數據來作類似度計算，下圖爲兩對類似實例的示例。

四、算法挑戰

通過前部分的處理，公式、參數和目標mr都有了，已經能夠代入公式計算出目標BP，接下來須要解決算法在工程落地過程當中所面臨的問題。

因爲hit ratio這個指標並不能直接的反應數據庫對業務的影響，致使業務方和DBA都沒有直接的體感，而且該指標也不能用來直接衡量數據庫業務穩定性。所以，受限於穩定性要求，該算法在沒法給出對業務影響的量化數值狀況下，尚不能落地具體業務。

針對這個問題，通過與DBA和業務方的屢次討論，咱們發現業務方和DBA最關心的是數據庫的Response Time（RT），尤爲是數據庫實例對應用服務時的最大RT。

設想一下，若是能夠預測出BP調整後的數據庫實例RT的最差值，也就是RT的上界RT upperbound，那麼就能夠量化的描述出調整BP以後對業務的影響，也就消除了業務方與DBA對該參數優化的擔心，算法就具有了落地生產環境的必要條件。因而，咱們對數據庫實例RT upperbound進行了算法預測。

RT預測模型

針對RT預測問題，咱們提出了一個pairwise的DNN模型，具體的結構如圖：

該DNN網絡模型中採用了全鏈接形式，激活函數爲ReLU，隱藏層節點數分別爲100，50，50。

實驗

在預測RT的實驗中，咱們對比了包括線性迴歸模型（LR）、XGBoost、RANSAC、決策樹（DTree）、ENet、AdaBoost線性迴歸（Ada）、GBDT、k近鄰迴歸（KNR）、bagging Regressor（BR）、extremely randomized trees regressor (ETR)、隨機森林（RF）、sparse subspace clustering (SSC)等迴歸算法，DNN模型、添加了embedding層進行instance-to-vector轉換的DNN（I2V-DNN）模型，以及pairwise DNN模型等深度學習算法。

I2V-DNN的結構如圖：

爲了證實該算法的普適性，咱們從集團數據庫的幾個重要業務場景中選擇了1000個實例，覆蓋了不一樣讀寫比的示例，包括只讀示例、只寫實例、讀寫均衡實例等狀況。

在評價算法效果方面，咱們主要採用了以下3個評價指標：

其中，AMRAE能夠評估出RT預測結果的偏差比例，MAE用於衡量RT預測的平均偏差，UMAE用於衡量RT預測值低估的狀況。

在實驗數據集上，RT預測結果對好比圖：

由上圖看出，PW-DNN模型在AMRAE這一指標上對比其餘算法優點比較明顯，綜合其餘指標，PW-DNN模型的算法效果最好，因此咱們最終選擇用來預測RT的算法是PW-DNN。

實際效果

爲了更加直觀的觀察實例變動BP先後的變化，咱們隨機選擇了10個實例來展現調整BP先後數據庫各項指標，數據如圖：

從上圖中能夠看出，不一樣規格實例在調整BP以後的RT與調整以前的RT相差不大（實例1除外）。經過QPS、CPU usage能夠看出，調整先後的業務訪問量相差不大，而且資源消耗很接近，但節省了不一樣幅度的內存。

在實例1中出現了調整後RT大幅上升的狀況，通過對該case的仔細排查發現，該業務的平常QPS很是低，耗時佔比最高的只有一個query，在調整後該query查詢的值不同，致使logical read和physical read升高不少，所以最終平均RT的值也升高不少。可是調整後RT的絕對值並不大，沒有發生慢SQL異常，對業務來講是能夠接受的，所以沒有觸發回滾操做。

五、落地

咱們實現了一個端到端的算法落地流程，從數據採集到BP優化指令的執行。該系統包含4個主要模塊，分別是指標採集、數據處理、決策和執行，模塊設計如圖：

• 指標採集：數據庫管控平臺已經實現對集團內所有數據庫實例的指標數據採集，覆蓋了算法所使用的各項指標；
• 數據處理：採集後的指標通過流式處理進行不一樣窗口維度的統計彙總，並存儲在odps中供算法使用；
• 決策：本文算法的具體實現部分，讀取odps中存儲的指標統計數據，經算法模型計算獲得待優化實例調整後的BP值；
• 執行：數據庫管控平臺對BP優化指令進行專項實現，並調度該優化操做的具體執行時間窗口，在符合發佈約束的前提下高效執行該操做。

穩定性挑戰

因爲下降BufferPool配置的這個操做是個會下降穩定性的操做，一旦操做不當，輕則給DBA帶來額外工做，重則引起業務故障。所以，該項目受到了BU內DBA和各穩定性相關同窗的挑戰和壓力。

咱們主要採起了多項措施來確保業務穩定性，具體包括：

1. 算法模型： 調整BufferPool大小與緩存命中率映射關係的敏感係數αα，使調整結果較爲保守；
2. 在線調整：咱們僅針對可online調整參數的實例進行調整，避免因MySQL內核緣由致使MySQL crash的狀況；
3. 灰度策略：全網規模化參數調整採用了嚴格的灰度策略，最開始由業務DBA根據算法給出的BP大小進行少許實例調整，確保業務穩定；而後經過較多實例的白名單機制，僅對白名單中的實例自動調整BufferPool大小，在指定範圍內實例上進行灰度；最後，在業務DBA確認過非核心實例上，嚴格按照發布流程和管控流程進行規模化全自動操做，並嚴格限制每次操做的數量。
4. 流程閉環：從數據採集，BP大小決策、自動化BP調整到調整後的量化跟蹤，以及回滾機制，整個流程閉環，天天發出調整後的統計分析報告。

六、成果

通過算法探索和端到端自動Buffer Pool優化流程建設，FY2019集團內全網最終優化 ~10000 個實例，將總體內存使用量從 217T內存縮減到 190T內存，節省 12.44%內存資源(27TB)。

七、將來

• 業務方面，FY2020咱們一方面繼續擴大BP優化的實例範圍以節省更多的內存資源；另外一方面將繼續優化該算法模型經過HDM產品輸出到公有云，爲雲上用戶提供數據庫實例規格建議。
• 技術方面，咱們將從Buffer Pool參數優化擴展到數據庫其餘性能參數優化，探索多性能參數之間的關係及影響，創建基於數據庫負載和性能關係影響模型，從整個數據庫實例視角進行統一數據庫參數優化。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。