本文由 「AI前線」原創，原文連結：阿里資料庫進入全網秒級實時監控時代
作者｜吳必良（未立）
編輯｜Emily
AI 前線導讀：“2017 雙 11 再次創下了 32.5 萬筆 / 秒交易建立的紀錄，在這個數字後面，更是每秒多達幾千萬次的資料庫寫入，如何大規模進行自動化操作、保證資料庫的穩定性、快速發現問題是一個巨大的難題， 這也是資料庫管控平臺要完成的任務。”
隨著阿里巴巴資料庫規模的不斷擴大，我們建設資料庫管控平臺也經歷了很多階段，從指令碼化、工具化、平臺化到目前的 DBPaaS，DBPaaS 在今年雙 11 中， 首次全面覆蓋集團、各子公司下的本地資料庫、公有云、混合雲等多種場景。今年雙 11，資料庫已經全面實現容器化部署，彈性使用離線資源、公有云資源支援大促。全面優化的監控採集鏈路，實現了全網所有資料庫例項的秒級採集、監控、展現、診斷。每秒實時處理超過 1000 萬項監控指標，讓異常無所遁形。DBPaaS 也持續在資料庫管理的自動化、規模化、數字化、智慧化等方向進行突破。
在這其中，關於資料庫監控系統建設比較典型。
在業務平時執行態，線上系統出現故障，在數萬資料庫中，如何發現異常、快速診斷亦是一件非常具有挑戰的事情。在雙十一全鏈路壓測中，系統吞吐量未達預期或業務出現了 RT 抖動，快速診斷定位資料庫問題是一個現實課題。此外，對於複雜資料庫故障事後排查故障根源、現場還原、歷史事件追蹤也迫使我們建設一個覆蓋線上所有環境、資料庫例項、事件的監控系統，
做到：
1） 覆蓋阿里全球子公司所有機房。
2） 覆蓋阿里生態包含新零售、新金融、新制造、新技術、新能源所有業務。
3） 覆蓋所有資料庫主機、作業系統、容器、資料庫、網路。
4） 所有效能指標做到 1 秒級連續不間斷監控。
5） 全天候持續穩定執行。
DBPaaS 監控雙 11 執行概況
2017 年雙 11，DBPaaS 平臺秒級監控系統每秒平均處理 1000 萬項效能指標，峰值處理 1400 萬項效能指標，為線上分佈在中國、美國、歐洲、東南亞的、所有資料庫例項健康執行保駕護航。做到了實時秒級監控，也就是說，任何時候，DBA 同學可以看到任何資料庫例項一秒以前的所有效能趨勢。
DBPaaS 監控系統僅使用 0.5% 的資料庫資源池的機器，支撐整個採集鏈路、計算鏈路、儲存、展現診斷系統。監控系統完美記錄今年每一次全鏈路壓測每個 RT 抖動現場，助力 DBA 快速診斷資料庫問題，併為後續系統優化提供建議。
在雙 11 大促保障期間，我們做到機器不擴容、服務不降級，讓 DBA 同學們喝茶度過雙 11。在日常業務執行保障, 我們也具備 7*24 服務能力。
我們是如何做到的
實現一個支援數萬資料庫例項的實時秒級監控系統，要解決許多技術挑戰。都說優秀的架構是演進過來，監控系統的建設也隨著規模和複雜性增加不斷迭代，到 2017 年，監控系統經歷了四個階段改進。
第一代監控系統
第一代監控系統架構非常簡單，採集 Agent 直接把效能資料寫入資料庫，監控系統直接查詢資料庫即可。
隨著資料庫叢集規模擴大，簡易架構的缺點也非常明顯。
首先，單機資料庫容量擴充套件性不足，隨著監控的資料庫規模擴大，日常效能指標寫入量非常大，資料庫容量捉襟見肘，長時間積累的監控歷史資料經常觸發磁碟空間預警，我們經常被迫刪除遠期資料。
其次，監控指標的擴充套件性不足。一開始資料庫監控項只有十幾項，但是很快就發現不夠用。因為經常有人拿著 MySQL 的文件說，我想看這個，我想看那個，能不能放到監控系統裡。效能指標展現的前提是儲存，在儲存層的擴充套件性缺陷讓我們頭痛不已。對於這種功能需求，無論是寬表還是窄表，都存在明顯的缺陷。如果用寬表，每新增一批效能指標，就要執行一次 DDL，雖然預定義擴充套件欄位可以緩解，但終究約束了產品想象空間。窄表在結構上解決了任意個效能指標的儲存問題，但是它也帶來了寫入資料量放大和儲存空間膨脹的弊病。最後，系統整體讀寫能力也不高，而且不具備水平擴充套件性。
以上所有原因催生了第二代監控系統的誕生。
第二代監控系統
第二代監控系統引入了 DataHub 模組和分散式文件資料庫。資料鏈路變成由採集 Agent 到 DataHub 到分散式文件資料庫，監控系統從分散式文件。
採集 Agent 專注於效能資料採集邏輯，構造統一資料格式，呼叫 DataHub 介面把資料傳輸到 DataHub，採集 Agent 不需要關心效能資料存在哪裡。DataHub 作為承上啟下的節點，實現了採集與儲存的解耦。第一，它對採集 Agent 遮蔽了資料儲存細節，僅暴露最簡單資料投遞介面；第二，DataHub 收到根據儲存引擎特性使用最優寫入模型，比如使用批量寫入、壓縮等方式；第三，使用 LVS、LSB 技術可以實現 DataHub 水平擴充套件。分散式文件資料庫部分了解決擴充套件性問題，水平擴容用於解決儲存容量不足的問題，schema free 的特性可以效能指標擴充套件性問題。
隨著監控系統持續執行，資料庫例項規模擴大，效能指標持續增加，監控系統使用者擴大，又遇到新的問題。第一，DBA 同學常常需要檢視資料庫跨越數月的效能趨勢，以預估資料庫流量未來趨勢，這時系統查詢速度基本不可用。第二，儲存長達一年的全量效能資料，成本變得越來越不可承受，每年雙 11 壓測時，DBA 同學總會問起去年雙 11 的效能趨勢。第三，DataHub 存在丟失採集資料的隱患，由於採集原始資料是先 buffer 在 DataHub 記憶體中，只要程式重啟，記憶體中的採集資料就會丟失。
第三代監控系統
關於查詢速度慢的問題，文件型資料庫和關係型資料庫一樣，都是面向行的資料庫，即讀寫的基本資料，每一秒的效能資料儲存一行，一行 N 個效能指標，效能指標被儲存在以時間為 key 的一個表格中。雖然同一時刻的所有效能指標被存在同一行，但是它們的關係卻沒那麼緊密。因為典型的監控診斷需求是查同一個或幾個指標在一段時間的變化趨勢，而不是查同一時刻的指標（瞬時值），比如這樣的：
資料庫儲存引擎為了查出某個指標的效能趨勢，卻要掃描所有指標的資料，CPU 和記憶體都開銷巨大，顯而易見，這些都是在浪費。雖然 Column Family 技術可以在一定程度上緩解上面說的問題，但是如何設定 Column Family 是個巨大挑戰，難道要儲存層的策略要和監控診斷層的需求耦合嗎？這看起來不是好辦法。
所以，我們把目光投向列式資料庫，監控效能指標讀寫特徵非常合適列式資料庫，以 OpenTSDB 為代表的時序資料庫，進入我們考察視野。OpenTSDB 用時間線來描述每一個帶有時間序列的特定物件，時間線的讀寫都是獨立的。毫無疑問，OpenTSDB 成為第三代監控系統架構的一部分。
為了消除 DataHub 穩定性隱患，引入分散式訊息佇列，起到削峰填谷作用，即使 DataHub 全線崩潰，也可以採用重新消費訊息的方式解決。分散式訊息佇列，可以選擇 Kafka 或 RocketMQ，這些分散式訊息佇列已經具備了高可用能力。
第三代架構相比過去有巨大的進步，在 2016 年雙 11 實現了全網資料庫 10 秒級監控，核心資料庫叢集 1 秒級監控。
隨著阿里生態擴大，全球化深入，各類全資子公司業務全面融合到阿里體系，除了中國大陸，還有美國、歐洲、俄羅斯、東南亞的業務。同時在阿里資料庫領域的新技術應用層出不窮，單元化部署已經成為常態，容器化排程正在覆蓋全網，儲存計算分離正在不斷推進，同一個業務資料庫叢集，在不同單元的部署策略可能也不同。與之對應的，DBA 團隊的規模並沒有相應擴大，一個 DBA 同學支援多個子公司業務是常態，有的 DBA 還要兼任新技術推廣等工作。在資料庫效能診斷這個環節，必須為 DBA 爭效率，為 DBA 提供從巨集觀到微觀到診斷路徑顯得越來越迫切：從大盤到叢集、到單元、到例項、到主機、容器等一站式服務。
在這樣的診斷需求下，第三代監控架構有點力不從心了，主要表現在查詢：
1） 高維度的效能診斷查詢速度慢，以叢集 QPS 為例，由於 OpenTSDB 裡儲存的每一個例項的 QPS 資料，當需要查詢叢集維度 QPS 就需要對掃描叢集每一個例項的 QPS，再 group by 時間戳 sum 所有例項 QPS。這需要掃描大量原始資料。
2） OpenTSDB 無法支援複雜的監控需求，比如檢視叢集平均 RT 趨勢，叢集平均 RT 並不是 avg(所有例項的 RT)，而是 sum(執行時間)/sum(執行次數)。為了實現目標只能查出 2 條時間線資料，在監控系統內部計算完後再展現在頁面中，使用者響應時間太長。
3） 長時間跨度的效能診斷速度慢，比如 1 個月的效能趨勢，需要掃描原始的秒級 2592000 個資料點到瀏覽器中展現，考慮到瀏覽器展現效能，實際並不能也沒必要展現原始秒級資料。展示 15 分鐘時間精度的資料就夠了。
上述提到的預計算問題，OpenTSDB 也意識到，其 2.4 版本開始，具備了簡陋預計算能力，無論從功能靈活性還是系統穩定性、效能，OpenTSDB 都無法滿足 DBPaaS 秒級監控需求。
DBPaaS 新一代架構
新一代架構，我們把 OpenTSDB 升級為更強勁的 HiTSDB，同時基於流式計算開發的實時預聚合引擎代替簡單的 DataHub，讓秒級監控飛。
在職責界定上，監控診斷需求的複雜性留給實時預聚合引擎來解決，對時序資料庫的查詢需求都限定在一條時間線內。這要求時序資料庫必須把單一時間線效能做到極致，由兄弟團隊開發的阿里巴巴高效能序資料庫 HiTSDB 做到了極致壓縮和極致讀寫能力，利用時序資料等距時間戳和數值小幅變化的特徵，它做了大量壓縮。同時它全面相容 OpenTSDB 協議，已經在阿里雲公測。
新架構讓我們放開雙手專注思考監控與診斷需求，不再受儲存層的束縛。第一，為了高維度效能趨勢查詢效能，預聚合引擎做到了預先按業務資料庫叢集、單元、例項把效能指標計算好，寫入 HiTSDB。第二，建立效能指標聚合計算函式庫，所有效能指標的聚合計算公式都是可以配置的，實現了自由的設定監控指標。第三，事先降時間精度，分為 6 個精度：1 秒、5 秒、15 秒、1 分鐘、5 分鐘、15 分鐘。不同時間精度的效能資料，才有不同的壓縮策略。
實時計算引擎
實時計算引擎實現了例項、單元、叢集三個維度逐級聚合，每一級聚合 Bolt 各自寫入 HiTSDB。流式計算平臺的選擇是自由，目前我們的程式執行在 JStorm 計算平臺上，JStorm 讓我們具備天生的高可用能力。
實時計算引擎效能
實時計算引擎使用了資料庫總機器規模 0.1% 的資源, 實現了全網秒級監控資料的計算，平均每秒處理超過 1000 萬項效能指標，平均寫入 TPS 600 萬，峰值 TPS 1400 萬，下圖是雙 11 期間 HiTSDB TPS 趨勢曲線。
關鍵優化點
用這麼少的計算資源就實現了這麼高吞吐量，必然用上了許多黑科技。
1） 在預計算中，我們使用增量迭代計算，無論是 5 秒精度的資料，還是 15 分鐘精度資料，我們不需要等時間視窗內所有的效能指標收集滿了，再開始計算，而是來多少效能資料，就算多少，僅保留中間結果，極大的節省記憶體。這項優化，相比常規計算方法至少節省 95% 記憶體。
2） 採集端，針對效能資料包文進行合併，把相似和相鄰的報文合併在一起上報到 kafka，這樣可以讓 JStorm 程式批量處理資料。
3） 利用流式計算的特性實現資料區域性性，同一個叢集單元的例項採集到的資料在同一個 kafka 分割槽。這樣可以減少計算過程的網路傳輸及 java 序列化 / 反序列化。這一項可以減少 50% 的網路傳輸。有興趣的朋友可以想想為什麼不能按例項分割槽或按叢集分割槽，會有什麼問題呢？
4） 使用 JStorm 自定義排程特性，讓具有資料相關性的計算 Bolt 排程在同一個 JVM 中，這個是為了配合上面第二步，實現資料流轉儘量發生在同一個 JVM 裡。
5） 對於不得不發生的 Map-Reduce 資料傳輸，儘量使用批量傳輸，並對傳輸的資料結構進行復用、裁剪，少傳輸重複資料，減少序列化、反序列化壓力。
未來展望
阿里 DBPaaS 全網秒級監控讓資料庫管控實現了數字化，經過這一年，我們積累了許多有價值的結構化資料。隨著大資料技術、機器學習技術的發展，為資料庫管控進入智慧化提供了可能性。
1） 智慧診斷，基於現有全方位無死角的監控，結合事件追蹤，智慧定位問題。
2） 排程優化，通過分析每個資料庫例項的畫像特徵，讓資源互補性的幾個資料庫例項排程在一起，最終節省成本。
3） 預算估計，通過分析資料庫歷史執行狀況, 在每次大促前，根據業務交易量目標，確定每一個資料庫叢集容量需求，進而為自動化擴容提供依據。
更多幹貨內容，可關注AI前線，ID：ai-front，後臺回覆「AI」、「TF」、「大資料」可獲得《AI前線》系列PDF迷你書和技能圖譜。