SQL稽核工具自薦Owls
關鍵詞： sql審批、sql檢測、sql執行、備份
概要
這裡主要是向大家推薦一款sql檢測、審批工具Owls，用於自動檢測、審批sql的執行，還有其他的審批、備份、查詢等功能。以提高sql的規範化，增強服務穩定性。自動稽核的規則沉澱自資深DBA。
另外，非常歡迎感興趣的夥伴加入社群共同開發維護：社群群組 。
開發計劃也會優先考慮使用者需求，歡迎在issue中提出需求。
線上範例
線上預覽: http://owls.nooncall.cn:8778/owls
測試使用者名稱：admin 密碼：aaaaaa
倉庫地址
Github(外網)：https://github.com/nooncall/owls
Gitee(國記憶體取)： https://gitee.com/nooncall/owls
離線sql可能會導致的問題
首先，什麼是離線sql呢？就是說手動觸發執行的這種sql；相對的還有線上sql，位於我們的程式程式碼中，由程式觸發執行的sql是線上sql。舉個例子，我們想要建庫、建表、改表的時候，通常會編寫sql語句，選一個合適的時間執行；這就是離線SQL。當然，運算元據的離線sql也是有的，比方說線上程式bug，我們想要手動修復個別資料，這時候也會提交離線的修改資料的SQL。
那麼，離線的sql可能會導致哪些問題呢？這個說起來還挺多的，我們來列舉一下。建表或者改表的時候，可能會存在不規範的列，比如我們可能會不希望欄位存在空值；可能會不小心使用不同的字元集；可能會不小心建立了重複的索引，給變更資料帶來不必要的負擔。而運算元據的時候，如果資料量特別大，一個不走索引的查詢或者變更語句就可能給db帶來災難；或者偶爾由於手速過快，提交了不帶條件限制的變更語句；另外，手動操作難免偶爾出錯，出錯了再去糾正資料也會十分麻煩。
如何避免問題
如何避免這些問題呢？最簡單的方式是我們每次執行sql都提交給dba，由dba同學手動檢查後執行。如果公司規模很小，這樣的話還能湊合（如果公司有dba同學的話），但人工稽核也難免有注意不到的地方；而公司規模比較大的話，就比較費dba同學了【手動狗頭】。
那我們可以在這個基礎上再加一層：由研發leader稽核完後，再由dba同學稽核並執行。這樣可以減輕dba同學的工作量，但是還是沒有辦法避免人工檢查的遺漏。而且也沒有辦法方便的進行資料備份。
那麼有沒有更好的方式呢？當然是有的，把檢查sql的標準梳理清楚形成一條一條的規則，然後固化到程式裡，由程式來應用規則完成首輪檢查，並在執行的時候，進行資料備份，需要時還可以進行資料回滾。
現成可使用的工具-Owls
Owl就是這樣一個開源工具，它提供sql提交流程審批、按規則檢測sql、執行sql、備份、回滾等功能，可以用以管理起來所有的離線sql執行場景。它讓我們的db資料更規範、db叢集更安全。下圖是它的一個流程結構示意圖。
首先它提供一個審批流程的地方，研發同學想要對自己存取不到（網路隔離）的線上環境執行sql時，可以在Owl上提交sql執行的請求工單，分別經過規則稽核、leader稽核、dba稽核後，由dba在Owl上直接執行。
規則審批即是通過一些規則限制可執行的sql。這些規則的實現還是挺有意思的，感興趣的同學可以去程式碼中看，文末會有地址。規則舉例：1，表必須使用utf8字元集；2，列和表都必須要有註釋；3，變更資料影響行數不能超過100；4，變更資料的sql必須完全匹配索引。上面這些都是具體的規則，規則可以開啟或者關閉，開啟狀態的規則會拒絕不滿足此條規則的sql。下圖是具體支援的部分規則截圖，目前已實現37條規則。
下面是資料查詢頁面的截圖：
當然，為了可以使用上述的一些功能還需要一些基礎的功能模組，比如使用者、管理員管理，叢集管理、登陸認證等。由於一些規則需要獲取具體的表資料資訊來實現驗證，所以需要db的賬號和密碼。密碼是加密儲存在資料庫的，必須要有組態檔中的key和程式中固定的key才能解密，所以安全性是有保障的。
最後還需要說明的是：大批次的資料更新不適合通過owl去做，除非我們不需要做資料備份。因為owl的資料備份方式是特殊編碼後轉儲到一張db表裡，資料量過大會給記憶體帶來很大的壓力，也不適合放到表裡了。
未來規劃
- 庫表狀態資訊展示
- Mysql改表時，分庫分表工具（gh-ost）的支援
- MQ輔助功能
- ......
開發計劃會優先考慮使用者需求，歡迎在issue中提出需求。
求個star
最後，求一個star呀，每一個star都是對開源專案開發者的巨大鼓勵！
專案地址
Github(外網): https://github.com/nooncall/owls
Gitee(國記憶體取): https://gitee.com/nooncall/owls