阿里在数据库智能优化路上_做了哪些探索与实践？
原文地址
近期，2017中國(guó)應(yīng)用性能管理大會(huì)（簡(jiǎn)稱APMCon 2017）圓滿落幕。阿里巴巴數(shù)據(jù)庫(kù)事業(yè)部高級(jí)技術(shù)專家喬紅麟發(fā)表了題為《數(shù)據(jù)庫(kù)智能優(yōu)化系統(tǒng)的探索與實(shí)踐》的演講，現(xiàn)場(chǎng)解讀了過(guò)去幾年阿里巴巴數(shù)據(jù)庫(kù)團(tuán)隊(duì)在面對(duì)數(shù)據(jù)庫(kù)規(guī)模急速增長(zhǎng)以及業(yè)務(wù)變化越來(lái)越快的情況下在智能數(shù)據(jù)庫(kù)診斷優(yōu)化方面的一些探索和實(shí)踐經(jīng)驗(yàn)。
以下為演講實(shí)錄：
喬紅麟：謝謝主持人，大家下午好。今天給大家分享一下我們團(tuán)隊(duì)在數(shù)據(jù)庫(kù)優(yōu)化方面做的一些事情。阿里的數(shù)據(jù)庫(kù)場(chǎng)景與其他公司可能會(huì)有一些不同，所以今天的分享更多是基于阿里的場(chǎng)景和規(guī)模所做的一些思考和實(shí)踐。
先簡(jiǎn)單介紹一下我自己。我在2015年加入阿里，目前負(fù)責(zé)阿里數(shù)據(jù)庫(kù)智能優(yōu)化產(chǎn)品CloudDBA的開發(fā)。我今天的分享主要有這幾方面：
首先講一下在阿里對(duì)數(shù)據(jù)庫(kù)優(yōu)化服務(wù)的訴求。我相信大家在數(shù)據(jù)庫(kù)性能優(yōu)化方面都有很多的經(jīng)驗(yàn)教訓(xùn)，不同公司對(duì)優(yōu)化的具體做法也不太一樣。在方式上大部分企業(yè)應(yīng)該還是重人工模式，就是由數(shù)據(jù)庫(kù)能力比較強(qiáng)的人，比如DBA，來(lái)解決數(shù)據(jù)庫(kù)性能問(wèn)題。但阿里今天的數(shù)據(jù)庫(kù)規(guī)模非常大，不管我們有多少DBA，我們的人員增長(zhǎng)速度都無(wú)法跟上業(yè)務(wù)發(fā)展的速度，單純依賴DBA已經(jīng)無(wú)法滿足業(yè)務(wù)發(fā)展需求。
第二方面講一下我們的CloudDBA是如何做的，里面涉及到哪些技術(shù)，希望把這些技術(shù)分享給大家。如果大家所在的公司也在做類似的事情，希望能夠提供一些參考和幫助。
第三方面大概講一下目前正在探索的一些事情。現(xiàn)在人工智能技術(shù)比較火，數(shù)據(jù)庫(kù)相對(duì)來(lái)說(shuō)是比較傳統(tǒng)的領(lǐng)域。如果我們將機(jī)器學(xué)習(xí)、深度學(xué)習(xí)這樣的技術(shù)引入到數(shù)據(jù)庫(kù)領(lǐng)域，它到底能做些什么，具體到數(shù)據(jù)庫(kù)優(yōu)化領(lǐng)域又能做什么，這是我們正在探索的一些事情。
一、阿里數(shù)據(jù)庫(kù)優(yōu)化服務(wù)訴求
第一部分、業(yè)務(wù)訴求
首先從整個(gè)阿里數(shù)據(jù)庫(kù)的角度看一下對(duì)于數(shù)據(jù)庫(kù)優(yōu)化服務(wù)的業(yè)務(wù)訴求，這也是我們做這個(gè)產(chǎn)品最大的驅(qū)動(dòng)力。
1、服務(wù)產(chǎn)品化。阿里業(yè)務(wù)發(fā)展速度遠(yuǎn)遠(yuǎn)超過(guò)了DBA團(tuán)隊(duì)發(fā)展的速度，單獨(dú)依靠DBA重人工支持模式變得越來(lái)越困難，因此我們?cè)趲啄昵伴_始嘗試通過(guò)產(chǎn)品來(lái)完成DBA人工做的一些工作。通過(guò)產(chǎn)品解決DBA人工服務(wù)的擴(kuò)展性問(wèn)題，是我們最直接的訴求，希望能把DBA人工服務(wù)產(chǎn)品化。
2、全局規(guī)模優(yōu)化。站在全局角度來(lái)看，數(shù)據(jù)庫(kù)規(guī)模迅速增大的同時(shí)也帶來(lái)了巨大的成本壓力。成本這塊怎么理解呢？只要業(yè)務(wù)有需求，理論上可以通過(guò)增加更多的機(jī)器來(lái)滿足業(yè)務(wù)需求。但是從另外一個(gè)角度來(lái)講，這些機(jī)器是不是一定要加，是不是有一些機(jī)器可以通過(guò)優(yōu)化節(jié)省下來(lái)給新的業(yè)務(wù)服務(wù)。當(dāng)規(guī)模非常大的時(shí)候，所做的一小點(diǎn)規(guī)模化優(yōu)化，所節(jié)省的成本可能都是很可觀的。因此我們需要有全局規(guī)模優(yōu)化的能力，僅僅一個(gè)數(shù)據(jù)庫(kù)實(shí)例內(nèi)部做的優(yōu)化都是一些局部?jī)?yōu)化，以全局角度來(lái)看是不夠的。
3、主動(dòng)診斷。從運(yùn)維的角度來(lái)看，阿里同其它公司一樣，就是要盡量避免故障的發(fā)生。在阿里的業(yè)務(wù)場(chǎng)景下，大部分業(yè)務(wù)跟數(shù)據(jù)庫(kù)有著非常緊密的關(guān)系。數(shù)據(jù)庫(kù)一個(gè)微小的抖動(dòng)，都可能對(duì)業(yè)務(wù)造成非常大的影響，所以如何讓數(shù)據(jù)庫(kù)更穩(wěn)定是非常重要的業(yè)務(wù)訴求。比如一個(gè)最常見的情況，有很多線上SQL性能是有問(wèn)題的，這些SQL會(huì)給業(yè)務(wù)穩(wěn)定性帶來(lái)一定的風(fēng)險(xiǎn)。那么我們能不能通過(guò)產(chǎn)品主動(dòng)對(duì)線上有問(wèn)題的SQL進(jìn)行主動(dòng)診斷，提前做優(yōu)化，而不是SQL引起故障后才去優(yōu)化。
4、智能異常發(fā)現(xiàn)。線上業(yè)務(wù)負(fù)載不斷地變化，業(yè)務(wù)行為、用戶行為也在不斷地變化。傳統(tǒng)基于閾值設(shè)置報(bào)警的方式無(wú)法可靠、及時(shí)地發(fā)現(xiàn)數(shù)據(jù)庫(kù)故障或者異常。如何可靠地去發(fā)現(xiàn)數(shù)據(jù)庫(kù)異常，甚至是提前預(yù)測(cè)到故障的發(fā)生并進(jìn)行及時(shí)干預(yù)，是有很強(qiáng)的業(yè)務(wù)需求的，但同時(shí)也有非常大的技術(shù)挑戰(zhàn)，尤其是在阿里這么大數(shù)據(jù)庫(kù)規(guī)模場(chǎng)景下。
第二部分、用戶訴求
另外一部分訴求是使用數(shù)據(jù)庫(kù)這些人的訴求，也就是我們的開發(fā)人員。每個(gè)公司數(shù)據(jù)庫(kù)服務(wù)方式有所不同。這里我列了一些開發(fā)人員經(jīng)常會(huì)問(wèn)到的一些問(wèn)題，這些問(wèn)題背后的訴求讓我們思考我們的產(chǎn)品站在開發(fā)者的角度，要解決什么問(wèn)題。在業(yè)務(wù)發(fā)生異常的時(shí)候，需要快速定位到整個(gè)鏈路到底哪塊出了問(wèn)題。之前DB對(duì)于開發(fā)者來(lái)說(shuō)是一個(gè)黑盒，不管是信息透明方面，還是大家對(duì)數(shù)據(jù)庫(kù)領(lǐng)域的知識(shí)方面，對(duì)于DB的了解程度可能都不夠，不知道DB是什么狀態(tài)，發(fā)生了什么問(wèn)題。具體來(lái)講用戶訴求主要有：
1、信息透明，自助優(yōu)化。我們期望用戶能夠自助發(fā)現(xiàn)和解決數(shù)據(jù)庫(kù)的性能問(wèn)題，并非發(fā)現(xiàn)問(wèn)題先去找DBA，這樣整個(gè)流程會(huì)比較長(zhǎng)，時(shí)間成本也比較高。但做到自助化，首先用戶能夠全面了解數(shù)據(jù)庫(kù)的運(yùn)行情況。
2、持續(xù)優(yōu)化。只要業(yè)務(wù)在線上運(yùn)行就會(huì)不斷的變化，業(yè)務(wù)負(fù)載不斷變化、用戶行為也會(huì)不斷變化。所以數(shù)據(jù)庫(kù)優(yōu)化是個(gè)持續(xù)的過(guò)程，并不是今天發(fā)現(xiàn)一個(gè)問(wèn)題解決了，以后就不出現(xiàn)問(wèn)題了。尤其是互聯(lián)網(wǎng)的應(yīng)用，持續(xù)優(yōu)化尤其重要。
3、量化跟蹤，流程閉環(huán)。開發(fā)人員經(jīng)常會(huì)問(wèn)到一個(gè)問(wèn)題，上次幫他做的優(yōu)化，結(jié)果到底怎么樣。我們知道并不是每個(gè)優(yōu)化都是實(shí)際有效的，因?yàn)楹芏鄡?yōu)化方案是基于當(dāng)時(shí)的信息和場(chǎng)景做的一個(gè)判斷，實(shí)際優(yōu)化結(jié)果只有當(dāng)應(yīng)用之后才能真正去做評(píng)估、做衡量，所以我們要提供量化跟蹤和評(píng)估的能力。另外，我們期望整個(gè)優(yōu)化流程，從發(fā)現(xiàn)問(wèn)題到最終解決問(wèn)題在產(chǎn)品內(nèi)能夠閉環(huán)，開發(fā)人員能夠自己完全自助化走完整個(gè)流程，而不需要DBA的參與。流程閉環(huán)也是產(chǎn)品必須具備的能力。
4、輸出產(chǎn)品，而不是人。不斷有新的業(yè)務(wù)上線，而我們的DBA就這么多人，并且每個(gè)人有不同的側(cè)重。對(duì)于一些快速發(fā)展的業(yè)務(wù)，在早期我們可能沒(méi)有DBA去做特別支持的，但這些業(yè)務(wù)的數(shù)據(jù)庫(kù)反而是容易出問(wèn)題的。開發(fā)人員如果能夠通過(guò)產(chǎn)品解決問(wèn)題，而不是凡事都去找DBA，解決問(wèn)題的效率會(huì)更高。將我們DBA的能力通過(guò)產(chǎn)品進(jìn)行輸出，更好去支持我們的業(yè)務(wù)。
所以今天我們做CloudDBA產(chǎn)品,是希望我們能夠通過(guò)產(chǎn)品的方式把DBA專家服務(wù)提供給業(yè)務(wù)開發(fā)同學(xué)，實(shí)現(xiàn)DBA人力的擴(kuò)展。同時(shí)我們需要具備全局規(guī)模優(yōu)化能力，這是在阿里對(duì)數(shù)據(jù)庫(kù)優(yōu)化服務(wù)的業(yè)務(wù)訴求和用戶訴求，也是我們做CloudDBA這個(gè)產(chǎn)品的動(dòng)機(jī)。
二、CloudDBA關(guān)鍵技術(shù)
首先簡(jiǎn)單介紹下CloudDBA在阿里的發(fā)展歷程。早期我們團(tuán)隊(duì)有很多非常牛的DBA，經(jīng)常是一個(gè)人當(dāng)千軍萬(wàn)馬的感覺，那個(gè)階段優(yōu)化更多依賴于DBA人工完成。之后我們開發(fā)了一些工具，讓工具來(lái)完成簡(jiǎn)單的優(yōu)化操作。幾年前我們的理念轉(zhuǎn)變?yōu)樗袛?shù)據(jù)庫(kù)服務(wù)都應(yīng)該由產(chǎn)品來(lái)做，所以我們?cè)跀?shù)據(jù)庫(kù)運(yùn)維，管理，優(yōu)化等方面都有相應(yīng)的產(chǎn)品，開始進(jìn)入自動(dòng)化階段。
未來(lái)數(shù)據(jù)庫(kù)優(yōu)化服務(wù)會(huì)從自動(dòng)化發(fā)展到智能化，這是我的判斷。今天仍然有很多問(wèn)題是解決不了的，比如精確的容量預(yù)估，智能的異常發(fā)現(xiàn)，故障提前預(yù)警等。現(xiàn)在我們有非常多的數(shù)據(jù)，也有數(shù)據(jù)加工分析的技術(shù)，所以我們開始進(jìn)行一些探索，通過(guò)數(shù)據(jù)分析和機(jī)器學(xué)習(xí)等技術(shù)手段來(lái)解決之前解決不了的問(wèn)題。比如最簡(jiǎn)單的容量預(yù)估，每年都會(huì)做預(yù)算，做容量預(yù)估。至少我現(xiàn)在還沒(méi)有看到特別多的公司去用很科學(xué)的方式，完全基于業(yè)務(wù)目標(biāo)以及歷史數(shù)據(jù)的分析來(lái)做容量預(yù)估。很多時(shí)候容量預(yù)估是靠拍腦袋決定的，但是今天有了大量的數(shù)據(jù)和加工數(shù)據(jù)的技術(shù)手段，我們是不是可以做更精準(zhǔn)的容量預(yù)估。舉這個(gè)例子來(lái)說(shuō)明一下，未來(lái)很多的優(yōu)化應(yīng)該向智能化方向去思考，去探索。
CloudDBA在阿里大概是這樣的一個(gè)發(fā)展歷程，我們今天還處于自動(dòng)化階段，但同時(shí)也有一些智能化的實(shí)踐。未來(lái)我的判斷是我們一定向智能化去走，后面會(huì)在這方面嘗試更多的探索。
說(shuō)了這么多，那么CloudDBA到底是什么？PPT上面有一句話，“CloudDBA是一個(gè)數(shù)據(jù)庫(kù)智能優(yōu)化產(chǎn)品，面向開發(fā)人員提供自助化診斷優(yōu)化服務(wù)，致力于成為用戶身邊的數(shù)據(jù)庫(kù)專家。” CloudDBA不是給DBA開發(fā)的工具，CloudDBA從一開始我們的用戶定義就很明確。我們是面向使用數(shù)據(jù)庫(kù)的開發(fā)人員提供這種自助化的診斷優(yōu)化服務(wù)，我們的用戶不是DBA，而是真正使用數(shù)據(jù)庫(kù)的開發(fā)同學(xué)。面向DBA和面向開發(fā)同學(xué)對(duì)產(chǎn)品來(lái)講是完全不同的概念。比如開發(fā)同學(xué)沒(méi)有太多數(shù)據(jù)庫(kù)背景知識(shí)，我們即使做簡(jiǎn)單的信息透明，也需要做一些翻譯，能夠讓開發(fā)同學(xué)理解。用戶定義不同，數(shù)據(jù)的加工、分析以及最終的呈現(xiàn)，都是完全不一樣的。
接下來(lái)講一下CloudDBA到底能做什么。這是我們簡(jiǎn)化版的整體架構(gòu)，涉及的面比較廣。從下到上分為四層：
1、最下面是我們的采集層。對(duì)所有數(shù)據(jù)庫(kù)進(jìn)行實(shí)時(shí)的秒級(jí)數(shù)據(jù)采集，包括性能指標(biāo)，日志數(shù)據(jù)、SQL流水，DB內(nèi)部的一些信息等等
2、采集完之后數(shù)據(jù)到達(dá)計(jì)算層，計(jì)算層分兩大塊。一部分是實(shí)時(shí)計(jì)算，對(duì)于SQL流水，監(jiān)控指標(biāo)等，都會(huì)做實(shí)時(shí)計(jì)算和展示。另一部分是離線分析，比如性能基線，讀寫熱點(diǎn)，統(tǒng)計(jì)報(bào)表等。
3、再往上就是數(shù)據(jù)庫(kù)診斷服務(wù)層。如果大家做過(guò)系統(tǒng)的數(shù)據(jù)庫(kù)優(yōu)化，就清楚數(shù)據(jù)庫(kù)優(yōu)化會(huì)涉及到很多方面。最常見的就是SQL優(yōu)化，SQL是不是很慢、有沒(méi)有走到最優(yōu)路徑、SQL寫法是否合理等等。SQL相關(guān)問(wèn)題是我們開發(fā)經(jīng)常會(huì)遇到的。還有其他一些問(wèn)題，比如說(shuō)空間，會(huì)話，鎖，安全，配置等，CloudDBA能夠?qū)B的每一個(gè)方面提供相應(yīng)的專家診斷服務(wù)。
4、最上面是接入層，在阿里內(nèi)部通過(guò)企業(yè)數(shù)據(jù)庫(kù)服務(wù)平臺(tái)iDB作為入口向開發(fā)同學(xué)提供數(shù)據(jù)庫(kù)優(yōu)化服務(wù)。
接下來(lái)跟大家分享一下我們做這個(gè)產(chǎn)品的一些產(chǎn)品設(shè)計(jì)原則。如果大家也在做類似的產(chǎn)品，希望能夠給大家一些參考。
之前我們數(shù)據(jù)庫(kù)優(yōu)化主要是DBA來(lái)做，但DBA人工優(yōu)化不具備擴(kuò)展性，CloudDBA第一個(gè)設(shè)計(jì)原則就是要提供自助化服務(wù)，希望整個(gè)優(yōu)化過(guò)程只有開發(fā)參與，并且整個(gè)優(yōu)化流程能在CloudDBA里實(shí)現(xiàn)閉環(huán)。
由于業(yè)務(wù)負(fù)載會(huì)不斷地變化，需要對(duì)所有線上數(shù)據(jù)庫(kù)進(jìn)行持續(xù)的主動(dòng)診斷，及時(shí)發(fā)現(xiàn)和解決數(shù)據(jù)庫(kù)性能問(wèn)題。
另外這個(gè)產(chǎn)品需要有全局的視角，能夠從全局角度發(fā)現(xiàn)規(guī)模優(yōu)化點(diǎn)，具備規(guī)模優(yōu)化能力，并且能夠量化規(guī)模優(yōu)化的收益。
還有最后兩點(diǎn)非常重要，首先就是數(shù)據(jù)驅(qū)動(dòng)。從我個(gè)人理解，今天要做這樣一個(gè)優(yōu)化產(chǎn)品，首先要有足夠的數(shù)據(jù)，然后用數(shù)據(jù)分析和挖掘的技術(shù)手段，再結(jié)合數(shù)據(jù)庫(kù)領(lǐng)域知識(shí)，給出更合理的診斷優(yōu)化建議。智能化是我們對(duì)于數(shù)據(jù)庫(kù)優(yōu)化產(chǎn)品未來(lái)發(fā)展方向的判斷，也是我們一直在堅(jiān)持探索的。
時(shí)間關(guān)系今天無(wú)法全部展開，接下來(lái)重點(diǎn)展開幾個(gè)方面。一個(gè)是CloudDBA的SQL優(yōu)化怎么做的，還有一個(gè)是空間優(yōu)化，另外就是CloudDBA全量SQL采集和分析。最后會(huì)分享一下我們?cè)谥悄芑较虻奶剿鳌?/p>
SQL診斷
先說(shuō)一下SQL優(yōu)化，不知道大家平時(shí)做SQL優(yōu)化時(shí)是怎樣的流程。大家回想一下，你是怎么發(fā)現(xiàn)哪些SQL需要優(yōu)化的？要知道優(yōu)化什么，為什么要優(yōu)化它，然后再考慮怎么去優(yōu)化。還有一個(gè)問(wèn)題是優(yōu)化完之后效果到底怎么樣，是不是真的有效。整個(gè)優(yōu)化過(guò)程不管是開發(fā)還是DBA做，都需要形成一個(gè)閉環(huán)。
CloudDBA產(chǎn)品實(shí)現(xiàn)了這么一個(gè)閉環(huán)。第一步?jīng)Q定哪些SQL需要優(yōu)化，第二步是如何優(yōu)化，第三步是優(yōu)化后效果如何，要做量化跟蹤，確認(rèn)是不是有效。如果發(fā)現(xiàn)沒(méi)有效果，再次重復(fù)這個(gè)優(yōu)化流程，直到問(wèn)題被解決。
這是CloudDBA里SQL優(yōu)化的大概流程。我們實(shí)現(xiàn)了一個(gè)類似MySQL優(yōu)化器的What-if optimizer。舉個(gè)例子說(shuō)明一下What-if optimizer是什么。比如一條SQL查詢有10個(gè)可選的訪問(wèn)路徑，MySQL優(yōu)化器目標(biāo)是要從這10個(gè)路徑選擇訪問(wèn)代價(jià)最低的一個(gè)路徑。而What-ifoptimizer要做的事情是如何規(guī)劃出第11條路，讓這條路比現(xiàn)有的10條路都快。難點(diǎn)在于這條路是不存在的，這個(gè)路怎么修，修完之后是不是真的更快，這些是What-if optimizer要解決的問(wèn)題。
比如一個(gè)常見的SQL優(yōu)化手段是索引，那建什么樣的索引會(huì)比當(dāng)前所有執(zhí)行路徑都好？這是我們的SQL優(yōu)化引擎要解決的問(wèn)題，也是我們產(chǎn)品比較核心的部分。大家可以看一下這個(gè)流程，前面幾步跟MySQL或者其他優(yōu)化器類似，但后面的候選索引生成，代價(jià)評(píng)估，優(yōu)化建議合并等都不一樣。我們的輸入是一條SQL或者一個(gè)SQL workload，輸出是對(duì)應(yīng)的優(yōu)化建議，比如新建索引，SQL改寫等。
SQL優(yōu)化最關(guān)鍵的是要有全面準(zhǔn)確的統(tǒng)計(jì)信息作為輸入，另外就是它不能是規(guī)則式的，因?yàn)镾QL的執(zhí)行路徑與數(shù)據(jù)分布有很大的關(guān)系。同樣一條SQL，數(shù)據(jù)分布不一樣，實(shí)際執(zhí)行路徑可能會(huì)完全不一樣。SQL優(yōu)化這塊有幾個(gè)關(guān)鍵點(diǎn)需要強(qiáng)調(diào)一下：
1、全局視角。如果業(yè)務(wù)SQL非常多，假設(shè)有100類SQL(模板化后)，挑選哪些SQL來(lái)優(yōu)化是非常關(guān)鍵的。是對(duì)這100類都做優(yōu)化，還是選出其中一些重要的SQL？通常會(huì)選擇性能有問(wèn)題的SQL優(yōu)化，但怎么選呢？CloudDBA有全量SQL性能統(tǒng)計(jì)數(shù)據(jù)，會(huì)分析出查詢效率低且有優(yōu)化空間的SQL Workload來(lái)進(jìn)行優(yōu)化。
2、代價(jià)評(píng)估(Cost-based Optimizer)。比如一條SQL可能會(huì)有多個(gè)索引建議，哪個(gè)建議是最優(yōu)的？候選索引生成階段確定某列是不是可以放到候選索引里，也需要結(jié)合統(tǒng)計(jì)信息來(lái)評(píng)估。這些過(guò)程都需要基于代價(jià)進(jìn)行評(píng)估，而不是規(guī)則。
3、動(dòng)態(tài)采樣。優(yōu)化器在做路徑選擇時(shí)很重要的一個(gè)輸入是統(tǒng)計(jì)信息，對(duì)于我們的What-if optimizer也一樣。我們通過(guò)動(dòng)態(tài)采樣來(lái)獲取代價(jià)評(píng)估所需要的統(tǒng)計(jì)信息，包括Cardinality, Frequency還有Histogram等。數(shù)據(jù)傾斜比較嚴(yán)重的時(shí)候，Histogram對(duì)做出準(zhǔn)確的代價(jià)評(píng)估非常關(guān)鍵。為了更準(zhǔn)確的代價(jià)評(píng)估，所以我們實(shí)現(xiàn)了一個(gè)動(dòng)態(tài)采樣系統(tǒng)。
量化跟蹤
CloudDBA的SQL診斷在阿里內(nèi)部怎么使用呢？我們選擇出要優(yōu)化的SQL之后會(huì)有一個(gè)優(yōu)化按紐來(lái)發(fā)起診斷流程。對(duì)單條SQL來(lái)講，診斷結(jié)果包括SQL文本，現(xiàn)在的執(zhí)行計(jì)劃大概是什么樣子，以及我們針對(duì)這條SQL給出的優(yōu)化建議。比如這個(gè)SQL給出一個(gè)新建索引的建議。這個(gè)建議我們目前直接給到了開發(fā)，開發(fā)同學(xué)會(huì)可以應(yīng)用這個(gè)建議，自助去創(chuàng)建這個(gè)索引。
那如何判斷索引建議是否有效？前面提到優(yōu)化流程閉環(huán)很重要的一環(huán)就是量化跟蹤。這里有一個(gè)例子，是CloudDBA推薦的索引被開發(fā)采納后24小時(shí)的性能量化跟蹤情況。這兩個(gè)框圈出來(lái)的時(shí)間點(diǎn)是索引生效的時(shí)間點(diǎn)，下面兩個(gè)圖表示優(yōu)化建議被采納前后的性能對(duì)比。會(huì)分析這個(gè)優(yōu)化建議對(duì)直接優(yōu)化SQL，以及該索引可能影響到的SQL，以及整個(gè)實(shí)例的性能影響，來(lái)量化判定和評(píng)估這次這個(gè)優(yōu)化的建議是否有效。
能夠發(fā)現(xiàn)問(wèn)題，找出問(wèn)題根本原因，給出問(wèn)題解決方案，并且可以應(yīng)用到線上，然后完成量化評(píng)估，整個(gè)優(yōu)化閉環(huán)在產(chǎn)品里做到閉環(huán)。只有這樣，開發(fā)自助優(yōu)化才能真正實(shí)現(xiàn)，我們才能拿到最終的優(yōu)化結(jié)果，中間少任何一環(huán)都很麻煩。比如說(shuō)沒(méi)有量化評(píng)估手段，用戶采納建議的動(dòng)力就會(huì)小很多，因?yàn)榧词箲?yīng)用了之后，也無(wú)法知道到底是不是有效。今天SQL診斷在CloudDBA可以做到整個(gè)流程閉環(huán)。
空間優(yōu)化
接下來(lái)簡(jiǎn)單說(shuō)一下空間優(yōu)化。不知道大家平時(shí)有沒(méi)有關(guān)注過(guò)自己DB空間使用情況。過(guò)去大多時(shí)候數(shù)據(jù)庫(kù)空間不夠首先考慮就是擴(kuò)容，加機(jī)器。在阿里當(dāng)然也有這樣的擴(kuò)容需求，但今天我們首先考慮的是優(yōu)化現(xiàn)有存儲(chǔ)空間。比如有的表數(shù)據(jù)有十列，但索引就建了二三十個(gè)，這個(gè)是不合理的。有的開發(fā)同學(xué)根據(jù)自己的SQL上去就建一個(gè)索引，他并沒(méi)有看有沒(méi)有建相關(guān)的索引，他可能只會(huì)建一個(gè)對(duì)他有用的索引。有些索引自從建了之后從來(lái)沒(méi)被訪問(wèn)過(guò)，也有的索引是和其他索引只是索引名字不同但完全重復(fù)的，這些都造成了空間的消耗。因此CloudDBA在空間優(yōu)化方面做了非常全面、深入的分析，也花了很大力氣去做，因?yàn)閷?duì)阿里今天的數(shù)據(jù)庫(kù)規(guī)模來(lái)講空間成本非常高。
1. 存儲(chǔ)優(yōu)化。通過(guò)數(shù)據(jù)存儲(chǔ)方式的優(yōu)化來(lái)節(jié)省存儲(chǔ)空間。比如分析出來(lái)有些數(shù)據(jù)表字段占用空間較大且可以做壓縮時(shí)，我們會(huì)建議用戶做壓縮。對(duì)于數(shù)據(jù)量特別大，但訪問(wèn)量又不是特別高的實(shí)例，我們會(huì)建議數(shù)據(jù)庫(kù)做存儲(chǔ)引擎的遷移，從InnoDB切換到RocksDB, 以獲取更高的壓縮比來(lái)節(jié)省空間。
2.空間回收。通過(guò)回收無(wú)用數(shù)據(jù)對(duì)象占用空間來(lái)優(yōu)化存儲(chǔ)空間，包括對(duì)表碎片進(jìn)行分析和回收，重復(fù)索引/無(wú)用索引刪除，無(wú)流量表刪除等。業(yè)務(wù)不斷變化，業(yè)務(wù)相關(guān)SQL也會(huì)變化，有些表或者索引在業(yè)務(wù)變化后可能就再?zèng)]有人訪問(wèn)了，但還占了非常昂貴的在線存儲(chǔ)空間，這些空間都是可以回收的。
3.數(shù)據(jù)遷移。把數(shù)據(jù)庫(kù)里存放時(shí)間過(guò)久且不被訪問(wèn)的數(shù)據(jù)遷移到更低成本的離線存儲(chǔ)上。CloudDBA會(huì)分析一張表的數(shù)據(jù)存儲(chǔ)時(shí)間分布情況，比如有百分之多少的數(shù)據(jù)是3個(gè)月以內(nèi)，多少數(shù)據(jù)是3個(gè)月到6個(gè)月，多少數(shù)據(jù)是6個(gè)月到1年等等。開發(fā)同學(xué)根據(jù)自己的業(yè)務(wù)需求結(jié)合數(shù)據(jù)生命周期來(lái)判斷哪些數(shù)據(jù)可以做遷移或者清理。
CloudDBA會(huì)對(duì)線上所有數(shù)據(jù)庫(kù)空間進(jìn)行主動(dòng)診斷，并且提供一鍵優(yōu)化功能，開發(fā)同學(xué)可以自助化完成數(shù)據(jù)庫(kù)的空間優(yōu)化。
數(shù)據(jù)驅(qū)動(dòng)
前面提到CloudDBA產(chǎn)品的設(shè)計(jì)原則，有一個(gè)很重要的核心理念就是數(shù)據(jù)驅(qū)動(dòng)。數(shù)據(jù)驅(qū)動(dòng)的前提先得有數(shù)據(jù)。阿里的數(shù)據(jù)庫(kù)規(guī)模下數(shù)據(jù)采集處理還是很有挑戰(zhàn)的，因?yàn)橐?guī)模太大了。今天我們所有數(shù)據(jù)都是秒級(jí)采集，分析和展現(xiàn)。過(guò)去幾年我們花了很多精力建設(shè)了一個(gè)可靠的數(shù)據(jù)通道，對(duì)采集上來(lái)的數(shù)據(jù)進(jìn)行實(shí)時(shí)分析和離線分析。因?yàn)槲覀儓?jiān)信未來(lái)CloudDBA產(chǎn)品一定向數(shù)據(jù)化、智能化的方向走，雖然數(shù)據(jù)通道和計(jì)算花了很多的精力，但是產(chǎn)生的數(shù)據(jù)價(jià)值很高。
數(shù)據(jù)驅(qū)動(dòng)這塊今天重點(diǎn)說(shuō)一下全量SQL分析。如果要對(duì)數(shù)據(jù)庫(kù)性能進(jìn)行診斷，單純看慢SQL是不夠的。有些業(yè)務(wù)對(duì)latency很敏感，盡管SQL沒(méi)有達(dá)到慢SQL標(biāo)準(zhǔn)，比如MySQL里默認(rèn)的1秒，但業(yè)務(wù)已經(jīng)感覺到明顯的異常，因此需要對(duì)數(shù)據(jù)庫(kù)實(shí)例上的全部SQL進(jìn)行分析，了解當(dāng)前實(shí)例正在執(zhí)行哪些SQL，性能如何。CloudDBA對(duì)全網(wǎng)數(shù)據(jù)庫(kù)實(shí)例上全部SQL進(jìn)行實(shí)時(shí)采集、分析和展現(xiàn)，并且基于這些數(shù)據(jù)來(lái)驅(qū)動(dòng)整個(gè)診斷優(yōu)化流程。
先看一下全量SQL分析的數(shù)據(jù)通道。我們的AliSQL內(nèi)核實(shí)現(xiàn)了非常輕量級(jí)SQL流水采集，包括SQL來(lái)源，SQL文本，執(zhí)行時(shí)間，鎖等待時(shí)間，掃描行數(shù)/返回行數(shù)、邏輯/物理讀等信息。這些信息會(huì)實(shí)時(shí)地上報(bào)到Kafka, 然后利用JStorm對(duì)全量SQL進(jìn)行各種維度的實(shí)時(shí)計(jì)算和分析。另外，對(duì)實(shí)時(shí)計(jì)算完的數(shù)據(jù)我們還會(huì)進(jìn)行很多離線分析。目前全量SQL流水采集在阿里基本上全網(wǎng)覆蓋，實(shí)時(shí)計(jì)算數(shù)據(jù)量達(dá)到千萬(wàn)級(jí)SQL/秒，離線計(jì)算數(shù)據(jù)量達(dá)到百TB/天。
這里列出了一些我們基于全量SQL分析進(jìn)一步做的一些事情。首先用戶通過(guò)CloudDBA可以實(shí)時(shí)查看當(dāng)前實(shí)例正在執(zhí)行的全部SQL信息以及性能趨勢(shì)，這些信息能夠更全面了解業(yè)務(wù)SQL的健康情況，比如對(duì)執(zhí)行耗時(shí)占比較高但執(zhí)行效率較低，執(zhí)行頻繁但索引缺失，執(zhí)行性能有明顯波動(dòng)以及新增SQL等進(jìn)行了識(shí)別。對(duì)于有分庫(kù)分表的業(yè)務(wù)，我們能夠識(shí)別是否有讀寫熱點(diǎn)。對(duì)線上的優(yōu)化操作可以更好地進(jìn)行性能優(yōu)化度量。還有從安全的角度，可以進(jìn)行全面的SQL審計(jì)，還有我們也進(jìn)行一些實(shí)際業(yè)務(wù)模型的分析。
再簡(jiǎn)單說(shuō)一下基于數(shù)據(jù)驅(qū)動(dòng)在全局優(yōu)化方面做的一些事情。
前面講業(yè)務(wù)訴求提到了需要有全局規(guī)模優(yōu)化的能力，全局優(yōu)化方面我們也構(gòu)造了一個(gè)閉環(huán)。基于海量數(shù)據(jù)分析，從“發(fā)現(xiàn)規(guī)模優(yōu)化點(diǎn)”，“估算預(yù)期收益”，到提供全局“優(yōu)化決策輸入”，開始“規(guī)模優(yōu)化”，然后進(jìn)行“實(shí)際收益量化跟蹤”，以及最后的“規(guī)模優(yōu)化效果評(píng)定”，整個(gè)流程在CloudDBA內(nèi)部形成閉環(huán)。比如我們的全網(wǎng)空間優(yōu)化，基于上就是通過(guò)這個(gè)閉環(huán)流程完成，同時(shí)CloudDBA會(huì)給出空間規(guī)模優(yōu)化的實(shí)際收益。
全局優(yōu)化方面，我們期望能夠真正做到數(shù)據(jù)驅(qū)動(dòng)，包括建立全網(wǎng)性能成本模型，建立性能成本基線等，能夠基于數(shù)據(jù)分析發(fā)現(xiàn)收益較大的規(guī)模優(yōu)化點(diǎn)。這方面我們還在持續(xù)地做更多的事情。
三、數(shù)據(jù)庫(kù)智能優(yōu)化探索
最后分享一些我們?cè)谥悄軆?yōu)化方向的一些探索。利用數(shù)據(jù)分析和機(jī)器學(xué)習(xí)的一些技術(shù)，我們嘗試去解決數(shù)據(jù)庫(kù)領(lǐng)域之前較難解決的一些問(wèn)題。這塊有很大的想像空間，目前我們主要是在以下幾個(gè)方面進(jìn)行探索：
1、異常檢測(cè)/關(guān)聯(lián)分析。上午我聽了一個(gè)分享講在其他領(lǐng)域的異常發(fā)現(xiàn)/關(guān)聯(lián)分析，異常檢測(cè)不僅是數(shù)據(jù)庫(kù)領(lǐng)域，在其他運(yùn)維領(lǐng)域也有需求，是一個(gè)共性的問(wèn)題。運(yùn)維同學(xué)做監(jiān)控，異常現(xiàn)在怎么發(fā)現(xiàn)？通常的做法是依賴報(bào)警，但報(bào)警的閾值怎么定？定高了到時(shí)候故障發(fā)生了報(bào)警還沒(méi)出來(lái)，定低了收到一堆報(bào)警，都是誤報(bào)。能不能做到智能的異常發(fā)現(xiàn)？比如說(shuō)某個(gè)數(shù)據(jù)庫(kù)實(shí)例跟之前的歷史行為有比較大的不同，但并沒(méi)有觸發(fā)報(bào)警，我如何能第一時(shí)間知道？因?yàn)榘l(fā)現(xiàn)的越晚，線上的損失就會(huì)越大，在阿里的場(chǎng)景這個(gè)是有直接的業(yè)務(wù)訴求。及時(shí)發(fā)現(xiàn)異常，快速定位原因，減少業(yè)務(wù)影響。
昨天清華的裴老師也講了，異常發(fā)現(xiàn)對(duì)于分鐘級(jí)的數(shù)據(jù), 目前一些現(xiàn)有算法是適用的，稍微做一些加工就會(huì)有比較明顯的效果。但是我們的數(shù)據(jù)都是秒級(jí)的，對(duì)我們來(lái)說(shuō)分鐘級(jí)太長(zhǎng)了。一個(gè)問(wèn)題如果在分鐘級(jí)別發(fā)現(xiàn)，損失可能已經(jīng)非常大了。基于秒級(jí)數(shù)據(jù)的異常發(fā)現(xiàn)，今天業(yè)界的大部分算法效果都非常差，因?yàn)槊爰?jí)數(shù)據(jù)抖動(dòng)非常頻繁，怎么在這種抖動(dòng)中區(qū)分出來(lái)是真正的異常還是正常的抖動(dòng)，這個(gè)挑戰(zhàn)比較大。這里我也列舉了一些其他方面的挑戰(zhàn)，目前對(duì)于這些問(wèn)題我們有一些初步的突破，有時(shí)間再分享這塊的細(xì)節(jié)。
2、主動(dòng)預(yù)警。異常發(fā)現(xiàn)都是事后的，因?yàn)楫惓Ｒ呀?jīng)發(fā)生了，損失也已經(jīng)造成了，快速的異常發(fā)現(xiàn)是盡量減少損失。但我們希望做到更進(jìn)一步，從被動(dòng)診斷發(fā)展為主動(dòng)診斷。在數(shù)據(jù)庫(kù)故障真正發(fā)生之前，根據(jù)歷史行為特征來(lái)對(duì)即將發(fā)生的異常進(jìn)行提前預(yù)警。因?yàn)楹芏鄶?shù)據(jù)庫(kù)故障發(fā)生前已經(jīng)有一些特征是異常的了。這個(gè)之前基于傳統(tǒng)閾值報(bào)警的方式是沒(méi)有辦法發(fā)現(xiàn)的。如果可以提前做預(yù)警，就有機(jī)會(huì)能更早的介入，避免故障的發(fā)生。
3、容量預(yù)估。我們每年都有雙11，雙11之前都要對(duì)數(shù)據(jù)庫(kù)系統(tǒng)做容量預(yù)估。如果拍腦袋加1萬(wàn)臺(tái)機(jī)器，但可能根本用不了這么多，那就造成大量的浪費(fèi)。怎么能夠更靠譜的做出容量預(yù)估，給出更合理的預(yù)算是很重要的。另外一方面，數(shù)據(jù)庫(kù)實(shí)例什么時(shí)候要進(jìn)行擴(kuò)容，之前比較難預(yù)測(cè)的事情。我們最近在這方面做了一些嘗試，舉一個(gè)數(shù)據(jù)庫(kù)空間增長(zhǎng)預(yù)測(cè)的例子。
我們基于空間增長(zhǎng)歷史數(shù)據(jù)分析來(lái)對(duì)線上實(shí)例空間增長(zhǎng)趨勢(shì)進(jìn)行預(yù)測(cè)，預(yù)測(cè)的結(jié)果作為實(shí)例自動(dòng)擴(kuò)容的輸入。數(shù)據(jù)庫(kù)實(shí)例什么時(shí)候需要擴(kuò)容，CloudDBA會(huì)把這個(gè)信息透明出去,CloudDBA也可以基于這個(gè)預(yù)測(cè)對(duì)實(shí)例進(jìn)行自動(dòng)擴(kuò)容。根據(jù)我們目前的預(yù)測(cè)結(jié)果，對(duì)線上>90%的實(shí)例空間增長(zhǎng)預(yù)測(cè)誤差都可以做到<5%, 我們還在不斷地優(yōu)化算法把這個(gè)數(shù)字做到更好。
4、自診斷，自優(yōu)化。這是未來(lái)CloudDBA智能化階段要具備的能力。整個(gè)系統(tǒng)可以基于大量的基礎(chǔ)數(shù)據(jù)，通過(guò)標(biāo)注把人的經(jīng)驗(yàn)注入然后利用一些模型或者算法進(jìn)行訓(xùn)練，分析出目前的性能問(wèn)題，自動(dòng)從優(yōu)化操作集選擇最合適的優(yōu)化方案，在全局代價(jià)評(píng)估后自動(dòng)應(yīng)用到線上。整個(gè)過(guò)程是自動(dòng)的，而且可以根據(jù)線上優(yōu)化結(jié)果反饋反復(fù)進(jìn)行優(yōu)化。這塊的探索我們還剛剛開始。
最后簡(jiǎn)單總結(jié)一下今天分享的內(nèi)容。首先分享了在阿里我們?yōu)槭裁匆鯟loudDBA，背后的業(yè)務(wù)訴求和用戶訴求是什么。其次分享了CloudDBA的一些關(guān)鍵技術(shù)，時(shí)間原因?qū)QL優(yōu)化、空間優(yōu)化以及全量SQL分析進(jìn)行了展開。最后跟大家簡(jiǎn)單分享了一些我們?cè)谥悄軆?yōu)化方向的一些思考和實(shí)際探索。智能化方向是CloudDBA的未來(lái)，這塊我們還在不斷地嘗試，也期望有興趣的同學(xué)能夠加入我們一起去探索。
原文地址
總結(jié)
以上是生活随笔為你收集整理的阿里在数据库智能优化路上_做了哪些探索与实践？的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 木马的检测、清除与防范
- 下一篇： mencoder_有用的Mplayer