作者介紹
蔡朋，貨拉拉DBA負責人。
分享概要
一、防微杜漸：異常SQL防禦體系建設
二、深度觀測：全量SQL分析與挖掘
三、容量預測：資料庫仿真流量壓測
一、防微杜漸：異常SQL防禦體系建設
1.SQL治理階段
如上圖所示，SQL治理的基本階段主要包括開發（事前）、測試（事中）、生産運維（事後）三階段。
在開發階段，研發通常不受相應開發規範和SQL稽核限制。從開發到測試或生産釋出時，才會進行DDL和DML的稽核。目前業内SQL治理，主要還是在SQL出問題之後進行相應的治理。
是以我們思考：能否在測試階段提前發現有問題的SQL，提前預判性能并治理？如何在事中進行SQL的兜底和止損？
之是以要把治理能力前置到測試階段，是因為越早發現有問題的SQL，對整體治理或改造的成本就越低，對生産的影響也越小。
2.事前發現
1）SQLReview
SQLReview是在開發環境向測試環境或生産環境釋出時，對語句進行基本稽核。此部分的整體能力建設與目前業界主流的開源沒有太大差别，隻是我們的內建規範會更個性化或更豐富。
第一，根據DBA在日常中的回報，完善相應規則并內建經驗，如攔截特殊文法；
第二，內建三方規範。比如大資料包含某些特殊要求，要求每一張表必須有時間字段等特定字段、特定類型和特定索引，以供大資料抽取資料；
第三，廣播變更消息，比如提供安全審計，變更大資料訂閱結構變更；
第四，日志分析，分析熱點表。DBA在日常運維時，需要一定資料統計來總結經驗，梳理重點關注的業務，了解攔截最多的規則和問題最多的部門。
2）新增SQL檢測
新增SQL檢測是指在SQL執行到生産環節之前，将它攔截。實作流程中最重要的一點是，通過資料庫代理中間件記錄全量測試及生産的全量SQL、然後統一進行消費處理，識别出生産環境新增的SQL。
例如通過指紋計算，對比測試環境下SQL的指紋是否出現在生産最後的指紋庫裡。若不存在的話，就把它認定為一個新增的SQL，再放到生産環境中進行特征判斷，比如它的掃描行數是否太多，是否存在全表掃描，索引特征是否出現index merge、file sort等，也包含執行時長，特殊禁止文法等全方位的特征判斷。
但這種實作存在兩個問題：
一是據統計，生産環境峰值QPS每秒上百萬。由于生産的真實流量比較大，改進後，我們不再轉發全量SQL，而是根據SQL指紋進行采樣避免流量太大，但即便如此，每天處理的SQL量仍接近5TB。
二是指紋計算。上述SQL通過DBA直覺去看，指紋計算應該是一緻的。但由于早期我們采用開源的基于正則的SQL指紋計算庫存在的不足，無法識别SQL在細微上的差異，導緻指紋計算準确度差影結果判斷。
改進後的指紋算法則采用文法解析樹的方式，将SQL的關鍵對象抽取出來做特征處理，比如取出查詢字段後做排序後再計算指紋，對where條件同樣做排序處理，防止sharding表由于表名字不同，造成的計算差異同樣進行特殊處理。
3）統計分析
我們統計了最近一個月的攔截量。在TP場景下，SQL問題大部分是索引問題，由上圖可知，“索引不合理”和“缺少索引”的情況占比之和達到80%。是以能否通過技術手段進行自動合理索引建立就是解決問題的重點。
4）研發視角新增SQL品質報告
通過上圖視角，研發可以了解每個DBA或每個部門，在具體時間範圍内新增哪些 SQL，發到生産的新增SQL是否高危SQL，并清晰地記錄下來。
品質報告還包含其他重要資訊，比如 SQL被認定為高風險的原因。如上圖所示，品質報告提示可能存在全表掃描的情況，然後記錄其首次出現的時長和時間，使用開源索引工具給出基本建議。
但初期的建設還不太完善，開源工具僅基于單條SQL提出建議，缺少評估意見合理性的全局視角，我們後續會整體改寫這部分。
5）不帶隐患上生産
實作攔截功能需要與整個研發流程結合。
在CICD環節的準出階段進行卡口內建，若出現高風險的慢查詢或SQL沒有處理的情況，會提示“不可上線”，避免隐患SQL上生産。
3.事中兜底
無論防禦做得多好，随着資料庫容量、QPS的增長，一些SQL會不可避免地逐漸惡化為慢SQL，是以要具備兜底能力。
第一，通過中間件進行主動或被動的SQL限流或熔斷，比如DBA會主動介入對某個SQL限流或者熔斷；
第二，自研資料庫管控平台。平台內建資料庫自愈系統，通過清除子產品，實時檢測每一個資料庫執行個體的健康狀況，并根據特征進行相應的SQL清除等。
我們整體建構在混合雲上，包含阿裡雲、華為雲，AWS，Azure。每一家雲對于資料庫的保護機制存在很大差别且是不可以跨雲移植适用的，是以要打造自己統一的、通用的保護能力。
4.事後治理
事後治理主要是慢查詢治理。由于混合雲上要相容産品比較多通過雲商接口，拉檔案的原始分析方式實作比較麻煩，具備全量SQL的能力後實作就較為簡潔，後續接入多家雲或相容MySQL協定的産品時，能更好實作慢查詢分析、分析及安全審計等能力。
使用單一雲較為簡單，而在混合雲上時，為了某一能力的統一化或标準化，就不得不把管控系統設計得很複雜。
5.後續計劃
前文提到，我們統計80%的SQL問題是索引問題。如上圖統計，生産環境中單列索引占比77%，複合索引隻占了13%，同時複合查詢條件占比91%。由此可以看出，用23%的複合索引服務91%的複合查詢顯然是不夠的，意味着可能是存在很多SQL執行計劃不佳的情況。
過去的開源建設是針對單個索引、單個SQL的最佳推薦，但具備了全量SQL采集分析能力後，可以做全局性最佳索引的推薦。在資料統計次元，可以基于代價進行評估給出整張表綜合索引的建議，進而自動建立和維護索引。
二、深度觀測：全量SQL分析與挖掘
1.為什麼要做全量SQL分析？
1）應用場景：問題分析定位
全量SQL的應用場景比較多。如上圖所示，例如資料庫CPU很高或抖了一下是哪些SQL導緻的，這些SQL的具體執行情況，包括時間響應、傳回行數、掃描行數等。
2）SQL挖掘：深度治理
基于全量SQL分析表、索引是否已廢棄，不同db的熱點表、熱點SQL，單條SQL RT是否穩定，甚至可以分析表的活躍資料情況等治理場景。
3）相容混合雲産品、統一問題排查
由于混合雲産品的差異性與企業統一管理的沖突，給問題分析或日常應用帶來很大困擾，是以産品設計時要格外考慮多雲相容性。
有時候，單一雲确實提升了某一能力，但混合雲下，服務整體功能的設計更加複雜。
2.全量SQL分析實作
全量SQL分析實作的基本流程：SQL請求DAL之後，DAL将SQL轉發到Kafka裡面，然後再根據業務場景需要進行消費處理。
比如分析某一個字段是否有在用，隻需要通過指紋去重，抓取這一段時間内所有這個表的SQL請求，并進行參數解析，就能輕易分析出所需要的字段。
還比如熱點表、熱點SQL、SQL波動，經過先前處理後，可直接通過原資料查詢。
通過對一段時間内的SQL查詢傳回資料記錄，分析出活躍資料量占比，來指導研發合理的規定設定。
上圖是做采樣的一個樣例，它的次元很豐富，我們可以基于SQL的采樣，進行大量統計分析的工作。
通過top SQL可以分析某個時間段内SQL執行占比情況，進而推測資料庫性能開銷情況，對深入問題分析有比較大的幫助作用。
上圖是第二個應用場景，通過波動SQL，查詢不穩定叢集。預處理每條SQL時，我們記錄了SQL RT 的p50跟p95時長，把每一個叢集下每一條SQL的p95跟p50去做差，然後聚合、排序。波動越大，聚合的內插補點越大，就大緻能推測這個叢集是不穩定的。
從上圖左下方的圖表可知，它的CPU經常具有毛刺。但日常中DBA很難根據經驗照顧到每一個叢集，是以需要拉取這些資料進行分析或日常治理。
再如DBA發現某個DB TOP 1的SQL執行的次數幾乎是TOP 2的10倍，分析這個SQL發現它是一個司機登入場景。由于活躍的司機體量是有限的，司機登入動作達到每秒幾萬，這顯然是不合理的。
與研發溝通後，我們找到了原因：這是典型的業務設計問題，也是一個基礎編碼問題。
三、容量預測：資料庫仿真流量測壓
1.資料庫容量評估
基于雲上技術的紅利，從存儲計算一體化的架構演進為存儲計算分離的架構，具備了快速容量彈性的能力。未來目标是做到ServerLess化，但目前仍需要一些時間和資料進行驗證。
雖然實作了存算分離實作快速擴縮容，但是容量評估仍舊是根據DBA經驗來判斷的，缺乏一些相應的資料支撐。
2.資料庫容量壓測
1）BenchMark
由于BenchMark壓測與真實環境的SQL表現差距巨大，是以不能用于容量評估。
近年來流行的SQLReplay等流量回放工具，核心就是利用抓包的方式将SQL記錄下來然後機械能回放。它主要的問題是：一方面抓包容易缺漏，另一方面是SQL次元資訊缺失難以支援還原真實場景。
2）全鍊路壓測
現在比較流行的方式是全鍊路壓測。它存在的問題是，在真實的業務場景下，APP ID之間的調用關系極其複雜。理論上使用全鍊路壓測的方式可以進行壓測評估，但實際應用中資料上下遊調用可能會造失真的問題，會存在壓不到、壓得過多或過少的情況。
同時，也存在資料熱點問題。全鍊路壓測有時會模拟一定的使用者、司機資料，通常這個量不會特别大，幾百條、上千條就已經算是比較多的。由于資料庫有cache，很多查詢不回表，是以無法反映真實的資料庫的實際負載情況。
3）仿真流量壓測
在具備了全量SQL後，我們提出了仿真流量壓測。它的大概流程是：高峰期内，SQL将流量錄制下來儲存至Kafka低峰期内，進行相應的消息處理後進行仿真回放。
主要問題：
- 壓測幂：比如壓測1000次理論上這1000次在任意時間點執行SQL的内容、數量以及并發度都要求保持一緻，這是非常困難的；
- 流量縮放：如果是1:1的回放，理論上是可以還原的。但研發可能對放量百分比産生疑問，比如流量增加120%，資料庫能否撐得住？這種時候隻能通過經驗預估容量。成倍放大是容易的，但成比例放大就很麻煩。
主要缺點：
- 使用真實生産環境進行回訪，不能執行DML導緻失真；
- 不能保證100%的仿真度，隻能無限接近。
3.資料庫容量評估應用
實際進行壓縮時，我們劃出一條以CPU為主的基準線，安全的上限值是45%。超過45%之後，無論資料庫是否能承受都需要進行擴容。基于這個基線進行壓測，CPU壓到45%時目前QPS即是容量的上限水位，這就有利于研發和DBA後續直覺地看到容量情況。
目前這一塊内容并未完全落地，整體處于開發階段，我們在理論上還原了SQL執行順序與并發情況。整體并發模型還需要做深入的打磨跟優化。
4.為什麼要圍繞SQL死磕？
根據真實生産的統計，我們将近70%的資料庫實際規格都低于8C。
使用這種小規格的伺服器，資料庫的彈性能力是非常差的，SQL稍有問題都可能擊穿資料庫。由于使用的是混合雲，無法将資料庫穩定性保障交給雲商統一解決，是以我們隻能在現有能力下，建構相容多雲的統一管理能力。
資料庫最大的兩個挑戰：高并發+大容量。雖然目前貨拉拉還沒有面臨大容量與高并發的場景，但已初顯端倪，不到3年，我們資料庫QPS流量增長了近10倍。
在可預見的未來，如果我們的訂單再增加1倍，流量可能會增加10倍，現存的SQL問題到時将會更加突出，這也是DBA圍繞SQL進行能力建設的原因之一。
5.後續規劃
目前平台初步具備了DAS功能的雛形，距離比較完善的産品形态還要繼續進行打磨。