為什么我們需要一個 SQL 數(shù)據(jù)庫審核平臺

2018年6月4日，鏈家 40歲程序員刪庫，公司斥資 18萬恢復(fù)系統(tǒng)；

2020年2月24日，微盟程序員刪庫跑路，次日股價下跌 21.5億人民幣；

這些安全事故，暴露出大部分公司的隱患，缺少一個完善的數(shù)據(jù)庫審核平臺。數(shù)據(jù)庫所有的操作，都應(yīng)該有其審核規(guī)則，來確保不會造成災(zāi)難性的事情發(fā)生。

比如刪庫，一旦審核平臺接到 Drop Database 的命令，就立馬出發(fā)郵件到主管，申請批復(fù)，并暫時性停止執(zhí)行，直到收到回復(fù)批準(zhǔn)。

本文探索數(shù)據(jù)庫審核平臺的功能和實現(xiàn)。參考書目還是《數(shù)據(jù)庫高效優(yōu)化：架構(gòu)、規(guī)范與SQL優(yōu)化》

再舉個例子，來說明下審核平臺提供的功能。

比如，有 CRM 用戶反映，平時 1,2秒就能打開的客戶利潤報表，現(xiàn)在需要 20 秒了。經(jīng)過前端組的排查，確定是數(shù)據(jù)庫的 SQL 返回結(jié)果慢了，請求 DBA 調(diào)優(yōu)。

DBA 于是在審核平臺，建了這么條規(guī)則：抓取運行時間超過 20 秒的所有 SQL 和存儲過程，包括詳細(xì)的 SQL 文本，索引使用和執(zhí)行計劃。

等待一段時間，平臺就會把這些超長的 SQL 抓取出來，DBA 篩選下，就能定位到問題。

數(shù)據(jù)庫審核平臺的功能，到此就很清晰了，提出問題，設(shè)定規(guī)則，抓取問題SQL.

有同學(xué)會疑惑，這不就是問題排查嘛，造一個平臺來解決，是不是大材小用？用短小精悍的腳本，不香嘛？

當(dāng)然不是！我用 3 個節(jié)拍說服你

SQL開發(fā)的苦惱

SQL 開發(fā)小哥哥和小姐姐，平時被業(yè)務(wù)開發(fā)掏空。考勤，OA，HR，生產(chǎn)制造系統(tǒng)，ERP，進(jìn)銷存，倉儲等 MIS 系統(tǒng)，通常三四條線，同時開工，占據(jù)絕大部分時間與精力。

忙起來，上午寫的SQL，下午都能忘記邏輯。好不容易閑下來，除了開黑，看劇，社交，解解乏，根本沒有時間再投入系統(tǒng)學(xué)數(shù)據(jù)庫。

長期以往，遇到某張大表，SQL性能直線下降時，他們將束手無策。當(dāng)靠經(jīng)驗，加索引，改寫SQL均無效時，他們只能求助于DBA。

DBA的無奈

業(yè)務(wù)越豐富，頭疼的當(dāng)然不止開發(fā)，還有DBA. 成熟的企業(yè)，往往使用四，五種不同架構(gòu)的數(shù)據(jù)庫，十多套不同廠商的商業(yè)數(shù)據(jù)庫。比如Oracle, SQL Server, DB2,MongoDB, ElasticSearch 等等。

安裝，調(diào)試，建庫建表建索引，建高可用集群，這些瑣事，已經(jīng)讓 DBA 應(yīng)接不暇。據(jù)我所知，傳統(tǒng)行業(yè)還不配備專職 DBA，他們往往兼顧一些報表開發(fā)，ETL設(shè)計和建模。

于是，他們的命運，也就剩下疲于奔命，現(xiàn)場救火。此時與開發(fā)并無不同，沒有緊急的工單，有問題的SQL調(diào)優(yōu)，就被安排到了猴年馬月。

上帝欲讓人瘋狂，先使人瘋忙。

數(shù)據(jù)增值小分隊

近十年，云計算不斷介入后端。越來越多的機(jī)械性管理工作，被云統(tǒng)一籌劃和部署。使得更多的精力與時間可以投入數(shù)據(jù)資產(chǎn)的管理，比如數(shù)據(jù)治理，數(shù)據(jù)質(zhì)量和數(shù)據(jù)安全。

云之前，DBA 團(tuán)隊面臨的情況：出了系統(tǒng)性能故障， DBA 的鍋；出了數(shù)據(jù)庫連接超時，DBA的鍋；甚至數(shù)據(jù)質(zhì)量問題，都是DBA的鍋。但是一旦業(yè)務(wù)猛增的時候呢，嗯，各種領(lǐng)獎，嘉獎，都是前端業(yè)務(wù)系統(tǒng)的。

當(dāng) DBA 團(tuán)隊不能成為資產(chǎn)時，就會淪為成本。成本，是要被剔除的。因此，數(shù)據(jù)增值分隊?wèi)?yīng)運而生！

讓上帝的歸上帝，凱撒的歸凱撒

SQL 開發(fā)會漸漸與前端框架融合，探索和保障業(yè)務(wù)系統(tǒng)順利展開。DBA 分隊，提供信息架構(gòu)的基礎(chǔ)建設(shè)，保障存儲的安全，計算的穩(wěn)定。在企業(yè)上云或數(shù)據(jù)庫自治后，讓大量基礎(chǔ) DBA 人員轉(zhuǎn)型到數(shù)據(jù)增值團(tuán)隊來，負(fù)責(zé)數(shù)據(jù)治理，數(shù)據(jù)分析和數(shù)據(jù)安全等領(lǐng)域。

以上三點，就是我們需要數(shù)據(jù)庫審核平臺的理由了， 它幫數(shù)據(jù)團(tuán)隊，把服務(wù)做到量化，可視化、規(guī)?；屠麧櫥?/p>

數(shù)據(jù)庫審核平臺實踐

那么，我們怎么做一個數(shù)據(jù)庫審核平臺呢？

購買軟件，還是自研？購買的軟件能幫我們解決所有的問題嗎，這些數(shù)據(jù)帶來的問題，有通用的模式，可以用統(tǒng)一模型來解決嗎？

回答這個問題前，讓我們先取個經(jīng)，看下別人的成果。

• 一梯隊，BAT等互聯(lián)網(wǎng)一線大廠。它們的方案，完全自研SQL引擎。實現(xiàn) SQL 執(zhí)行成本分析，自動審核，訪問分流等。

• 與大廠提前自動審核不同，大多數(shù)沒有自研SQL引擎能力的中廠，選擇半自動方式，做到事后審核。方法是收集數(shù)據(jù)庫各項指標(biāo)數(shù)據(jù)，引入人工判斷，做好審核。

• 針對完全沒有研發(fā)能力的小廠，那么只能依靠購買商用的軟件產(chǎn)品，再輔以人工處理。缺點就太明顯，價格高，而且擴(kuò)展性不高。

普通的團(tuán)隊怎么辦呢，保二爭一。自研適合大部分團(tuán)隊。

用 2 張圖來表達(dá)，第一張是架構(gòu)圖，第二張是操作流程圖：

平時開發(fā)中，經(jīng)常遇到這些異常：

• 上一秒運行正常的SQL，這一秒拋出了日志文件空間不足，執(zhí)行失敗
• 平常運行秒出的SQL，今天偶然特別慢，就像人睡覺睡的好好的，突然抽了一兩下，原因未知
• 平靜的出奇的某天下午，突然有同事大叫一聲，誰XX把我的報表進(jìn)程給殺了
• 一天中的某段時間，數(shù)據(jù)庫就像僵住了一樣，無論運行什么都很慢
• 系統(tǒng)中總有幾張表，涉及到他們的查詢，就非常慢
• 每天都要手工清理一些表、索引或視圖等數(shù)據(jù)庫對象，沒有時間和精力投入數(shù)據(jù)建模，數(shù)據(jù)治理

這些常見問題，歸納為兩類：

• 數(shù)據(jù)庫對象
• SQL 審核

也就是圖中的 SQL 管理和 DB Object 管理。數(shù)據(jù)庫審核平臺主要做這兩類。

回顧開頭的原理圖，數(shù)據(jù)團(tuán)隊要做的事情，無非就是：

• 定義問題
• 規(guī)則設(shè)計
• 編碼實現(xiàn)

如果大家有興趣，可以參考宜信團(tuán)隊開源的 CreditEaseDBA Themis 數(shù)據(jù)庫審核平臺，在此基礎(chǔ)上，加入自研的功能。他們的產(chǎn)品地址是：

https://github.com/CreditEaseDBA/Themis

再次申明，本文靈感來自《數(shù)據(jù)庫高效優(yōu)化：架構(gòu)、規(guī)范與SQL優(yōu)化》，摘錄部分觀點和示意圖*。