3月25日，中國民生銀行信息科技部數據庫專家孔再華在dbaplus社群帶來了《民生銀行數據庫智能運維實踐》主題的線上直播，之後在線回答了觀眾提問，現在我們精選出16個問題和解答與大家分享。
文末還有本期PPT的獲取路徑，不要錯過~
Q&A
Q1：採集的歷史數據需要放到啥類型的數據庫中？
A：因為我只需要使用三個月左右的數據，所以現在數據還是放在傳統的關係型數據庫裡面，便於查詢和處理。其實我更偏向於使用時序數據庫存儲指標數據。
Q2：一場檢測算法，怎麼處理營銷寶典活動的數據呢？
A： 對於促銷類的活動，異常檢測算法可定會將那段時間的很多指標數據標記成異常。我認為這個行為是應該的，因為確實發生了很大的業務行為變化。這個變化值得運維人員去關注。但是最重要的是要搞清楚這部分新的數據在下次檢測的時候要不要。所以是不是要給這個時間窗口打個標記，下次訓練排除這部分異常數據。
Q3：像Zabbix、Promethues這類的監控平臺能否有效的監控數據庫的健康狀態？
A：Zabbix和普羅米修斯這些監控平臺都是很好的工具。在我行也已經大規模使用。但是這些工具對於數據庫的監控其實還是更多依託人為定義採集的數據，因此健康狀態這個問題還是DBA來定義的。
Q4：請問有做一場預測模型嗎？
預測模型現在還沒有做，計劃後面針對核心的指標做一些oom這種類型的異常預測。基於歷史變化趨勢判斷未來是否會出現異常。另外一個計劃做的事情是磁盤的健康預測。
Q5：請問異常和具體的SQL是怎麼關聯起來的？
A：異常指標是數據庫級別的。SQL自己也有指標。需要做的事情就是基於歷史數據，在數據庫指標和sql指標之間找到他們的相關性，最後基於相關性來定位sql指標已經sql貢獻度。
Q6：您這邊沒有用到時間序列預測，請問用的是什麼模型呢？
A：暫時沒有使用時間預測。主要原因是我這邊觀察大部分數據的時序特徵不是很明顯。數據庫的指標不僅僅受到業務週期的影響，內部各種機制的觸發也會影響指標數據。而且時序模型報出來的異常數量會更多。我只從產品健康的角度觸發，而且不關心業務的週期，所以最終放棄了時序模型。
Q7：SQL是如何蒐集的，是全部採集還是出現問題再採集呢？
Sql也是週期性採集的，間隔5分鐘。因為SQL的數據也需要做差值和平均。
Q8：數據採集頻率是多長時間呢？
A：1分鐘到5分鐘不等。這個主要看需求。我個人覺得5分鐘就可以。通常一個異常的發現不會被5分鐘就平滑掉的。
Q9：請問db2用快照分析，那Oracle和MySQL用什麼分析呢？
A：我雖然稱為快照數據，但是和db2的snapshot不一樣。因為db2的snapshot工具已經棄用了。Db2我用的mon_get_database，Mysql我用的show global status 加上performance schema裡面的event wait相關視圖。
Q10：每個SQL的執行，都有相關執行時間、等待時間之類的嗎？
A：這個是有的。DB2的sql信息裡有cpu時間，執行時間，等待時間，各種子的等待時間等，非常詳細。因此時間分佈餅圖就非常好做。結合時間分佈和異常的指標信息，分析sql問題就很簡單啦。
Q11：數據庫診斷日誌監控和分析嗎？
A：這個還沒有做，是在計劃裡的。主要思路是用爬蟲去定期獲取官方的問題數據，然後基於自然語言處理裡面的一些基礎算法，將問題變成向量，診斷日誌也變成向量，最終通過相似度來判斷是否命中已知問題。
Q12：數據庫方面，還有那些場景可以智能運維來實現呢？
A：異常預測，健康度檢測，數據庫畫像，資源動態調配，異常自愈等。其實未來能做的很多。
Q13：如果實現了，dba是不是就沒飯吃了？
A：這個問題我特別想回答。我認為未來的DBA是要向兩個方向發展的。一種是深度。藉助智能運維挖掘的信息價值，DBA能夠更瞭解一個數據庫，更能夠洞察數據庫的運行狀態。因此DBA的技術其實是會往深度拓展，這是一片新的天空。還有一種是高度。藉助智能運維，DBA可以更清楚管理的所有數據庫的運行狀態，更能夠把握不同數據庫產品的特點，不同業務在使用數據庫時候的特點。DBA以更貼近業務的管理方式為業務服務，挑選合適的數據庫，合適的軟硬件。也就是DBA的服務更往前推了。總的來說，未來DBA的影響力更大，更不可或缺。
Q14：關於學習智能運維的算法，有什麼推薦的書籍嗎？你是怎麼入門的？
A：我自己是先看吳恩達的視頻開始的。因為他講的特別透徹，我也比較喜歡從原理還是往結果走。不過他的內容更多的是和深度學習相關。而深度學習在其他領域效果很好，但是在運維領域，因為其不可解釋性，反而用的不多。後來是看看機器學習的那些基礎算法。Sklean有張機器學習的算法挑選圖。建議按照那個圖把相關算法都看看。
Q15：機器學習基本算法對開發要求高嗎？
A：要求不高，這個算法都有現成的模型。所以只要清楚原理，會用就好。
Q16：目前我們也有收集採集主機信息並加工分析的想法，數據是在源端格式化後採集嗎？需要源端加工嗎？入庫後，需要怎麼規劃管理這些數據呢？
A：建議源端採集之後就格式化成json數據往後走。數據加工不建議源端做。數據都得管理好生命週期：採集，處理，存儲，清理。建議每一步都用做適合的工具。我這邊因為數據因為是個旁路分析系統，原始數據在其他系統還有，因此我也不需要保存歷史。基本上保存3到6個月數據就行。所以我直接清理了。否則的話還需要歸檔。
獲取本期PPT，請添加微信：dbafefiei
從過去40年至今，數據庫的形態基本經歷了傳統商業數據庫、開源數據庫到雲原生數據庫的演進過程。雲時代下數據庫將如何革新與創變？金融行業核心數據庫遷移與建設如何安全平穩展開？來
Gdevops全球敏捷運維峰會北京站尋找答案：- 《All in Cloud 時代，下一代雲原生數據庫技術與趨勢》阿里巴巴集團副總裁/達摩院首席數據庫科學家 李飛飛（飛刀）
- 《AI和雲原生時代的數據庫進化之路》騰訊數據庫產品中心總經理 林曉斌（丁奇）
- 《ICBC的MySQL探索之路》工商銀行軟件開發中心 魏亞東
- 《金融行業MySQL高可用實踐》愛可生技術總監 明溪源
- 《民生銀行在SQL審核方面的探索和實踐》民生銀行 資深數據庫專家 李寧寧
- 《OceanBase分佈式數據庫在西安銀行的落地和實踐》螞蟻金服P9資深專家/OceanBase核心負責人 蔣志勇
讓我們9月11日在北京共同眺望數據庫發展變革更長遠的未來！
閱讀更多 dbaplus社群 的文章
