一、防微杜漸：異常SQL防御體系建設(shè)

1.SQL治理階段

如上圖所示，SQL治理的基本階段主要包括開(kāi)發(fā)（事前）、測(cè)試（事中）、生產(chǎn)運(yùn)維（事后）三階段。

在開(kāi)發(fā)階段，研發(fā)通常不受相應(yīng)開(kāi)發(fā)規(guī)范和SQL審核約束。從開(kāi)發(fā)到測(cè)試或生產(chǎn)發(fā)布時(shí)，才會(huì)進(jìn)行DDL和DML的審核。目前業(yè)內(nèi)SQL治理，主要還是在SQL出問(wèn)題之后進(jìn)行相應(yīng)的治理。

所以我們思考：能否在測(cè)試階段提前發(fā)現(xiàn)有問(wèn)題的SQL，提前預(yù)判性能并治理？如何在事中進(jìn)行SQL的兜底和止損？

之所以要把治理能力前置到測(cè)試階段，是因?yàn)樵皆绨l(fā)現(xiàn)有問(wèn)題的SQL，對(duì)整體治理或改造的成本就越低，對(duì)生產(chǎn)的影響也越小。

2.事前發(fā)現(xiàn)

1）SQLReview

SQLReview是在開(kāi)發(fā)環(huán)境向測(cè)試環(huán)境或生產(chǎn)環(huán)境發(fā)布時(shí)，對(duì)語(yǔ)句進(jìn)行基本審核。此部分的整體能力建設(shè)與當(dāng)前業(yè)界主流的開(kāi)源沒(méi)有太大差別，只是我們的集成規(guī)范會(huì)更個(gè)性化或更豐富。

第一，根據(jù)DBA在日常中的反饋，完善相應(yīng)規(guī)則并集成經(jīng)驗(yàn)，如攔截特殊語(yǔ)法；

第二，集成三方規(guī)范。比如大數(shù)據(jù)包含某些特殊要求，要求每一張表必須有時(shí)間字段等特定字段、特定類(lèi)型和特定索引，以供大數(shù)據(jù)抽取數(shù)據(jù)；

第三，廣播變更消息，比如提供安全審計(jì)，變更大數(shù)據(jù)訂閱結(jié)構(gòu)變更；

第四，日志分析，分析熱點(diǎn)表。DBA在日常運(yùn)維時(shí)，需要一定數(shù)據(jù)統(tǒng)計(jì)來(lái)總結(jié)經(jīng)驗(yàn)，梳理重點(diǎn)關(guān)注的業(yè)務(wù)，了解攔截最多的規(guī)則和問(wèn)題最多的部門(mén)。

2）新增SQL檢測(cè)

新增SQL檢測(cè)是指在SQL執(zhí)行到生產(chǎn)環(huán)節(jié)之前，將它攔截。實(shí)現(xiàn)流程中最重要的一點(diǎn)是，通過(guò)數(shù)據(jù)庫(kù)代理中間件記錄全量測(cè)試及生產(chǎn)的全量SQL、然后統(tǒng)一進(jìn)行消費(fèi)處理，識(shí)別出生產(chǎn)環(huán)境新增的SQL。

例如通過(guò)指紋計(jì)算，對(duì)比測(cè)試環(huán)境下SQL的指紋是否出現(xiàn)在生產(chǎn)最后的指紋庫(kù)里。若不存在的話(huà)，就把它認(rèn)定為一個(gè)新增的SQL，再放到生產(chǎn)環(huán)境中進(jìn)行特征判斷，比如它的掃描行數(shù)是否太多，是否存在全表掃描，索引特征是否出現(xiàn)index merge、file sort等，也包含執(zhí)行時(shí)長(zhǎng)，特殊禁止語(yǔ)法等全方位的特征判斷。

但這種實(shí)現(xiàn)存在兩個(gè)問(wèn)題：

一是據(jù)統(tǒng)計(jì)，生產(chǎn)環(huán)境峰值QPS每秒上百萬(wàn)。由于生產(chǎn)的真實(shí)流量比較大，改進(jìn)后，我們不再轉(zhuǎn)發(fā)全量SQL，而是根據(jù)SQL指紋進(jìn)行采樣避免流量太大，但即便如此，每天處理的SQL量仍接近5TB。

二是指紋計(jì)算。上述SQL通過(guò)DBA直觀(guān)去看，指紋計(jì)算應(yīng)該是一致的。但由于早期我們采用開(kāi)源的基于正則的SQL指紋計(jì)算庫(kù)存在的不足，無(wú)法識(shí)別SQL在細(xì)微上的差異，導(dǎo)致指紋計(jì)算準(zhǔn)確度差影結(jié)果判斷。

改進(jìn)后的指紋算法則采用語(yǔ)法解析樹(shù)的方式，將SQL的關(guān)鍵對(duì)象抽取出來(lái)做特征處理，比如取出查詢(xún)字段后做排序后再計(jì)算指紋，對(duì)where條件同樣做排序處理，防止sharding表由于表名字不同，造成的計(jì)算差異同樣進(jìn)行特殊處理。

3）統(tǒng)計(jì)分析

我們統(tǒng)計(jì)了最近一個(gè)月的攔截量。在TP場(chǎng)景下，SQL問(wèn)題大部分是索引問(wèn)題，由上圖可知，“索引不合理”和“缺少索引”的情況占比之和達(dá)到80%。因此能否通過(guò)技術(shù)手段進(jìn)行自動(dòng)合理索引創(chuàng)建就是解決問(wèn)題的重點(diǎn)。

4）研發(fā)視角新增SQL質(zhì)量報(bào)告

通過(guò)上圖視角，研發(fā)可以了解每個(gè)DBA或每個(gè)部門(mén)，在具體時(shí)間范圍內(nèi)新增哪些 SQL，發(fā)到生產(chǎn)的新增SQL是否高危SQL，并清晰地記錄下來(lái)。

質(zhì)量報(bào)告還包含其他重要信息，比如 SQL被認(rèn)定為高風(fēng)險(xiǎn)的原因。如上圖所示，質(zhì)量報(bào)告提示可能存在全表掃描的情況，然后記錄其首次出現(xiàn)的時(shí)長(zhǎng)和時(shí)間，使用開(kāi)源索引工具給出基本建議。

但初期的建設(shè)還不太完善，開(kāi)源工具僅基于單條SQL提出建議，缺少評(píng)估意見(jiàn)合理性的全局視角，我們后續(xù)會(huì)整體改寫(xiě)這部分。

5）不帶隱患上生產(chǎn)

實(shí)現(xiàn)攔截功能需要與整個(gè)研發(fā)流程結(jié)合。

在CICD環(huán)節(jié)的準(zhǔn)出階段進(jìn)行卡口集成，若出現(xiàn)高風(fēng)險(xiǎn)的慢查詢(xún)或SQL沒(méi)有處理的情況，會(huì)提示“不可上線(xiàn)”，避免隱患SQL上生產(chǎn)。

3.事中兜底

無(wú)論防御做得多好，隨著數(shù)據(jù)庫(kù)容量、QPS的增長(zhǎng)，一些SQL會(huì)不可避免地逐步惡化為慢SQL，因此要具備兜底能力。

第一，通過(guò)中間件進(jìn)行主動(dòng)或被動(dòng)的SQL限流或熔斷，比如DBA會(huì)主動(dòng)介入對(duì)某個(gè)SQL限流或者熔斷；

第二，自研數(shù)據(jù)庫(kù)管控平臺(tái)。平臺(tái)集成數(shù)據(jù)庫(kù)自愈系統(tǒng)，通過(guò)查殺模塊，實(shí)時(shí)檢測(cè)每一個(gè)數(shù)據(jù)庫(kù)實(shí)例的健康狀況，并根據(jù)特征進(jìn)行相應(yīng)的SQL查殺等。

我們整體構(gòu)建在混合云上，包含阿里云、華為云，AWS，Azure。每一家云對(duì)于數(shù)據(jù)庫(kù)的保護(hù)機(jī)制存在很大差別且是不可以跨云移植適用的，所以要打造自己統(tǒng)一的、通用的保護(hù)能力。

4.事后治理

事后治理主要是慢查詢(xún)治理。由于混合云上要兼容產(chǎn)品比較多通過(guò)云商接口，拉文件的原始分析方式實(shí)現(xiàn)比較麻煩，具備全量SQL的能力后實(shí)現(xiàn)就較為簡(jiǎn)潔，后續(xù)接入多家云或兼容MySQL協(xié)議的產(chǎn)品時(shí)，能更好實(shí)現(xiàn)慢查詢(xún)分析、分析及安全審計(jì)等能力。

使用單一云較為簡(jiǎn)單，而在混合云上時(shí)，為了某一能力的統(tǒng)一化或標(biāo)準(zhǔn)化，就不得不把管控系統(tǒng)設(shè)計(jì)得很復(fù)雜。

5.后續(xù)計(jì)劃

前文提到，我們統(tǒng)計(jì)80%的SQL問(wèn)題是索引問(wèn)題。如上圖統(tǒng)計(jì)，生產(chǎn)環(huán)境中單列索引占比77%，復(fù)合索引只占了13%，同時(shí)復(fù)合查詢(xún)條件占比91%。由此可以看出，用23%的復(fù)合索引服務(wù)91%的復(fù)合查詢(xún)顯然是不夠的，意味著可能是存在很多SQL執(zhí)行計(jì)劃不佳的情況。

過(guò)去的開(kāi)源建設(shè)是針對(duì)單個(gè)索引、單個(gè)SQL的最佳推薦，但具備了全量SQL采集分析能力后，可以做全局性最佳索引的推薦。在數(shù)據(jù)統(tǒng)計(jì)維度，可以基于代價(jià)進(jìn)行評(píng)估給出整張表綜合索引的建議，進(jìn)而自動(dòng)創(chuàng)建和維護(hù)索引。

二、深度觀(guān)測(cè)：全量SQL分析與挖掘

1.為什么要做全量SQL分析？

1）應(yīng)用場(chǎng)景：?jiǎn)栴}分析定位

全量SQL的應(yīng)用場(chǎng)景比較多。如上圖所示，例如數(shù)據(jù)庫(kù)CPU很高或抖了一下是哪些SQL導(dǎo)致的，這些SQL的具體執(zhí)行情況，包括時(shí)間響應(yīng)、返回行數(shù)、掃描行數(shù)等。

2）SQL挖掘：深度治理

基于全量SQL分析表、索引是否已廢棄，不同db的熱點(diǎn)表、熱點(diǎn)SQL，單條SQL RT是否穩(wěn)定，甚至可以分析表的活躍數(shù)據(jù)情況等治理場(chǎng)景。

3）兼容混合云產(chǎn)品、統(tǒng)一問(wèn)題排查

由于混合云產(chǎn)品的差異性與企業(yè)統(tǒng)一管理的矛盾，給問(wèn)題分析或日常應(yīng)用帶來(lái)很大困擾，因此產(chǎn)品設(shè)計(jì)時(shí)要格外考慮多云兼容性。

有時(shí)候，單一云確實(shí)提升了某一能力，但混合云下，服務(wù)整體功能的設(shè)計(jì)更加復(fù)雜。

2.全量SQL分析實(shí)現(xiàn)

全量SQL分析實(shí)現(xiàn)的基本流程：SQL請(qǐng)求DAL之后，DAL將SQL轉(zhuǎn)發(fā)到Kafka里面，然后再根據(jù)業(yè)務(wù)場(chǎng)景需要進(jìn)行消費(fèi)處理。

比如分析某一個(gè)字段是否有在用，只需要通過(guò)指紋去重，抓取這一段時(shí)間內(nèi)所有這個(gè)表的SQL請(qǐng)求，并進(jìn)行參數(shù)解析，就能輕易分析出所需要的字段。

還比如熱點(diǎn)表、熱點(diǎn)SQL、SQL波動(dòng)，經(jīng)過(guò)先前處理后，可直接通過(guò)原數(shù)據(jù)查詢(xún)。

通過(guò)對(duì)一段時(shí)間內(nèi)的SQL查詢(xún)返回?cái)?shù)據(jù)記錄，分析出活躍數(shù)據(jù)量占比，來(lái)指導(dǎo)研發(fā)合理的規(guī)定設(shè)置。

上圖是做采樣的一個(gè)樣例，它的維度很豐富，我們可以基于SQL的采樣，進(jìn)行大量統(tǒng)計(jì)分析的工作。

通過(guò)top SQL可以分析某個(gè)時(shí)間段內(nèi)SQL執(zhí)行占比情況，進(jìn)而推測(cè)數(shù)據(jù)庫(kù)性能開(kāi)銷(xiāo)情況，對(duì)深入問(wèn)題分析有比較大的幫助作用。

上圖是第二個(gè)應(yīng)用場(chǎng)景，通過(guò)波動(dòng)SQL，查詢(xún)不穩(wěn)定集群。預(yù)處理每條SQL時(shí)，我們記錄了SQL RT 的p50跟p95時(shí)長(zhǎng)，把每一個(gè)集群下每一條SQL的p95跟p50去做差，然后聚合、排序。波動(dòng)越大，聚合的差值越大，就大致能推測(cè)這個(gè)集群是不穩(wěn)定的。

從上圖左下方的圖表可知，它的CPU經(jīng)常具有毛刺。但日常中DBA很難根據(jù)經(jīng)驗(yàn)照顧到每一個(gè)集群，所以需要拉取這些數(shù)據(jù)進(jìn)行分析或日常治理。

再如DBA發(fā)現(xiàn)某個(gè)DB TOP 1的SQL執(zhí)行的次數(shù)幾乎是TOP 2的10倍，分析這個(gè)SQL發(fā)現(xiàn)它是一個(gè)司機(jī)登錄場(chǎng)景。由于活躍的司機(jī)體量是有限的，司機(jī)登錄動(dòng)作達(dá)到每秒幾萬(wàn)，這顯然是不合理的。

與研發(fā)溝通后，我們找到了原因：這是典型的業(yè)務(wù)設(shè)計(jì)問(wèn)題，也是一個(gè)基礎(chǔ)編碼問(wèn)題。

三、容量預(yù)測(cè)：數(shù)據(jù)庫(kù)仿真流量測(cè)壓

1.數(shù)據(jù)庫(kù)容量評(píng)估

基于云上技術(shù)的紅利，從存儲(chǔ)計(jì)算一體化的架構(gòu)演進(jìn)為存儲(chǔ)計(jì)算分離的架構(gòu)，具備了快速容量彈性的能力。未來(lái)目標(biāo)是做到ServerLess化，但目前仍需要一些時(shí)間和數(shù)據(jù)進(jìn)行驗(yàn)證。

雖然實(shí)現(xiàn)了存算分離實(shí)現(xiàn)快速擴(kuò)縮容，但是容量評(píng)估仍舊是根據(jù)DBA經(jīng)驗(yàn)來(lái)判斷的，缺乏一些相應(yīng)的數(shù)據(jù)支撐。

2.數(shù)據(jù)庫(kù)容量壓測(cè)

1）BenchMark

由于BenchMark壓測(cè)與真實(shí)環(huán)境的SQL表現(xiàn)差距巨大，因此不能用于容量評(píng)估。

近年來(lái)流行的SQLReplay等流量回放工具，核心就是利用抓包的方式將SQL記錄下來(lái)然后機(jī)械能回放。它主要的問(wèn)題是：一方面抓包容易缺漏，另一方面是SQL維度信息缺失難以支持還原真實(shí)場(chǎng)景。

2）全鏈路壓測(cè)

現(xiàn)在比較流行的方式是全鏈路壓測(cè)。它存在的問(wèn)題是，在真實(shí)的業(yè)務(wù)場(chǎng)景下，APP ID之間的調(diào)用關(guān)系極其復(fù)雜。理論上使用全鏈路壓測(cè)的方式可以進(jìn)行壓測(cè)評(píng)估，但實(shí)際應(yīng)用中數(shù)據(jù)上下游調(diào)用可能會(huì)造失真的問(wèn)題，會(huì)存在壓不到、壓得過(guò)多或過(guò)少的情況。

同時(shí)，也存在數(shù)據(jù)熱點(diǎn)問(wèn)題。全鏈路壓測(cè)有時(shí)會(huì)模擬一定的用戶(hù)、司機(jī)數(shù)據(jù)，通常這個(gè)量不會(huì)特別大，幾百條、上千條就已經(jīng)算是比較多的。由于數(shù)據(jù)庫(kù)有cache，很多查詢(xún)不回表，所以無(wú)法反映真實(shí)的數(shù)據(jù)庫(kù)的實(shí)際負(fù)載情況。

3）仿真流量壓測(cè)

在具備了全量SQL后，我們提出了仿真流量壓測(cè)。它的大概流程是：高峰期內(nèi)，SQL將流量錄制下來(lái)保存至Kafka低峰期內(nèi)，進(jìn)行相應(yīng)的消息處理后進(jìn)行仿真回放。

主要問(wèn)題：

壓測(cè)冪：比如壓測(cè)1000次理論上這1000次在任意時(shí)間點(diǎn)執(zhí)行SQL的內(nèi)容、數(shù)量以及并發(fā)度都要求保持一致，這是非常困難的；

流量縮放：如果是1:1的回放，理論上是可以還原的。但研發(fā)可能對(duì)放量百分比產(chǎn)生疑問(wèn)，比如流量增加120%，數(shù)據(jù)庫(kù)能否撐得?。窟@種時(shí)候只能通過(guò)經(jīng)驗(yàn)預(yù)估容量。成倍放大是容易的，但成比例放大就很麻煩。

主要缺點(diǎn)：

• 使用真實(shí)生產(chǎn)環(huán)境進(jìn)行回訪(fǎng)，不能執(zhí)行DML導(dǎo)致失真；
• 不能保證100%的仿真度，只能無(wú)限接近。

3.數(shù)據(jù)庫(kù)容量評(píng)估應(yīng)用

實(shí)際進(jìn)行壓縮時(shí)，我們劃出一條以CPU為主的基準(zhǔn)線(xiàn)，安全的上限值是45%。超過(guò)45%之后，無(wú)論數(shù)據(jù)庫(kù)是否能承受都需要進(jìn)行擴(kuò)容。基于這個(gè)基線(xiàn)進(jìn)行壓測(cè)，CPU壓到45%時(shí)當(dāng)前QPS即是容量的上限水位，這就有利于研發(fā)和DBA后續(xù)直觀(guān)地看到容量情況。

目前這一塊內(nèi)容并未完全落地，整體處于開(kāi)發(fā)階段，我們?cè)诶碚撋线€原了SQL執(zhí)行順序與并發(fā)情況。整體并發(fā)模型還需要做深入的打磨跟優(yōu)化。

4.為什么要圍繞SQL死磕？

根據(jù)真實(shí)生產(chǎn)的統(tǒng)計(jì)，我們將近70%的數(shù)據(jù)庫(kù)實(shí)際規(guī)格都低于8C。

使用這種小規(guī)格的服務(wù)器，數(shù)據(jù)庫(kù)的彈性能力是非常差的，SQL稍有問(wèn)題都可能擊穿數(shù)據(jù)庫(kù)。由于使用的是混合云，無(wú)法將數(shù)據(jù)庫(kù)穩(wěn)定性保障交給云商統(tǒng)一解決，因此我們只能在現(xiàn)有能力下，構(gòu)建兼容多云的統(tǒng)一管理能力。

數(shù)據(jù)庫(kù)最大的兩個(gè)挑戰(zhàn)：高并發(fā)+大容量。雖然目前貨拉拉還沒(méi)有面臨大容量與高并發(fā)的場(chǎng)景，但已初顯端倪，不到3年，我們數(shù)據(jù)庫(kù)QPS流量增長(zhǎng)了近10倍。

在可預(yù)見(jiàn)的未來(lái)，如果我們的訂單再增加1倍，流量可能會(huì)增加10倍，現(xiàn)存的SQL問(wèn)題到時(shí)將會(huì)更加突出，這也是DBA圍繞SQL進(jìn)行能力建設(shè)的原因之一。

5.后續(xù)規(guī)劃

目前平臺(tái)初步具備了DAS功能的雛形，距離比較完善的產(chǎn)品形態(tài)還要繼續(xù)進(jìn)行打磨。