為什么我們需要一個 SQL 數據庫審核平臺

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

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

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

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

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

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

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

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

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

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

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

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

SQL開發(fā)的苦惱

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

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

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

DBA的無奈

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

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

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

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

數據增值小分隊

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

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

當 DBA 團隊不能成為資產時，就會淪為成本。成本，是要被剔除的。因此，數據增值分隊應運而生！

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

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

以上三點，就是我們需要數據庫審核平臺的理由了， 它幫數據團隊，把服務做到量化，可視化、規(guī)模化和利潤化。

數據庫審核平臺實踐

那么，我們怎么做一個數據庫審核平臺呢？

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

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

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

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

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

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

用 2 張圖來表達，第一張是架構圖，第二張是操作流程圖：

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

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

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

• 數據庫對象
• SQL 審核

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

回顧開頭的原理圖，數據團隊要做的事情，無非就是：

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

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

https://github.com/CreditEaseDBA/Themis

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