原文：

前言

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

本文將對入圍ResearchTrack 的論文《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分佈，即：

其中，
αi是Power Law分佈的指數，miss_ratio=1−hit_ratio。

經過上面的理論調研，關係模型已經得到解決，接下來需要求解該模型中的超引數，即MySQL資料庫Cache的αi。

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

於是，給定當前未命中率 mrcur、當前BP大小BPcur和目標未命中率 mrtarget的情況下，我們可以推匯出如下公式來計算調整後的BP BPtarget，公式：

透過上面的理論調研和MySQL實際場景驗證，該理論公式經驗證在MySQL場景下成立，並且可計算出關鍵係數αi，接下來看如何計算 miss_ratiotarget。

尋找合適的miss ratio

阿里巴巴集團中有數萬+資料庫例項主節點，我們考慮從這數萬資料庫中尋找與待調整例項相似的例項，然後利用這些相似例項的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模型，具體的結構如圖：

在訓練階段，左例項代表的是我們要預測RT的例項，右例項代表的是某一個相似例項（前面尋找 mrtarget時篩選出的相似例項），左右例項的RT都是已知的。

在測試階段，我們用該模型來預測例項BP調整後的RT，左右例項均是當前例項，但是把mrcur替換成 mrtarget。

該DNN網路模型中採用了全連線形式，啟用函式為ReLU，隱藏層節點數分別為100，50，50。

損失函式：

其中I(.)是個指示函式，e=RT− RTpredict，λ∈[0,1]是個超引數，e=RT−RTpredict，用來控制underestimate時的懲罰程度。

其中，y為實際RT觀測值。由於不同例項y的值域跨度很大，我們將e用y來做正則化，同時增加η來避免RT非常小時引入的最佳化誤差。

實驗

在預測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引數最佳化擴充套件到資料庫其他效能引數最佳化，探索多效能引數之間的關係及影響，建立基於資料庫負載和效能關係影響模型，從整個資料庫例項視角進行統一資料庫引數最佳化。

想了解更多關於資料庫、雲技術的內容嗎？

快來關注“資料和雲"、"雲和恩墨，"公眾號及"雲和恩墨"官方網站，我們期待大家一同學習與進步！

資料和雲小程式”DBASK“線上問答，隨時解惑，歡迎瞭解和關注！

前沿 | VLDB 2019論文解讀：阿里巴巴大規模資料庫智慧引數最佳化的創新與實踐

相關文章