3-1 沈裕鋒-美團數據庫自治服務平臺建設.pdf

1、美團數據庫自治服務平臺建設演講人：沈裕鋒2個人介紹沈裕鋒 數據庫自治服務平臺負責人曾就職于IBM、微軟數據庫平臺組，有多年的關系型數據庫跟大數據平臺研發經驗。2019年加入美團，目前深耕于數據庫自治服務領域，負責公司數據庫研發中心數據庫自治服務平臺的相關工作。3平臺簡介演進策略異常發現與診斷SQL性能優化與治理自動化故障處理未來展望4平臺簡介運維效率1.分析定位難度高，以人為主，工具為輔2.工具之間聯動少，單點之間來回切換3.處理過程不透明，協同溝通成本高業務穩定性1.故障處理周期長，小問題容易變成大故障2.故障出現頻次高，新業務故障持續不斷發生業務規模增長與運維能力發展之間的不平衡問題凸顯數

2、據庫自治服務平臺是一種基于大數據技術、專家經驗以及AI算法來實現數據庫的異常發現、故障分析與處理以及SQL性能優化與治理的自治數據庫服務平臺，目標是實現數據庫領域的自動駕駛。5平臺簡介演進策略異常發現與診斷SQL優化建議與治理自動化預案處理未來展望6整個平臺的演進路線分為數據庫“可觀測性建設”、“異常發現”、“智能診斷”以及“SQL優化與故障預案處理”幾個大的階段進行。演進策略各層功能介紹 接口與展示：展示平臺的功能以及對外提供平臺的服務。業務邏輯層：使用采集到的數據來提供異常診斷、SQL性能優化與治理等業務功能。計算存儲層：通過實時計算跟大數據平臺對采集的數據進行計算跟存儲。數據采集層：采集

3、異常診斷跟性能優化的關鍵數據，為業務層服務。7平臺簡介演進策略異常發現與診斷SQL性能優化與治理自動化預案處理未來規劃8異常類型與處理生命周期異常發現、診斷、處理的全生命周期關鍵指標異常診斷面臨挑戰造成異常的原因眾多全方位的信息獲取困難排查經驗難以傳承數據庫系統發生異常時，需要快速發現異常、根因定位以及快速解決問題，防止異常造成的影響被進一步放大。異常類型 活躍會話突增 主從延遲增加 慢查詢數量突增 9異常發現策略異常發現策略分為傳統的靜態閥值、基于數理統計的動態閥值的策略，動態閥值是根據不同的指標歷史變化規律，構建不同的模型進行異常檢測，根據歷史的時序數據分布來預測未來的指標走勢。異常發現算

4、法基于模型的實時異常指標發現10復盤分析總結提煉規則生成 學習專家經驗：咨詢DBA同學，學習行業專家的經驗；內核源碼分析：深入研究MySQL內核代碼，了解SQL執行的明細步驟，從最底層的邏輯來判斷異常發生的根源；AI算法診斷：學習業界知名公司異常診斷方面論文，做一些技術上的創新。異常診斷策略例子：活躍會話異常診斷分析規則樹11有些case的診斷很有挑戰性（尤其內核層面的Mutex鎖造成SQL阻塞，比如binlog清理、BP空閑內存不足、DICT_SYS鎖或者硬件故障問題等），因為缺少那部分的關鍵數據，我們從源碼角度出發整理了整個SQL的明細執行步驟，跟公司MySQL內核團隊合作，輸出了100多

5、個在內核中執行的關鍵步驟的耗時情況，為疑難雜癥的Case打下堅實的基礎。內核可觀測性-基于內核源碼分析12根據分析結果，公司內MySQL內核團隊對整個SQL的執行流水中涉及的關鍵執行步驟的耗時打點，把性能相關的打點數據輸出至本地文件后通過平臺的agent組建傳至后端進行SQL的性能分析與根因診斷。內核可觀測性-內核建設MySQL內核數據打點、上報的總體架構部分內核指標列表 BPWaitFreeTime SchemaWaitTime BinlogRotateTime RecLockTime PageReadTime LockTime CommTime PageWriteTime TableWai

6、tTime TableHoldTime SchemaHoldTime 自治服務平臺13根據專家經驗跟內核可觀測性功能總結出的診斷規則，同時結合AI算法進行異常指標的根因診斷分析?；谝巹t的根因診斷處理流程基于規則診斷給出根因（基于頁面的產品展示）基于AI診斷給出根因（基于IM的產品展示）基于AI算法的根因診斷處理流程診斷系統架構設計與產品展示14平臺簡介演進策略異常發現與診斷SQL性能優化與治理自動化預案處理未來規劃15SQL性能優化&治理-背景性能問題相關的風險SQL對應用程序系統的穩定性造成很大的挑戰，我們的目標是及時的發現、分析跟處理掉風險SQL，防患于未然。服務耗時組成SQL請求耗時分

7、布SQL執行可觀測性SQL優化建議系統SQL治理系統發現問題給出方案治理風險 針對給出的方案，有風險SQL通過手工或自動化的方式進行治理。網絡耗時業務邏輯耗時GC耗時訪問數據庫耗時其他組件耗時SQL逐漸變慢SQL突然變慢SQL恒定很慢SQL忽快忽慢SQL性能問題可能的原因 對于有性能問題的SQL給出如何添加索引的優化方案。通過慢查詢SQL跟全量SQL系統，發現有性能問題的SQL。16SQL性能優化&治理-治理階段治理階段拆解SQL發布生產環境前SQL生產環境執行過程中SQL生產環境執行過后防患于未然，把問題SQL扼殺于在搖籃里實時發現正在執行的問題SQL，快速止損基于整體維度進行SQL治理事前

8、（審核）事中（實時發現）事后（治理）對SQL執行的整個生命周期進行監控，分為事前、事中、事后三階段來進行風險SQL的發現、分析以及治理。17風險SQL發現-全量SQL與慢查詢系統通過采集并且上報全量SQL以及慢查詢日志信息（日志包含SQL文本、鎖等待、執行耗時等信息），發送至平臺后端用來進行SQL相關的性能排查、優化建議以及數據安全審計等場景。序號挑戰項設計原則1QPS特別高（達到數千萬/秒）高并發、高吞吐、可擴展2數量存儲容量特別大（PB級別/天）低成本3業務需求變化頻繁靈活性4采集程序頻繁更新，對MySQL實例影響大低風險5后端處理邏輯復雜可擴展系統挑戰全量SQL系統架構慢查詢系統架構18

9、索引優化建議-系統設計通過SQL可觀測性能力發現有性能問題的SQL后，如何給出最佳的索引建議來提升SQL性能是一個具有挑戰性的問題，因為加或者不加索引根據經驗比較難判斷眼，完全是由數據分布來決定。索引優化建議總體架構SQL：select c1,c2 from t1where c3=123 and c410group by c5候選索引：c1、c2、c3、c4、c5的排列組合索引選擇過程：c1、c2、c3、c4、c5-c3c1、c2、c4、c5-c3、c1c2、c4、c5-c3、c1、c5c2、c4-c3、c1、c5、c4c2-c3、c1、c5、c4、c2基于貪心算法的索引選擇19索引優化建議-

10、基于workload優化建議我們知道索引并不是越多越好，最好的方案盡可能使用最少的索引數量，同時能取得整個數據庫系統的最大的性能提升，這方面我們參照業界的論文進行了基于workload的索引優化建議。核心思路1.通過上節基于貪心算法來選擇針對單個query最佳的索引（從單列開始）2.進行索引的合并，主要是去除掉一些索引之間列有交集的索引3.通過貪心算法Greedy(m,k)來選擇k個需要的索引（因為存儲空間有限）；4.在m個最優索引（排列組合）的基礎上使用貪心算法Greedy(m,k)選擇總共k個需要的索引的基礎上，通過MC_LEAD（添加的列都是可索引列）算法來添加多列索引；5.重復步驟1、

11、2、3跟4。20索引優化建議-生態建設通過索引優化建議服務給出優化建議后，需要在真正添加索引前后，進行事前的性能評估以及事后的性能跟蹤，讓用戶事前放心的添加索引，事后量化的感知優化的真實效果。優化建議生態系統索引添加前，讓用戶放心的添加平臺給的索引優化建議索引添加后，讓用戶量化的感知添加索引帶來的性能提升21索引優化建議-產品效果展示索引推薦&一鍵審批添加索引添加索引優化前后，SQL執行時間效果對比22SQL審核（事前）程序發布之前，在公司的CI/CD平臺集成流水線，增設SQL審核卡控，盡量防止風險SQL被帶到生產環境引發故障，起防患于未然的作用。程序發布時SQL審核進行卡點（數據來源于全量S

12、QL）產品展示審核結果，風險提示跟建議23實時風險SQL發現（事中）耗時突增耗時波動耗時漸增耗時平穩耗時漸降耗時突減風險SQL耗時分布圖非風險SQL耗時分布圖間歇性慢查詢SQL發現系統架構全表掃描、新增慢查詢風險SQL發現系統架構程序發布之前，在公司的CI/CD平臺集成流水線，增設SQL審核卡控，杜絕風險SQL被帶到生產環境引發故障，起防患于未然的作用。24SQL治理（事后）通過全量SQL&慢查詢SQL日志獲取SQL治理對象?；趦灮ㄗh服務給出索引優化建議，通過風險治理系統進行風險治理。通過批量分析已執行過的慢查詢SQL跟全量SQL日志，給可優化的SQL提供索引優化建議，來推送給用戶進行風險

13、SQL的治理（這里的分析包括基于workload的索引優化建議等）。SQL治理總體架構25平臺簡介演進策略異常發現與診斷SQL性能優化與治理自動化預案處理未來展望26診斷平臺與預案處理平臺結合數據庫自治服務系統給出故障的根因或者SQL索引優化建議后，我們通過一鍵化或者自動化的方式調用預案處理系統處理異?；蚬收?，讓系統快速、安全、可靠的從故障中恢復。數據庫自治服務：提供精確的故障根因，根據診斷結果來快速、安全、可靠的執行某些操作恢復故障是一個挑戰，借助兄弟團隊預案處理系統解決問題。預案處理系統：為自治服務等平臺接入提供便利，助力提升上述系統的一鍵化、自動化水平，降低治人工介入成本。27產品展示下

14、面為系統診斷出根因后，調用預案處理系統的預案接口來對SQL進行限量、Kill阻塞者SQL或者添加索引的方式讓系統快速從異常中恢復。28平臺簡介演進策略異常發現與診斷SQL性能優化與治理自動化預案處理未來展望29未來展望-LLM在數據庫場景的應用隨著ChatGPT的持續火熱，也帶來了我們對LLM在數據庫場景應用的探索，經過我們初步的測試，發現無論是OpenAI的GPT序列模型還是業界開源的LLM比如Bert、T5模型都在Q&A、Query Rewrite、Index Adviser及Text2SQL等數據庫場景都有不錯的表現。30未來展望-LLM在數據庫場景的應用使用開源LLM模型Bert跟T5

15、在SQL索引建議（也適用SQL Rewrite）跟Q&A方面的微調跟推理進行初步的探索T5基于MLM（掩碼語言模型）模式的預訓練SQL格式化后通過調優后的T5模型推理給出索引Bert微調過程中學習Start跟End兩個Vector根據學來的S跟E的Vector進行推理，提取答案31當前平臺已經具備了數據庫故障自助能力跟一定的自治能力，但是自治化、智能化程度需要進一步提升，沒有完全形成閉環，數據庫自治服務的下一個目標實現完全的自感知、自分析、自優化與修復的數據庫自動駕駛服務平臺，同時隨著ChatGPT的興起，我們也在探索LLM（大語言模型）在智能運維方面的場景落地。通過手工輸入命令，進行故障排查、性能優化通過開源工具進行故障排查、性能優化海量數據的采集、分析、給出故障根因、優化建議自動彈性伸縮、自動索引維護、自動參數優化、自動空間優化、LLM（大語言模型）在智能運維方向探索。手工工具化平臺化自治化&智能化平臺演進階段未來展望-平臺演進已實現進行中32THANK YOU!