前沿 | VLDB 2019論文解讀：阿里巴巴大規(guī)模數(shù)據(jù)庫智能參數(shù)優(yōu)化的創(chuàng)新與實(shí)踐

原文： https://www.modb.pro/db/6143  

前言

一年一度的數(shù)據(jù)庫領(lǐng)域頂級會議VLDB 2019于美國當(dāng)?shù)貢r(shí)間8月26日-8月30日在洛杉磯召開。在本屆大會上，阿里云數(shù)據(jù)庫產(chǎn)品團(tuán)隊(duì)多篇論文入選Research Track和Industrial Track。

本文將對入圍ResearchTrack 的論文《iBTune: Individualized Buffer Tuning for Largescale Cloud Databases》進(jìn)行詳細(xì)解讀，以饗讀者。

背景

大概五六年前，阿里數(shù)據(jù)庫團(tuán)隊(duì)開始嘗試如何將DBA的經(jīng)驗(yàn)轉(zhuǎn)換成產(chǎn)品，為業(yè)務(wù)開發(fā)提供更高效，更智能的數(shù)據(jù)庫服務(wù)。從14年CloudDBA開始為用戶提供自助式智能診斷優(yōu)化服務(wù)，經(jīng)過四年的持續(xù)探索和努力，18年進(jìn)化到CloudDBA下一代產(chǎn)品 —— 自治數(shù)據(jù)庫平臺SDDP(Self-Driving Database Platform)。

SDDP是一個賦予多種數(shù)據(jù)庫無人駕駛能力的智能數(shù)據(jù)庫平臺，讓運(yùn)行于該平臺的數(shù)據(jù)庫具備自感知、自決策、自恢復(fù)、自優(yōu)化的能力，為用戶提供無感知的不間斷服務(wù)。自治數(shù)據(jù)庫平臺涵蓋了非常多的能力，包括物理資源管理，實(shí)例生命周期管理，診斷優(yōu)化，安全，彈性伸縮等，而其中自動異常診斷與恢復(fù)和自動優(yōu)化是自治數(shù)據(jù)庫平臺最核心的能力之一。

2017年底，SDDP開始對全網(wǎng)數(shù)據(jù)庫實(shí)例進(jìn)行端到端的全自動優(yōu)化，除了常見的自動慢SQL優(yōu)化和自動空間優(yōu)化外，還包含了本文重點(diǎn)介紹的大規(guī)模數(shù)據(jù)庫自動參數(shù)優(yōu)化。

基于數(shù)據(jù)驅(qū)動和機(jī)器學(xué)習(xí)算法的數(shù)據(jù)庫參數(shù)優(yōu)化是近年來數(shù)據(jù)庫智能優(yōu)化的一個熱點(diǎn)方向，但也面臨著很大的技術(shù)挑戰(zhàn)。要解決的問題是在大規(guī)模數(shù)據(jù)庫場景下，如何對百萬級別運(yùn)行不同業(yè)務(wù)的數(shù)據(jù)庫實(shí)例完成自動配置，同時(shí)權(quán)衡性能和成本，在滿足SLA的前提下資源成本最低，該技術(shù)對于CSP(Cloud Service Provider)有重要價(jià)值。

學(xué)術(shù)界近一兩年在該方向有一些研究(比如CMU的OtterTune)，但該算法依賴于一些人工先驗(yàn)經(jīng)驗(yàn)且在大規(guī)模場景下不具備可擴(kuò)展性。據(jù)了解, 其他云廠商Azure SQL Database以及AWS該方向都有投入，目前尚未看到相關(guān)論文或產(chǎn)品發(fā)布。

從18年初開始我們開始數(shù)據(jù)庫智能參數(shù)優(yōu)化的探索，從問題定義，關(guān)鍵算法設(shè)計(jì)，算法評估及改進(jìn)，到最終端到端自動化流程落地，多個團(tuán)隊(duì)通力合作完成了技術(shù)突破且實(shí)現(xiàn)了大規(guī)模落地。

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

這項(xiàng)工作不僅在數(shù)據(jù)庫智能參數(shù)優(yōu)化理論方面提出了創(chuàng)新想法，而且目前已經(jīng)在阿里集團(tuán)~10000實(shí)例上實(shí)現(xiàn)了規(guī)?；涞?，累計(jì)節(jié)省~12%內(nèi)存資源，是目前業(yè)界唯一一家真正實(shí)現(xiàn)數(shù)據(jù)庫智能參數(shù)優(yōu)化大規(guī)模落地的公司。

問題定義

參數(shù)優(yōu)化是數(shù)據(jù)庫優(yōu)化的重要手段，而數(shù)據(jù)庫參數(shù)之多也增加了參數(shù)調(diào)優(yōu)的難度，比如最新版本的MySQL參數(shù)超過500，PostgreSQL參數(shù)也超過290。通常數(shù)據(jù)庫調(diào)優(yōu)化主要關(guān)心性能相關(guān)的參數(shù)，而其中對性能影響最大的是Buffer Pool的設(shè)置。

目前集團(tuán)環(huán)境多個數(shù)據(jù)庫實(shí)例共享主機(jī)的部署方式導(dǎo)致經(jīng)常出現(xiàn)主機(jī)內(nèi)存嚴(yán)重不足，但CPU和存儲資源還有較多剩余，造成了機(jī)器資源浪費(fèi)，因此內(nèi)存資源緊張成為影響數(shù)據(jù)庫實(shí)例部署密度的關(guān)鍵瓶頸。

Buffer Pool是內(nèi)存資源消耗的最大頭，如何實(shí)現(xiàn)Buffer Pool最優(yōu)配置是影響全網(wǎng)機(jī)器成本的關(guān)鍵，同時(shí)也是影響數(shù)據(jù)庫實(shí)例性能的關(guān)鍵，因此我們將智能參數(shù)優(yōu)化重點(diǎn)放在了Buffer Pool參數(shù)優(yōu)化。

對于大規(guī)模數(shù)據(jù)庫場景，挑戰(zhàn)在于如何為每個數(shù)據(jù)庫實(shí)例配置合理的Buffer Pool Size，可以在不影響實(shí)例性能的前提下，Buffer Pool Size最小。傳統(tǒng)大規(guī)模數(shù)據(jù)庫場景為了方便統(tǒng)一管控，通常采用靜態(tài)配置模板的配置數(shù)據(jù)庫實(shí)例參數(shù)。

以阿里集團(tuán)數(shù)據(jù)庫場景為例，集團(tuán)內(nèi)提供了10種BufferPool規(guī)格的數(shù)據(jù)庫實(shí)例供業(yè)務(wù)方選擇。開發(fā)同學(xué)在申請實(shí)例時(shí)，由于不清楚自己的業(yè)務(wù)對BP的需求是什么，通常會選用默認(rèn)配置規(guī)格或者較高配置規(guī)格。這種資源分配，帶來了嚴(yán)重的資源浪費(fèi)。

另外業(yè)務(wù)多樣性和持續(xù)可變性使得傳統(tǒng)依賴DBA手工調(diào)優(yōu)方式在大規(guī)模場景下完全不可行，因此基于數(shù)據(jù)驅(qū)動和機(jī)器學(xué)習(xí)算法來根據(jù)數(shù)據(jù)庫負(fù)載和性能變化動態(tài)調(diào)整數(shù)據(jù)庫Buffer Pool成為一個重要的研究問題。

問題分析

從問題本身來看，緩存的大?。˙P）與緩存命中率（hit ratio）是存在直接關(guān)系的。設(shè)想一下，如果可以找到一個公式BP=Function(hit_ratio)，然后從業(yè)務(wù)方或者DBA的視角找到一個業(yè)務(wù)可接受的緩存命中率，就可以下調(diào)BP且不影響業(yè)務(wù)。

經(jīng)過調(diào)研，我們發(fā)現(xiàn)在操作系統(tǒng)的Cache研究領(lǐng)域中，研究者已經(jīng)對buffer size和hit ratio的對應(yīng)關(guān)系有了很多研究，其中有研究表明在數(shù)據(jù)長尾部分這二者的關(guān)系服從Power Law分布，即：

其中，
αi是Power Law分布的指數(shù)，miss_ratio=1?hit_ratio。

經(jīng)過上面的理論調(diào)研，關(guān)系模型已經(jīng)得到解決，接下來需要求解該模型中的超參數(shù)，即MySQL數(shù)據(jù)庫Cache的αi。

在集團(tuán)DBA同學(xué)開發(fā)的Frodo工具幫助下，我們針對集團(tuán)內(nèi)的幾個重要OLTP場景（例如購物車場景、交易支付場景）進(jìn)行了不同BP配置的壓測實(shí)驗(yàn)。實(shí)驗(yàn)結(jié)果也印證了前面的理論結(jié)果，在長尾部分MySQL的緩存確實(shí)是符合Power Law分布假設(shè)的。

于是，給定當(dāng)前未命中率 mrcur、當(dāng)前BP大小BPcur和目標(biāo)未命中率 mrtarget的情況下，我們可以推導(dǎo)出如下公式來計(jì)算調(diào)整后的BP BPtarget，公式：

通過上面的理論調(diào)研和MySQL實(shí)際場景驗(yàn)證，該理論公式經(jīng)驗(yàn)證在MySQL場景下成立，并且可計(jì)算出關(guān)鍵系數(shù)αi，接下來看如何計(jì)算 miss_ratiotarget。

尋找合適的miss ratio

阿里巴巴集團(tuán)中有數(shù)萬+數(shù)據(jù)庫實(shí)例主節(jié)點(diǎn)，我們考慮從這數(shù)萬數(shù)據(jù)庫中尋找與待調(diào)整實(shí)例相似的實(shí)例，然后利用這些相似實(shí)例的miss ratio來找到待調(diào)整實(shí)例的目標(biāo)miss ratio.

特征選擇上，我們選用了CPU usage, logical read, io read, miss ratio, response time 等性能指標(biāo)來描述一個業(yè)務(wù)workload，并對這些特征選取了幾個統(tǒng)計(jì)量（如mean、media、70th percentile、90th percentile）作為具體的特征數(shù)值。

為了降低工作日、周末對數(shù)據(jù)的影響，我們選取了跨度4周的性能數(shù)據(jù)來做相似度計(jì)算，下圖為兩對相似實(shí)例的示例。

算法挑戰(zhàn)

經(jīng) 過前部分的處理，公式、參數(shù)和目標(biāo)mr都有了，已經(jīng)可以代入公式計(jì)算出目標(biāo)BP，接下來需要解決算法在工程落地過程中所面臨的問題。

由于hit ratio這個指標(biāo)并不能直接的反應(yīng)數(shù)據(jù)庫對業(yè)務(wù)的影響，導(dǎo)致業(yè)務(wù)方和DBA都沒有直接的體感，并且該指標(biāo)也不能用來直接衡量數(shù)據(jù)庫業(yè)務(wù)穩(wěn)定性。因此，受限于穩(wěn)定性要求，該算法在無法給出對業(yè)務(wù)影響的量化數(shù)值情況下，尚不能落地具體業(yè)務(wù)。

針對這個問題，經(jīng)過與DBA和業(yè)務(wù)方的多次討論，我們發(fā)現(xiàn)業(yè)務(wù)方和DBA最關(guān)心的是數(shù)據(jù)庫的Response Time（RT），尤其是數(shù)據(jù)庫實(shí)例對應(yīng)用服務(wù)時(shí)的最大RT。

設(shè)想一下，如果可以預(yù)測出BP調(diào)整后的數(shù)據(jù)庫實(shí)例RT的最差值，也就是RT的上界RT upperbound，那么就可以量化的描述出調(diào)整BP之后對業(yè)務(wù)的影響，也就消除了業(yè)務(wù)方與DBA對該參數(shù)優(yōu)化的擔(dān)憂，算法就具備了落地生產(chǎn)環(huán)境的必要條件。于是，我們對數(shù)據(jù)庫實(shí)例RT upperbound進(jìn)行了算法預(yù)測。

RT預(yù)測模型

針對RT預(yù)測問題，我們提出了一個pairwise的DNN模型，具體的結(jié)構(gòu)如圖：

在訓(xùn)練階段，左實(shí)例代表的是我們要預(yù)測RT的實(shí)例，右實(shí)例代表的是某一個相似實(shí)例（前面尋找 mrtarget時(shí)篩選出的相似實(shí)例），左右實(shí)例的RT都是已知的。

在測試階段，我們用該模型來預(yù)測實(shí)例BP調(diào)整后的RT，左右實(shí)例均是當(dāng)前實(shí)例，但是把mrcur替換成 mrtarget。

該DNN網(wǎng)絡(luò)模型中采用了全連接形式，激活函數(shù)為ReLU，隱藏層節(jié)點(diǎn)數(shù)分別為100，50，50。

損失函數(shù)：

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

其中，y為實(shí)際RT觀測值。由于不同實(shí)例y的值域跨度很大，我們將e用y來做正則化，同時(shí)增加η來避免RT非常小時(shí)引入的優(yōu)化誤差。

實(shí)驗(yàn)

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

I2V-DNN的結(jié)構(gòu)如圖：

為了證明該算法的普適性，我們從集團(tuán)數(shù)據(jù)庫的幾個重要業(yè)務(wù)場景中選擇了1000個實(shí)例，覆蓋了不同讀寫比的示例，包括只讀示例、只寫實(shí)例、讀寫均衡實(shí)例等情況。

在評價(jià)算法效果方面，我們主要采用了如下3個評價(jià)指標(biāo)：

其中，AMRAE可以評估出RT預(yù)測結(jié)果的誤差比例，MAE用于衡量RT預(yù)測的平均誤差，UMAE用于衡量RT預(yù)測值低估的情況。

在實(shí)驗(yàn)數(shù)據(jù)集上，RT預(yù)測結(jié)果對比如圖：

由上圖看出，PW-DNN模型在AMRAE這一指標(biāo)上對比其他算法優(yōu)勢比較明顯，綜合其他指標(biāo)，PW-DNN模型的算法效果最好，所以我們最終選擇用來預(yù)測RT的算法是PW-DNN。

實(shí)際效果

為了更加直觀的觀察實(shí)例變更BP前后的變化，我們隨機(jī)選擇了10個實(shí)例來展示調(diào)整BP前后數(shù)據(jù)庫各項(xiàng)指標(biāo)，數(shù)據(jù)如圖：

從上圖中可以看出，不同規(guī)格實(shí)例在調(diào)整BP之后的RT與調(diào)整之前的RT相差不大（實(shí)例1除外）。通過QPS、CPU usage可以看出，調(diào)整前后的業(yè)務(wù)訪問量相差不大，并且資源消耗很接近，但節(jié)省了不同幅度的內(nèi)存。

在實(shí)例1中出現(xiàn)了調(diào)整后RT大幅上升的情況，經(jīng)過對該case的仔細(xì)排查發(fā)現(xiàn)，該業(yè)務(wù)的日常QPS非常低，耗時(shí)占比最高的只有一個query，在調(diào)整后該query查詢的值不一樣，導(dǎo)致logical read和physical read升高很多，因此最終平均RT的值也升高很多。但是調(diào)整后RT的絕對值并不大，沒有發(fā)生慢SQL異常，對業(yè)務(wù)來說是可以接受的，因此沒有觸發(fā)回滾操作。

落地

我們實(shí)現(xiàn)了一個端到端的算法落地流程，從數(shù)據(jù)采集到BP優(yōu)化指令的執(zhí)行。該系統(tǒng)包含4個主要模塊，分別是指標(biāo)采集、數(shù)據(jù)處理、決策和執(zhí)行，模塊設(shè)計(jì)如圖：

 · 指標(biāo)采集：數(shù)據(jù)庫管控平臺已經(jīng)實(shí)現(xiàn)對集團(tuán)內(nèi)全部數(shù)據(jù)庫實(shí)例的指標(biāo)數(shù)據(jù)采集，覆蓋了算法所使用的各項(xiàng)指標(biāo)；

 · 數(shù)據(jù)處理：采集后的指標(biāo)經(jīng)過流式處理進(jìn)行不同窗口維度的統(tǒng)計(jì)匯總，并存儲在odps中供算法使用；

 · 決策：本文算法的具體實(shí)現(xiàn)部分，讀取odps中存儲的指標(biāo)統(tǒng)計(jì)數(shù)據(jù)，經(jīng)算法模型計(jì)算得到待優(yōu)化實(shí)例調(diào)整后的BP值；

 · 執(zhí)行：數(shù)據(jù)庫管控平臺對BP優(yōu)化指令進(jìn)行專項(xiàng)實(shí)現(xiàn)，并調(diào)度該優(yōu)化操作的具體執(zhí)行時(shí)間窗口，在符合發(fā)布約束的前提下高效執(zhí)行該操作。

穩(wěn)定性挑戰(zhàn)

由于降低BufferPool配置的這個操作是個會降低穩(wěn)定性的操作，一旦操作不當(dāng)，輕則給DBA帶來額外工作，重則引發(fā)業(yè)務(wù)故障。因此，該項(xiàng)目受到了BU內(nèi)DBA和各穩(wěn)定性相關(guān)同學(xué)的挑戰(zhàn)和壓力。

我們主要采取了多項(xiàng)措施來確保業(yè)務(wù)穩(wěn)定性，具體包括：
1. 算法模型： 調(diào)整BufferPool大小與緩存命中率映射關(guān)系的敏感系數(shù)αα，使調(diào)整結(jié)果較為保守；

2. 在線調(diào)整：我們僅針對可online調(diào)整參數(shù)的實(shí)例進(jìn)行調(diào)整，避免因MySQL內(nèi)核原因?qū)е翸ySQL crash的情況；

3. 灰度策略：全網(wǎng)規(guī)?；瘏?shù)調(diào)整采用了嚴(yán)格的灰度策略，最開始由業(yè)務(wù)DBA根據(jù)算法給出的BP大小進(jìn)行少量實(shí)例調(diào)整，確保業(yè)務(wù)穩(wěn)定；然后通過較多實(shí)例的白名單機(jī)制，僅對白名單中的實(shí)例自動調(diào)整BufferPool大小，在指定范圍內(nèi)實(shí)例上進(jìn)行灰度；最后，在業(yè)務(wù)DBA確認(rèn)過非核心實(shí)例上，嚴(yán)格按照發(fā)布流程和管控流程進(jìn)行規(guī)?；詣硬僮?，并嚴(yán)格限制每次操作的數(shù)量。

4. 流程閉環(huán)：從數(shù)據(jù)采集，BP大小決策、自動化BP調(diào)整到調(diào)整后的量化跟蹤，以及回滾機(jī)制，整個流程閉環(huán)，每天發(fā)出調(diào)整后的統(tǒng)計(jì)分析報(bào)告。

成果

經(jīng)過算法探索和端到端自動Buffer Pool優(yōu)化流程建設(shè)，F(xiàn)Y2019集團(tuán)內(nèi)全網(wǎng)最終優(yōu)化 ~10000 個實(shí)例，將整體內(nèi)存使用量從 217T內(nèi)存縮減到 190T內(nèi)存，節(jié)省 12.44%內(nèi)存資源(27TB)。

未來

業(yè)務(wù)方面，F(xiàn)Y2020我們一方面繼續(xù)擴(kuò)大BP優(yōu)化的實(shí)例范圍以節(jié)省更多的內(nèi)存資源；另一方面將繼續(xù)優(yōu)化該算法模型通過HDM產(chǎn)品輸出到公有云，為云上用戶提供數(shù)據(jù)庫實(shí)例規(guī)格建議。

技術(shù)方面，我們將從Buffer Pool參數(shù)優(yōu)化擴(kuò)展到數(shù)據(jù)庫其他性能參數(shù)優(yōu)化，探索多性能參數(shù)之間的關(guān)系及影響，建立基于數(shù)據(jù)庫負(fù)載和性能關(guān)系影響模型，從整個數(shù)據(jù)庫實(shí)例視角進(jìn)行統(tǒng)一數(shù)據(jù)庫參數(shù)優(yōu)化。

想了解更多關(guān)于數(shù)據(jù)庫、云技術(shù)的內(nèi)容嗎？

快來關(guān)注“數(shù)據(jù)和云"、"云和恩墨，"公眾號及"云和恩墨"官方網(wǎng)站，我們期待大家一同學(xué)習(xí)與進(jìn)步！

數(shù)據(jù)和云小程序”DBASK“在線問答，隨時(shí)解惑，歡迎了解和關(guān)注！