1、 阿里數(shù)據(jù)庫智能優(yōu)化技術(shù)本文介紹基于阿里的場景和規(guī)模所做的一些思考和實踐。首先在阿里對數(shù)據(jù)庫優(yōu)化服務(wù)的訴求，大家在數(shù)據(jù)庫性能優(yōu)化方面都有很多的經(jīng)驗教訓(xùn)，不同公司對優(yōu)化的具體做法也不太一樣。在方式上，大部分企業(yè)應(yīng)該還是重人工模式，就是由數(shù)據(jù)庫能力比較強(qiáng)的人，比如DBA，來解決數(shù)據(jù)庫性能問題。但阿里今天的數(shù)據(jù)庫規(guī)模非常大，不管我們有多少DBA，我們的人員增長速度都無法跟上業(yè)務(wù)發(fā)展的速度，單純依賴DBA已經(jīng)無法滿足業(yè)務(wù)發(fā)展需求。第二方面分析CloudDBA是如何做的，里面涉及到哪些技術(shù)，希望把這些技術(shù)分享給大家。如果大家所在的公司也在做類似的事情，希望能夠提供一些參考和幫助。第三方介紹目前正在探索的

2、一些事情?，F(xiàn)在人工智能技術(shù)比較火，數(shù)據(jù)庫相對來說是比較傳統(tǒng)的領(lǐng)域。如果我們將機(jī)器學(xué)習(xí)、深度學(xué)習(xí)這樣的技術(shù)引入到數(shù)據(jù)庫領(lǐng)域，它到底能做些什么，具體到數(shù)據(jù)庫優(yōu)化領(lǐng)域又能做什么，這是我們正在探索的一些事情。一、阿里數(shù)據(jù)庫優(yōu)化服務(wù)訴求1、業(yè)務(wù)訴求首先從整個阿里數(shù)據(jù)庫的角度看一下對于數(shù)據(jù)庫優(yōu)化服務(wù)的業(yè)務(wù)訴求，這也是我們做這個產(chǎn)品最大的驅(qū)動力。（1）服務(wù)產(chǎn)品化。阿里業(yè)務(wù)發(fā)展速度遠(yuǎn)遠(yuǎn)超過了DBA團(tuán)隊發(fā)展的速度，單獨(dú)依靠DBA重人工支持模式變得越來越困難，因此我們在幾年前開始嘗試通過產(chǎn)品來完成DBA人工做的一些工作。通過產(chǎn)品解決DBA人工服務(wù)的擴(kuò)展性問題，是我們最直接的訴求，希望能把DBA人工服務(wù)產(chǎn)品化。（2

3、）全局規(guī)模優(yōu)化。站在全局角度來看，數(shù)據(jù)庫規(guī)模迅速增大的同時也帶來了巨大的成本壓力。成本這塊怎么理解呢？只要業(yè)務(wù)有需求，理論上可以通過增加更多的機(jī)器來滿足業(yè)務(wù)需求。但從另外一個角度來講，這些機(jī)器是不是一定要加？是不是有一些機(jī)器可以通過優(yōu)化節(jié)省下來給新的業(yè)務(wù)服務(wù)？當(dāng)規(guī)模非常大時，所做的一小點(diǎn)規(guī)?；瘍?yōu)化，所節(jié)省的成本可能都是很可觀的。因此我們需要有全局規(guī)模優(yōu)化的能力，僅僅一個數(shù)據(jù)庫實例內(nèi)部做的優(yōu)化都是一些局部優(yōu)化，以全局角度來看是不夠的。（3）主動診斷。從運(yùn)維的角度來看，阿里同其它公司一樣，就是要盡量避免故障的發(fā)生。在阿里的業(yè)務(wù)場景下，大部分業(yè)務(wù)跟數(shù)據(jù)庫有著非常緊密的關(guān)系。數(shù)據(jù)庫一個微小的抖動，都可

4、能對業(yè)務(wù)造成非常大的影響，所以如何讓數(shù)據(jù)庫更穩(wěn)定是非常重要的業(yè)務(wù)訴求。比如一個最常見的情況，有很多線上SQL性能是有問題的，這些SQL會給業(yè)務(wù)穩(wěn)定性帶來一定的風(fēng)險。那么，我們能不能通過產(chǎn)品主動對線上有問題的SQL進(jìn)行主動診斷，提前做優(yōu)化，而不是SQL引起故障后才去優(yōu)化。（4）智能異常發(fā)現(xiàn)。線上業(yè)務(wù)負(fù)載不斷地變化，業(yè)務(wù)行為、用戶行為也在不斷地變化。傳統(tǒng)基于閾值設(shè)置報警的方式無法可靠、及時地發(fā)現(xiàn)數(shù)據(jù)庫故障或者異常。如何可靠地去發(fā)現(xiàn)數(shù)據(jù)庫異常，甚至是提前預(yù)測到故障的發(fā)生并進(jìn)行及時干預(yù)，是有很強(qiáng)的業(yè)務(wù)需求的，但同時也有非常大的技術(shù)挑戰(zhàn)，尤其是在阿里這么大數(shù)據(jù)庫規(guī)模場景下。（5）容量預(yù)估。還有一些業(yè)務(wù)訴

5、求是容量預(yù)估的需求。比如什么時候需要擴(kuò)容，如何更精準(zhǔn)地對數(shù)據(jù)庫容量做出預(yù)估，這些后面我會稍微展開一下。2、用戶訴求另外一部分訴求是使用數(shù)據(jù)庫這些人的訴求，也就是我們的開發(fā)人員。每個公司數(shù)據(jù)庫服務(wù)方式有所不同。這里我列了一些開發(fā)人員經(jīng)常會問到的一些問題，這些問題背后的訴求讓我們思考我們的產(chǎn)品站在開發(fā)者的角度，要解決什么問題。在業(yè)務(wù)發(fā)生異常時，需要快速定位到整個鏈路到底哪塊出了問題。之前DB對于開發(fā)者來說是一個黑盒，不管是信息透明方面，還是大家對數(shù)據(jù)庫領(lǐng)域的知識方面，對于DB的了解程度可能都不夠，不知道DB是什么狀態(tài)，發(fā)生了什么問題。具體來講用戶訴求主要有：（1）信息透明，自助優(yōu)化。我們期望用戶能

6、夠自助發(fā)現(xiàn)和解決數(shù)據(jù)庫的性能問題，并非發(fā)現(xiàn)問題先去找DBA，這樣整個流程會比較長，時間成本也比較高。但做到自助化，首先用戶能夠全面了解數(shù)據(jù)庫的運(yùn)行情況。（2）持續(xù)優(yōu)化。只要業(yè)務(wù)在線上運(yùn)行就會不斷的變化，業(yè)務(wù)負(fù)載不斷變化、用戶行為也會不斷變化。所以數(shù)據(jù)庫優(yōu)化是個持續(xù)的過程，并不是今天發(fā)現(xiàn)一個問題解決了，以后就不出現(xiàn)問題了。尤其是互聯(lián)網(wǎng)的應(yīng)用，持續(xù)優(yōu)化尤其重要。（3）量化跟蹤，流程閉環(huán)。開發(fā)人員經(jīng)常會問到一個問題，上次幫他做的優(yōu)化，結(jié)果到底怎么樣。我們知道并不是每個優(yōu)化都是實際有效的，因為很多優(yōu)化方案是基于當(dāng)時的信息和場景做的一個判斷，實際優(yōu)化結(jié)果只有當(dāng)應(yīng)用之后才能真正去做評估、做衡量，所以我們要

7、提供量化跟蹤和評估的能力。另外，我們期望整個優(yōu)化流程，從發(fā)現(xiàn)問題到最終解決問題在產(chǎn)品內(nèi)能夠閉環(huán)，開發(fā)人員能夠自己完全自助化走完整個流程，而不需要DBA的參與。流程閉環(huán)也是產(chǎn)品必須具備的能力。（4）輸出產(chǎn)品，而不是人。不斷有新的業(yè)務(wù)上線，而我們的DBA就這么多人，并且每個人有不同的側(cè)重。對于一些快速發(fā)展的業(yè)務(wù)，在早期我們可能沒有DBA去做特別支持的，但這些業(yè)務(wù)的數(shù)據(jù)庫反而是容易出問題的。開發(fā)人員如果能夠通過產(chǎn)品解決問題，而不是凡事都去找DBA，解決問題的效率會更高。將我們DBA的能力通過產(chǎn)品進(jìn)行輸出，更好去支持我們的業(yè)務(wù)。所以今天做這個產(chǎn)品，是希望能夠通過產(chǎn)品的方式把DBA專家服務(wù)提供給我們的業(yè)

8、務(wù)開發(fā)同學(xué)，實現(xiàn)DBA人力的擴(kuò)展。同時我們需要具備全局規(guī)模優(yōu)化能力，這是在阿里對數(shù)據(jù)庫優(yōu)化服務(wù)的業(yè)務(wù)訴求和用戶訴求，也是我們做這個產(chǎn)品的動機(jī)。二、CloudDBA關(guān)鍵技術(shù)首先簡單介紹下CloudDBA在阿里的發(fā)展歷程。早期我們團(tuán)隊有很多非常牛的DBA，經(jīng)常是一個人當(dāng)千軍萬馬的感覺，那個階段優(yōu)化更多依賴于DBA人工完成。之后我們開發(fā)了一些工具，讓工具來完成簡單的優(yōu)化操作。幾年前，我們的理念轉(zhuǎn)變?yōu)樗袛?shù)據(jù)庫服務(wù)都應(yīng)該由產(chǎn)品來做，所以我們在數(shù)據(jù)庫運(yùn)維、管理、優(yōu)化等方面都有相應(yīng)的產(chǎn)品，開始進(jìn)入自動化階段。未來數(shù)據(jù)庫優(yōu)化服務(wù)會從自動化發(fā)展到智能化，這是我的判斷。今天仍然有很多問題是解決不了的，比如精確的

9、容量預(yù)估，智能的異常發(fā)現(xiàn)，故障提前預(yù)警等。現(xiàn)在我們有非常多的數(shù)據(jù)，也有數(shù)據(jù)加工分析的技術(shù)，所以我們開始進(jìn)行一些探索，通過數(shù)據(jù)分析和機(jī)器學(xué)習(xí)等技術(shù)手段來解決之前解決不了的問題。比如最簡單的容量預(yù)估，每年都會做預(yù)算，做容量預(yù)估。至少我現(xiàn)在還沒有看到特別多的公司去用很科學(xué)的方式，完全基于業(yè)務(wù)目標(biāo)以及歷史數(shù)據(jù)的分析來做容量預(yù)估。很多時候容量預(yù)估是靠拍腦袋決定的，但是今天有了大量的數(shù)據(jù)和加工數(shù)據(jù)的技術(shù)手段，我們是不是可以做更精準(zhǔn)的容量預(yù)估。舉這個例子來說明一下，未來很多的優(yōu)化應(yīng)該向智能化方向去思考，去探索。CloudDBA在阿里大概是這樣的一個發(fā)展歷程，我們今天還處于自動化階段，但同時也有一些智能化的實

10、踐。未來我的判斷是一定向智能化去走，后面會在這方面嘗試更多的探索。說了這么多，CloudDBA到底是什么？這有一句話：“CloudDBA是一個數(shù)據(jù)庫智能優(yōu)化產(chǎn)品，面向開發(fā)人員提供自助化診斷優(yōu)化服務(wù)，致力于成為用戶身邊的數(shù)據(jù)庫專家。”CloudDBA不是給DBA開發(fā)的工具，從一開始我們的用戶定義就很明確。我們是面向使用數(shù)據(jù)庫的開發(fā)人員提供這種自助化的診斷優(yōu)化服務(wù)，我們的用戶不是DBA，而是真正使用數(shù)據(jù)庫的開發(fā)同學(xué)。面向DBA和面向開發(fā)同學(xué)對產(chǎn)品來講是完全不同的概念。比如開發(fā)同學(xué)沒有太多數(shù)據(jù)庫背景知識，我們即使做簡單的信息透明，也需要做一些翻譯，能夠讓開發(fā)同學(xué)理解。用戶定義不同，數(shù)據(jù)的加工、分析以

11、及最終的呈現(xiàn)，都是完全不一樣的。接下來講一下CloudDBA到底能做什么。這是我們簡化版的整體架構(gòu)，涉及的面比較廣。從下到上分為四層：（1）最下面是我們的采集層。對所有數(shù)據(jù)庫進(jìn)行實時的秒級數(shù)據(jù)采集，包括性能指標(biāo)、日志數(shù)據(jù)、SQL流水、DB內(nèi)部的一些信息等。（2）采集完之后數(shù)據(jù)到達(dá)計算層，計算層分兩大塊。一部分是實時計算，對于SQL流水、監(jiān)控指標(biāo)等，都會做實時計算和展示。另一部分是離線分析，比如性能基線、讀寫熱點(diǎn)、統(tǒng)計報表等。（3）再往上就是數(shù)據(jù)庫診斷服務(wù)層。如果大家做過系統(tǒng)的數(shù)據(jù)庫優(yōu)化，就清楚數(shù)據(jù)庫優(yōu)化會涉及到很多方面。最常見的就是SQL優(yōu)化，SQL是不是很慢、有沒有走到最優(yōu)路徑、SQL寫法是

12、否合理等等。SQL相關(guān)問題是我們開發(fā)經(jīng)常會遇到的。還有其它一些問題，比如說空間、會話、鎖、安全、配置等，CloudDBA能夠?qū)B的每一個方面提供相應(yīng)的專家診斷服務(wù)。（4）最上面是接入層，在阿里內(nèi)部通過企業(yè)數(shù)據(jù)庫服務(wù)平臺iDB作為入口向開發(fā)同學(xué)提供數(shù)據(jù)庫優(yōu)化服務(wù)。接下來跟大家分享一下我們做這個產(chǎn)品的一些產(chǎn)品設(shè)計原則。如果大家也在做類似的產(chǎn)品，希望能夠給大家一些參考。之前我們數(shù)據(jù)庫優(yōu)化主要是DBA來做，但DBA人工優(yōu)化不具備擴(kuò)展性，CloudDBA第一個設(shè)計原則就是要提供自助化服務(wù)，希望整個優(yōu)化過程只有開發(fā)參與，并且整個優(yōu)化流程能在CloudDBA里實現(xiàn)閉環(huán)。由于業(yè)務(wù)負(fù)載會不斷地變化，需要對所有

13、線上數(shù)據(jù)庫進(jìn)行持續(xù)的主動診斷，及時發(fā)現(xiàn)和解決數(shù)據(jù)庫性能問題。另外，這個產(chǎn)品需要有全局的視角，能夠從全局角度發(fā)現(xiàn)規(guī)模優(yōu)化點(diǎn)，具備規(guī)模優(yōu)化能力，并且能夠量化規(guī)模優(yōu)化的收益。還有最后兩點(diǎn)非常重要，首先就是數(shù)據(jù)驅(qū)動。從我個人理解，今天要做這樣一個優(yōu)化產(chǎn)品，首先要有足夠的數(shù)據(jù)，然后用數(shù)據(jù)分析和挖掘的技術(shù)手段，再結(jié)合數(shù)據(jù)庫領(lǐng)域知識，給出更合理的診斷優(yōu)化建議。智能化是我們對于數(shù)據(jù)庫優(yōu)化產(chǎn)品未來發(fā)展方向的判斷，也是我們一直在堅持探索的。時間關(guān)系今天無法全部展開，接下來重點(diǎn)展開幾個方面。一個是CloudDBA的SQL優(yōu)化怎么做的，還有一個是空間優(yōu)化，另外就是CloudDBA全量SQL采集和分析。最后會分享一下我

14、們在智能化方向的探索。SQL診斷先說一下SQL優(yōu)化，不知道大家平時做SQL優(yōu)化時是怎樣的流程。大家回想一下，你是怎么發(fā)現(xiàn)哪些SQL需要優(yōu)化的？要知道優(yōu)化什么，為什么要優(yōu)化它，然后再考慮怎么去優(yōu)化。還有一個問題是優(yōu)化完之后效果到底怎么樣，是不是真的有效。整個優(yōu)化過程不管是開發(fā)還是DBA做，都需要形成一個閉環(huán)。CloudDBA實現(xiàn)了這么一個閉環(huán)。第一步?jīng)Q定哪些SQL需要優(yōu)化，第二步是如何優(yōu)化，第三步是優(yōu)化后效果如何，要做量化跟蹤，確認(rèn)是不是有效。如果發(fā)現(xiàn)沒有效果，再次重復(fù)這個優(yōu)化流程，直到問題被解決。這是SQL優(yōu)化的大概流程。我們實現(xiàn)了一個類似MySQL優(yōu)化器的What-if optimizer。

15、舉個例子說明一下What-if optimizer是什么。比如一條SQL查詢有10個可選的訪問路徑，MySQL優(yōu)化器目標(biāo)是要從這10個路徑選擇訪問代價最低的一個路徑。而What-ifoptimizer要做的事情是如何規(guī)劃出第11條路，讓這條路比現(xiàn)有的10條路都快。難點(diǎn)在于這條路是不存在的，這個路怎么修，修完之后是不是真的更快，這些是What-if optimizer要解決的問題。比如一個常見的SQL優(yōu)化手段是索引，那建什么樣的索引會比當(dāng)前所有執(zhí)行路徑都好？這是我們的SQL優(yōu)化引擎要解決的問題，也是我們產(chǎn)品比較核心的部分。大家可以看一下這個流程，前面幾步跟MySQL或者其它優(yōu)化器類似，但后面的候

16、選索引生成，代價評估，優(yōu)化建議合并等都不一樣。我們的輸入是一條SQL或者一個SQL workload，輸出是對應(yīng)的優(yōu)化建議，比如新建索引、SQL改寫等。SQL優(yōu)化最關(guān)鍵的是要有全面準(zhǔn)確的統(tǒng)計信息作為輸入，另外就是它不能是規(guī)則式的，因為SQL的執(zhí)行路徑與數(shù)據(jù)分布有很大的關(guān)系。同樣一條SQL，數(shù)據(jù)分布不一樣，實際執(zhí)行路徑可能會完全不一樣。SQL優(yōu)化這塊有幾個關(guān)鍵點(diǎn)需要強(qiáng)調(diào)一下：（1）全局視角。如果業(yè)務(wù)SQL非常多，假設(shè)有100類SQL(模板化后)，挑選哪些SQL來優(yōu)化是非常關(guān)鍵的。是對這100類都做優(yōu)化，還是選出其中一些重要的SQL？通常會選擇性能有問題的SQL優(yōu)化，但怎么選呢？CloudDBA有

17、全量SQL性能統(tǒng)計數(shù)據(jù)，會分析出查詢效率低且有優(yōu)化空間的SQL Workload來進(jìn)行優(yōu)化。（2）代價評估(Cost-based Optimizer)。比如一條SQL可能會有多個索引建議，哪個建議是最優(yōu)的？候選索引生成階段確定某列是不是可以放到候選索引里，也需要結(jié)合統(tǒng)計信息來評估。這些過程都需要基于代價進(jìn)行評估，而不是規(guī)則。（3）動態(tài)采樣。優(yōu)化器在做路徑選擇時很重要的一個輸入是統(tǒng)計信息，對于我們的What-if optimizer也一樣。我們通過動態(tài)采樣來獲取代價評估所需要的統(tǒng)計信息，包括Cardinality, Frequency還有Histogram等。數(shù)據(jù)傾斜比較嚴(yán)重的時候，Histog

18、ram對做出準(zhǔn)確的代價評估非常關(guān)鍵。為了更準(zhǔn)確的代價評估，所以我們實現(xiàn)了一個動態(tài)采樣系統(tǒng)。量化跟蹤C(jī)loudDBA的SQL診斷在阿里內(nèi)部怎么使用呢？我們選擇出要優(yōu)化的SQL之后會有一個優(yōu)化按紐來發(fā)起診斷流程。對單條SQL來講，診斷結(jié)果包括SQL文本，現(xiàn)在的執(zhí)行計劃大概是什么樣子，以及我們針對這條SQL給出的優(yōu)化建議。比如這個SQL給出一個新建索引的建議。這個建議我們目前直接給到了開發(fā)，開發(fā)同學(xué)會可以應(yīng)用這個建議，自助去創(chuàng)建這個索引。那如何判斷索引建議是否有效？前面提到優(yōu)化流程閉環(huán)很重要的一環(huán)就是量化跟蹤。這里有一個例子，是CloudDBA推薦的索引被開發(fā)采納后24小時的性能量化跟蹤情況。這兩個

19、框圈出來的時間點(diǎn)是索引生效的時間點(diǎn)，下面兩個圖表示優(yōu)化建議被采納前后的性能對比。會分析這個優(yōu)化建議對直接優(yōu)化SQL，以及該索引可能影響到的SQL，以及整個實例的性能影響，來量化判定和評估這次這個優(yōu)化的建議是否有效。能夠發(fā)現(xiàn)問題，找出問題根本原因，給出問題解決方案，并且可以應(yīng)用到線上，然后完成量化評估，整個優(yōu)化閉環(huán)在產(chǎn)品里做到閉環(huán)。只有這樣，開發(fā)自助優(yōu)化才能真正實現(xiàn)，我們才能拿到最終的優(yōu)化結(jié)果，中間少任何一環(huán)都很麻煩。比如說沒有量化評估手段，用戶采納建議的動力就會小很多，因為即使應(yīng)用了之后，也無法知道到底是不是有效。今天SQL診斷在CloudDBA可以做到整個流程閉環(huán)?？臻g優(yōu)化接下來簡單說一下空

20、間優(yōu)化。不知道大家平時有沒有關(guān)注過自己DB空間使用情況。過去大多時候數(shù)據(jù)庫空間不夠首先考慮就是擴(kuò)容，加機(jī)器。在阿里當(dāng)然也有這樣的擴(kuò)容需求，但今天我們首先考慮的是優(yōu)化現(xiàn)有存儲空間。比如有的表數(shù)據(jù)有十列，但索引就建了二三十個，這個是不合理的。有的開發(fā)同學(xué)根據(jù)自己的SQL上去就建一個索引，他并沒有看有沒有建相關(guān)的索引，他可能只會建一個對他有用的索引。有些索引自從建了之后從來沒被訪問過，也有的索引是和其它索引只是索引名字不同但完全重復(fù)的，這些都造成了空間的消耗。因此CloudDBA在空間優(yōu)化方面做了非常全面、深入的分析，也花了很大力氣去做，因為對阿里今天的數(shù)據(jù)庫規(guī)模來講空間成本非常高。（1）存儲優(yōu)化。

21、通過數(shù)據(jù)存儲方式的優(yōu)化來節(jié)省存儲空間。比如分析出來有些數(shù)據(jù)表字段占用空間較大且可以做壓縮時，我們會建議用戶做壓縮。對于數(shù)據(jù)量特別大，但訪問量又不是特別高的實例，我們會建議數(shù)據(jù)庫做存儲引擎的遷移，從InnoDB切換到RocksDB，以獲取更高的壓縮比來節(jié)省空間。（2）空間回收。通過回收無用數(shù)據(jù)對象占用空間來優(yōu)化存儲空間，包括對表碎片進(jìn)行分析和回收，重復(fù)索引/無用索引刪除，無流量表刪除等。業(yè)務(wù)不斷變化，業(yè)務(wù)相關(guān)SQL也會變化，有些表或者索引在業(yè)務(wù)變化后可能就再沒有人訪問了，但還占了非常昂貴的在線存儲空間，這些空間都是可以回收的。（3）數(shù)據(jù)遷移。把數(shù)據(jù)庫里存放時間過久且不被訪問的數(shù)據(jù)遷移到更低成本的

22、離線存儲上。CloudDBA會分析一張表的數(shù)據(jù)存儲時間分布情況，比如有百分之多少的數(shù)據(jù)是3個月以內(nèi)，多少數(shù)據(jù)是3個月到6個月，多少數(shù)據(jù)是6個月到1年等等。開發(fā)同學(xué)根據(jù)自己的業(yè)務(wù)需求結(jié)合數(shù)據(jù)生命周期來判斷哪些數(shù)據(jù)可以做遷移或者清理。CloudDBA會對線上所有數(shù)據(jù)庫空間進(jìn)行主動診斷，并且提供一鍵優(yōu)化功能，開發(fā)同學(xué)可以自助化完成數(shù)據(jù)庫的空間優(yōu)化。數(shù)據(jù)驅(qū)動前面提到CloudDBA產(chǎn)品的設(shè)計原則，有一個很重要的核心理念就是數(shù)據(jù)驅(qū)動。數(shù)據(jù)驅(qū)動的前提先得有數(shù)據(jù)。阿里的數(shù)據(jù)庫規(guī)模下數(shù)據(jù)采集處理還是很有挑戰(zhàn)的，因為規(guī)模太大了。今天我們所有數(shù)據(jù)都是秒級采集、分析和展現(xiàn)。過去幾年我們花了很多精力建設(shè)了一個可靠的數(shù)

23、據(jù)通道，對采集上來的數(shù)據(jù)進(jìn)行實時分析和離線分析。因為我們堅信未來CloudDBA產(chǎn)品一定向數(shù)據(jù)化、智能化的方向走，雖然數(shù)據(jù)通道和計算花了很多的精力，但是產(chǎn)生的數(shù)據(jù)價值很高。數(shù)據(jù)驅(qū)動這塊今天重點(diǎn)說一下全量SQL分析。如果要對數(shù)據(jù)庫性能進(jìn)行診斷，單純看慢SQL是不夠的。有些業(yè)務(wù)對latency很敏感，盡管SQL沒有達(dá)到慢SQL標(biāo)準(zhǔn)，比如MySQL里默認(rèn)的1秒，但業(yè)務(wù)已經(jīng)感覺到明顯的異常，因此需要對數(shù)據(jù)庫實例上的全部SQL進(jìn)行分析，了解當(dāng)前實例正在執(zhí)行哪些SQL，性能如何。CloudDBA對全網(wǎng)數(shù)據(jù)庫實例上全部SQL進(jìn)行實時采集、分析和展現(xiàn)，并且基于這些數(shù)據(jù)來驅(qū)動整個診斷優(yōu)化流程。先看一下全量SQL

24、分析的數(shù)據(jù)通道。我們的AliSQL內(nèi)核實現(xiàn)了非常輕量級SQL流水采集，包括SQL來源，SQL文本，執(zhí)行時間，鎖等待時間，掃描行數(shù)/返回行數(shù)、邏輯/物理讀等信息。這些信息會實時地上報到Kafka,然后利用JStorm對全量SQL進(jìn)行各種維度的實時計算和分析。另外，對實時計算完的數(shù)據(jù)我們還會進(jìn)行很多離線分析。目前全量SQL流水采集在阿里基本上全網(wǎng)覆蓋，實時計算數(shù)據(jù)量達(dá)到千萬級SQL/秒，離線計算數(shù)據(jù)量達(dá)到百TB/天。這里列出了一些我們基于全量SQL分析進(jìn)一步做的一些事情。首先用戶通過CloudDBA可以實時查看當(dāng)前實例正在執(zhí)行的全部SQL信息以及性能趨勢，這些信息能夠更全面了解業(yè)務(wù)SQL的健康情況

25、，比如對執(zhí)行耗時占比較高但執(zhí)行效率較低，執(zhí)行頻繁但索引缺失，執(zhí)行性能有明顯波動以及新增SQL等進(jìn)行了識別。對于有分庫分表的業(yè)務(wù)，我們能夠識別是否有讀寫熱點(diǎn)。對線上的優(yōu)化操作可以更好地進(jìn)行性能優(yōu)化度量。還有從安全的角度，可以進(jìn)行全面的SQL審計，還有我們也進(jìn)行一些實際業(yè)務(wù)模型的分析。再簡單說一下基于數(shù)據(jù)驅(qū)動在全局優(yōu)化方面做的一些事情。前面講業(yè)務(wù)訴求提到了需要有全局規(guī)模優(yōu)化的能力，全局優(yōu)化方面我們也構(gòu)造了一個閉環(huán)?；诤Ａ繑?shù)據(jù)分析，從“發(fā)現(xiàn)規(guī)模優(yōu)化點(diǎn)”，“估算預(yù)期收益”，到提供全局“優(yōu)化決策輸入”，開始“規(guī)模優(yōu)化”，然后進(jìn)行“實際收益量化跟蹤”，以及最后的“規(guī)模優(yōu)化效果評定”，整個流程在Cloud

26、DBA內(nèi)部形成閉環(huán)。比如我們的全網(wǎng)空間優(yōu)化，基于上就是通過這個閉環(huán)流程完成，同時CloudDBA會給出空間規(guī)模優(yōu)化的實際收益。全局優(yōu)化方面，我們期望能夠真正做到數(shù)據(jù)驅(qū)動，包括建立全網(wǎng)性能成本模型，建立性能成本基線等，能夠基于數(shù)據(jù)分析發(fā)現(xiàn)收益較大的規(guī)模優(yōu)化點(diǎn)。這方面我們還在持續(xù)地做更多的事情。三、數(shù)據(jù)庫智能優(yōu)化探索最后分享一些我們在智能優(yōu)化方向的一些探索。利用數(shù)據(jù)分析和機(jī)器學(xué)習(xí)的一些技術(shù)，我們嘗試去解決數(shù)據(jù)庫領(lǐng)域之前較難解決的一些問題。這塊有很大的想像空間，目前我們主要是在以下幾個方面進(jìn)行探索：1、異常檢測/關(guān)聯(lián)分析上午我聽了一個分享講在其它領(lǐng)域的異常發(fā)現(xiàn)/關(guān)聯(lián)分析，異常檢測不僅是數(shù)據(jù)庫領(lǐng)域，在其它運(yùn)維領(lǐng)域也有需求，是一個共性的問題。運(yùn)維同學(xué)做監(jiān)控，異?，F(xiàn)在怎么發(fā)現(xiàn)？通常的做法是依賴報警，但報警的閾值怎么定？定高了到時候故障發(fā)生了報警還沒出來，定低了收到一堆報警，都是誤報。能不能做到智能的異常發(fā)現(xiàn)？比如說某個數(shù)據(jù)庫實例跟之前的歷史行為有比較大的不同，但并沒有觸發(fā)報警，我如何能第一時間知道？因為發(fā)現(xiàn)得越晚，線上的損失就會越大，在阿里的場景這個是有直接的業(yè)務(wù)訴求。及時發(fā)現(xiàn)異常，快速定位原因，減少業(yè)務(wù)影響。清華的裴丹老師也講了，異常發(fā)現(xiàn)對于分鐘級的數(shù)據(jù)，目前一些現(xiàn)有算法是適用的，稍微做一些加工就會有比較明顯的效果。但是我們