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