簡介：?第十一屆中國數(shù)據(jù)庫技術(shù)大會（DTCC2020），在北京隆重召開。在12.23日性能優(yōu)化與SQL審計(jì)專場上，邀請了阿里巴巴數(shù)據(jù)庫技術(shù)團(tuán)隊(duì)高級技術(shù)專家梁高中為大家介紹DAS之基于Workload的全局自動優(yōu)化實(shí)踐。 SQL自動優(yōu)化是阿里云數(shù)據(jù)庫自治服務(wù)重要自治場景之一，該服務(wù)支撐阿里巴巴集團(tuán)全網(wǎng)慢SQL的自動優(yōu)化，目前已累計(jì)自動優(yōu)化超4900萬慢SQL。阿里在構(gòu)建這一能力過程中有經(jīng)驗(yàn)也有教訓(xùn)，期望從基于Workload的全局優(yōu)化能力構(gòu)建歷程、智能化自動優(yōu)化閉環(huán)實(shí)踐兩個(gè)方面和大家分享。

SQL自動優(yōu)化是阿里云數(shù)據(jù)庫自治服務(wù)重要自治場景之一，該服務(wù)支撐阿里巴巴集團(tuán)全網(wǎng)慢SQL的自動優(yōu)化，目前已累計(jì)自動優(yōu)化超4900萬慢SQL。阿里在構(gòu)建這一能力過程中有經(jīng)驗(yàn)也有教訓(xùn)，期望從基于Workload的全局優(yōu)化能力構(gòu)建歷程、智能化自動優(yōu)化閉環(huán)實(shí)踐兩個(gè)方面和大家分享。

演講嘉賓簡介：

梁高中，阿里巴巴數(shù)據(jù)庫技術(shù)團(tuán)隊(duì)高級技術(shù)專家，2017年加入阿里巴巴集團(tuán)，目前負(fù)責(zé)阿里巴巴阿里云數(shù)據(jù)庫自治服務(wù)研發(fā)負(fù)責(zé)人。加入阿里巴巴前，曾就職于IBM，華為等，擁有12+年的數(shù)據(jù)庫產(chǎn)品、數(shù)據(jù)庫優(yōu)化經(jīng)驗(yàn)，曾擔(dān)任數(shù)據(jù)庫優(yōu)化專家系統(tǒng)，跨源跨數(shù)據(jù)中心聯(lián)邦數(shù)據(jù)庫等開發(fā)團(tuán)隊(duì)負(fù)責(zé)人。

以下內(nèi)容根據(jù)演講視頻以及PPT整理而成。

本次分享主要圍繞以下三個(gè)方面：
一、SQL優(yōu)化場景
二、核心診斷能力構(gòu)建
三、自動優(yōu)化閉環(huán)

一、SQL優(yōu)化場景

1. SQL優(yōu)化挑戰(zhàn)

數(shù)據(jù)庫診斷優(yōu)化是提高數(shù)據(jù)庫性能和穩(wěn)定性的關(guān)鍵技術(shù)之一， SQL優(yōu)化是其中至關(guān)重要的一環(huán)。目前約80%的數(shù)據(jù)庫性能問題可通過SQL優(yōu)化手段解決。SQL優(yōu)化目前還是面臨著很多挑戰(zhàn)，首先，SQL優(yōu)化需要基于多方面的數(shù)據(jù)庫領(lǐng)域?qū)＜抑R和經(jīng)驗(yàn)。而且SQL優(yōu)化耗時(shí)繁重，當(dāng)面臨如阿里這樣的大規(guī)模的業(yè)務(wù)場景時(shí)，SQL持續(xù)優(yōu)化充滿挑戰(zhàn)。下圖中有一個(gè)基于真實(shí)業(yè)務(wù)數(shù)據(jù)所畫出的，隨時(shí)間變化的數(shù)據(jù)庫慢SQL趨勢圖
，T1代表著發(fā)現(xiàn)數(shù)據(jù)庫實(shí)例因慢SQL造成性能異常的時(shí)間點(diǎn)，而T2表示優(yōu)化過程結(jié)束，恢復(fù)常態(tài)時(shí)間點(diǎn)。那么T1越短表示發(fā)現(xiàn)性能異常的耗費(fèi)時(shí)間越少。其次T2-T1時(shí)間是異常處理時(shí)長，如果處理時(shí)間過長，一方面會嚴(yán)重影響業(yè)務(wù)，另一方面大大增加故障風(fēng)險(xiǎn)。

2. SQL優(yōu)化三大場景

如果將SQL優(yōu)化功能提供給用戶，主要涉及三種場景。首先是單SQL工具輔助診斷。用戶可以選擇以單SQL為輸入，輔助診斷工具會根據(jù)給定SQL及相關(guān)環(huán)境信息，給出優(yōu)化建議（改寫、最優(yōu)索引建議等），最大化加速查詢。還有基于負(fù)載全局輔助診斷工具，主要以Workload負(fù)載為優(yōu)化單位，綜合考慮Workload中影響整體性能的特征，實(shí)現(xiàn)負(fù)載整體性能最大化提升同時(shí)最大化降低空間消耗。這兩個(gè)場景以輔助決策方式，為用戶提供SQL診斷和優(yōu)化。還有一種場景是自動SQL優(yōu)化，通過構(gòu)建完善的自動化流程，實(shí)現(xiàn)問題SQL識別、優(yōu)化建議生成、評估自動上線，后續(xù)跟蹤、收益計(jì)算的全自動化流程。

二、核心診斷能力構(gòu)建

支持SQL優(yōu)化，就需要對核心診斷能力進(jìn)行構(gòu)建。那什么是核心診斷能力？即針對問題SQL，給出非常準(zhǔn)確的建議。用戶通常會遇到下面幾種SQL優(yōu)化問題。

1. 單SQL優(yōu)化診斷

SQL優(yōu)化的本質(zhì)是創(chuàng)造條件，發(fā)現(xiàn)可以提升的點(diǎn)，如SQL改寫，創(chuàng)建SQL索引等，從而讓數(shù)據(jù)庫優(yōu)化器選擇最優(yōu)或者次優(yōu)的SQL執(zhí)行計(jì)劃。下圖中間核心位置的是SQL優(yōu)化引擎，兩邊是從核心能力衍生出的對外場景，左邊是對外提供的SQL自動優(yōu)化的閉環(huán)，右邊是為用戶提供的SQL優(yōu)化建議。那么單SQL優(yōu)化診斷能力的構(gòu)建面臨幾個(gè)主要的問題，首先是應(yīng)該采用哪種優(yōu)化推薦算法？是基于規(guī)則方式還是基于代價(jià)模型方式？針對WHAT-IF內(nèi)核能力缺失的數(shù)據(jù)庫，應(yīng)該如何選擇？第二點(diǎn)，足夠覆蓋度的測試集，既如何構(gòu)建一個(gè)龐大的測試案例庫用于其核心能力驗(yàn)證？擁有足夠覆蓋度，因?yàn)闇?zhǔn)確的測試案例庫往往是核心診斷能力構(gòu)建過程中至關(guān)重要的一環(huán)。第三點(diǎn)，如何在大規(guī)模業(yè)務(wù)場景下提供診斷服務(wù)能力，阿里需要服務(wù)于云上幾十萬級的數(shù)據(jù)庫實(shí)例的SQL優(yōu)化診斷，那么如何實(shí)現(xiàn)復(fù)雜的計(jì)算服務(wù)服務(wù)化拆分，計(jì)算服務(wù)的橫向伸縮，最大化的并行，資源訪問分布式環(huán)境下的并發(fā)控制，不同優(yōu)先級的有效調(diào)度消除隔離，峰值緩沖等等？第四點(diǎn)，如何讓SQL診斷能力持續(xù)改進(jìn)。

單SQL優(yōu)化診斷 —— 優(yōu)化推薦算法選擇·面臨挑戰(zhàn)

第一類推薦算法是基于規(guī)則式的，其明顯的特點(diǎn)是基于事先編輯好的規(guī)則來優(yōu)化。第二類是基于代價(jià)評估方式。下圖左側(cè)是目前傳統(tǒng)商業(yè)化最優(yōu)索引推薦引擎架構(gòu)，SQL導(dǎo)入之后，對其進(jìn)行分析，生成候選索引。然后通過代價(jià)評估，這時(shí)會通過數(shù)據(jù)庫服務(wù)器WHAT-IF能力獲得這些候選索引的代價(jià)。基于WHAT-IF接口返回的結(jié)果進(jìn)行代價(jià)評估，最后進(jìn)行最終的索引合并擇優(yōu)。這是傳統(tǒng)數(shù)據(jù)庫中基于代價(jià)評估的最優(yōu)索引推薦流程。但是，對于例如MySQL這樣的數(shù)據(jù)庫引擎，這個(gè)過程中還是面臨幾個(gè)挑戰(zhàn)：
挑戰(zhàn)一：在MySQL中WHAT-IF功能是缺失的；
挑戰(zhàn)二：MySQL中沒有完整的統(tǒng)計(jì)信息可使用；

因此需要對此架構(gòu)進(jìn)行優(yōu)化，既在SQL引擎和數(shù)據(jù)庫服務(wù)器間加一個(gè)內(nèi)置優(yōu)化器，通過內(nèi)置優(yōu)化器提供WHAT-IF功能。但這種架構(gòu)依然會面臨幾個(gè)挑戰(zhàn)：

挑戰(zhàn)三：如何最大限度縮小兩個(gè)優(yōu)化器的差距；
挑戰(zhàn)四：內(nèi)置優(yōu)化器中的統(tǒng)計(jì)信息與MySQL中的統(tǒng)計(jì)信息存在差異，那么應(yīng)該如何縮小或者優(yōu)化它們之間的統(tǒng)計(jì)信息的差異？

單SQL優(yōu)化診斷 —— 優(yōu)化推薦算法選擇·基于代價(jià)評估方式

首先在內(nèi)置優(yōu)化器部分，阿里會在物理計(jì)劃基礎(chǔ)上進(jìn)行代價(jià)評估，然后從中選擇。這里與傳統(tǒng)數(shù)據(jù)庫中的優(yōu)化器不同點(diǎn)在于加入候選索引、SQL改寫的考量。另外，優(yōu)化器是基于統(tǒng)計(jì)信息進(jìn)行代價(jià)計(jì)算，因此在統(tǒng)計(jì)信息問題上采用了自適應(yīng)采樣算法，自適應(yīng)采樣實(shí)現(xiàn)在指定誤差范圍內(nèi)自適應(yīng)決定數(shù)據(jù)采樣量。還需要注意的一點(diǎn)是數(shù)據(jù)采樣的過程不能對目標(biāo)數(shù)據(jù)庫實(shí)例造成太大的壓力。

單SQL優(yōu)化診斷 —— 足夠覆蓋度的測試集·整體思路

為了保證SQL優(yōu)化引擎覆蓋足夠全面，那么就需要足夠的測試集。選擇測試集時(shí)會面臨三個(gè)問題，首先在選擇的測試集中要包含什么樣的測試案例？第二點(diǎn)，多少測試案例能夠證明已經(jīng)足夠全面？第三點(diǎn)，目前SQL優(yōu)化引擎的能力在什么位置？測試集的選擇之所以困難是因?yàn)橛绊慡QL優(yōu)化的因素太多， 如何讓這些特征一一映射到測試案例也是較為龐大的工程。還有，測試案例設(shè)計(jì)需要專業(yè)知識且信息量大，對于單一測試案例設(shè)計(jì)也需要專業(yè)知識且測試案例中攜帶的信息量大。

測試案例覆蓋度分析報(bào)告是通過下圖右側(cè)的流程來生成，首先是分析影響SQL優(yōu)化的因素，將其分解為多維度的測試案例特征集。之后通過特征形式化描述，生成測試案例形式化特征庫。之后借助阿里豐富的業(yè)務(wù)場景，收集線上全量SQL及全量慢SQL。然后結(jié)合形式化的特征，抽取線上測試案例，生成測試案例庫。最后結(jié)合測試案例運(yùn)行系統(tǒng)和測試案例分析工具，評估測試案例覆蓋度，生成分析報(bào)告。整個(gè)過程中首先是在對多維度特征進(jìn)行形式化轉(zhuǎn)化，然后通過線上資源構(gòu)建通往引擎測試集的橋梁，另外，對引擎測試集構(gòu)建查漏補(bǔ)缺的一把尺子。

單SQL優(yōu)化診斷 —— 足夠覆蓋度的測試集·測試用例特征化

下圖展示了測試用例特征化的結(jié)構(gòu)。首先從影響索引選擇的因素出發(fā)，列出這些因素。然后將SQL分為Single Table 和Multi Table兩個(gè)場景，分別從影響因素往下分SQL語句。再通過三種場景，完成特征集到能力級的映射。

這三種場景分別是L1、L2、L3。L1支持對核心標(biāo)簽謂詞部分、聚合排序部分做全排列，保證非核心標(biāo)簽被覆蓋，對謂詞聚合排序做粗粒度排列組合。L2包括對LIMIT的支持、NOT謂詞、聚合支持、函數(shù)支持、OR謂詞的支持、兩表的INNER JOIN、單表或兩表的UNION、SUBQUERY支持、隱式轉(zhuǎn)換等。L3包括三表到五表的INNER JOIN、UNION、SUBQUERY、LEFT/RIGHT JOIN、NATUAL JOIN等。

單SQL優(yōu)化診斷 —— 大規(guī)模診斷能力與數(shù)據(jù)驅(qū)動

支持大規(guī)模的業(yè)務(wù)場景的診斷服務(wù)，SQL優(yōu)化策略的實(shí)踐還需要完成很多的事情。首先對計(jì)算服務(wù)進(jìn)行拆分、保證計(jì)算服務(wù)橫向伸縮、還要有效保證并行采樣效率、控制資源并發(fā)訪問、消除優(yōu)先級調(diào)度隔離、緩沖業(yè)務(wù)峰值。這樣才能滿足在線上支持大規(guī)模業(yè)務(wù)場景的SQL優(yōu)化的應(yīng)用。

2. 基于Workload全局優(yōu)化

上面一直在討論對單SQL的優(yōu)化策略，那么從支持業(yè)務(wù)角度而言，還是需要從全局出發(fā)，做全局優(yōu)化。全局優(yōu)化是以Workload負(fù)載為優(yōu)化單位，綜合考慮Workload中影響整體性能的特征，實(shí)現(xiàn)負(fù)載整體性能最大化提升，同時(shí)最大化降低空間消耗。如下圖左側(cè)，從全量SQL中提取Workload負(fù)載情況，通過SQL全局優(yōu)化引擎，在考慮存儲約束條件S，以及成本約束條件C的情況下，輸出需要創(chuàng)建的新索引、需要改寫的新索引、需要刪除的新索引、并提供SQL改寫建議。

下圖左側(cè)的表格里是一系列簡單的SQL語句和Workload特征，包括INSERT語句，SELECT語句，在每個(gè)時(shí)間段內(nèi)執(zhí)行次數(shù)。如果從單SQL優(yōu)化的角度，會推薦SQL2-SQL6的四條優(yōu)化語句。但是從Workload全局優(yōu)化角度考慮會推薦兩項(xiàng)SQL優(yōu)化。Workload全局優(yōu)化相比與單SQL優(yōu)化整體RT下降了14.45%，索引空間節(jié)省了50%。

三、SQL自動優(yōu)化閉環(huán)

1. SQL自動優(yōu)化閉環(huán) —— 實(shí)踐效果

SQL自動優(yōu)化閉環(huán)指的是從問題SQL識別到基于Workload全局優(yōu)化建議自動生成與評估、優(yōu)化上線再到量化追蹤評估的全自動優(yōu)化閉環(huán)。自動優(yōu)化閉環(huán)將人工的被動式優(yōu)化轉(zhuǎn)變?yōu)橐灾悄芑癁榛A(chǔ)的主動式優(yōu)化。下圖左側(cè)展示了整個(gè)SQL自動優(yōu)化閉環(huán)的幾個(gè)關(guān)鍵優(yōu)化節(jié)點(diǎn)。首先是持續(xù)24小時(shí)的跟蹤，進(jìn)行指標(biāo)異常檢測和Workload異常檢測，發(fā)現(xiàn)異常點(diǎn)。之后通過SQL優(yōu)化引擎，給出優(yōu)化建議。如果用戶采納自動優(yōu)化建議，則灰度上線。如果不采納，則需要通過智能壓測驗(yàn)證，再到灰度上線，然后進(jìn)行優(yōu)化效果跟蹤。
阿里實(shí)現(xiàn)了SQL優(yōu)化的全自動化閉環(huán)，自動SQL優(yōu)化持續(xù)保持?jǐn)?shù)據(jù)庫實(shí)例運(yùn)行在最佳優(yōu)化狀態(tài)，目前阿里內(nèi)部自動優(yōu)化了4900萬慢SQL，全網(wǎng)慢SQL顯著下降了92%，全網(wǎng)慢SQL推薦率達(dá)到了75%。自動優(yōu)化閉環(huán)在云上輔助自治了30萬多的服務(wù)實(shí)例，全網(wǎng)實(shí)例月增長率達(dá)到90%。SQL自動優(yōu)化閉環(huán)希望從規(guī)模性、精準(zhǔn)性、安全性、全面性、聯(lián)動性等方面持續(xù)優(yōu)化提升，服務(wù)更多用戶。

2. SQL自動優(yōu)化閉環(huán) —— 生成基于壓測的優(yōu)化收益報(bào)告

下圖左側(cè)是基于壓測的優(yōu)化收益報(bào)告。根據(jù)SQL優(yōu)化引擎生成的SQL優(yōu)化的建議，選取用戶真實(shí)的負(fù)載數(shù)據(jù)情況，進(jìn)行壓測。壓測完成之后生成在真實(shí)的場景下對優(yōu)化建議的綜合評估，分析優(yōu)化收益。

3. SQL自動優(yōu)化閉環(huán) —— 演示復(fù)盤

SQL優(yōu)化為用戶提供了豐富的測試場景，基于SQL自動優(yōu)化只是其中一個(gè)場景。那如何將SQL自動優(yōu)化與其它測試場景混合到一起？這又將產(chǎn)生什么奇妙的效果？同時(shí)可以解決哪些問題？
下圖展示了隨時(shí)間變化的數(shù)據(jù)庫性能變化圖，以及過程中SQL自動優(yōu)化做的事情。圖中黃色線條是活躍會話數(shù)，深藍(lán)色線條表示CPU利用率，淺藍(lán)色線條是IOPS利用率。第一個(gè)階段是橙黃色部分，既在2020年9月3日21:06 數(shù)據(jù)庫出現(xiàn)異常，此時(shí)可以1分鐘內(nèi)發(fā)現(xiàn)異常、2分鐘內(nèi)定位異常，并自動發(fā)現(xiàn)SQL限流，然后限流生效，黃色活躍會話數(shù)回歸原位，深藍(lán)色CPU利用率下降，業(yè)務(wù)恢復(fù)正常。到第二階段綠色部分SQL自動優(yōu)化啟動，在2020年9月3日21:17 發(fā)起異常SQL優(yōu)化診斷，緊接著優(yōu)化索引變更上線，索引變更結(jié)束，進(jìn)行24小時(shí)跟蹤，然后解除限流。隨即推出規(guī)格升配（Autoscaling）建議，根據(jù)負(fù)載的變
化升級數(shù)據(jù)庫規(guī)格。

作者：stromal

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載

?

總結(jié)

以上是生活随笔為你收集整理的DTCC 2020 | 阿里云梁高中：DAS之基于Workload的全局自动优化实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。