2017 雙 11 再次創下了 32.5 萬筆/秒交易紀錄，在這個數字后面，是每秒多達幾千萬次的數據庫寫入。

[[211398]]

如何大規模進行自動化操作、保證數據庫的穩定性、快速發現問題是一個巨大的難題，這也是數據庫管控平臺要完成的任務。

隨著阿里巴巴數據庫規模的不斷擴大，我們建設數據庫管控平臺也經歷了很多階段。

從腳本化、工具化、平臺化到目前的 DBPaaS，DBPaaS 在今年雙 11 中，***全面覆蓋集團、各子公司下的本地數據庫、公有云、混合云等多種場景。

今年雙 11，數據庫已經全面實現容器化部署，彈性使用離線資源、公有云資源支持大促。

全面優化的監控采集鏈路，實現了全網所有數據庫實例的秒級采集、監控、展現、診斷，每秒實時處理超過 1000 萬項監控指標，讓異常無所遁形。

DBPaaS 也持續在數據庫管理的自動化、規模化、數字化、智能化等方向進行突破。

在這其中，關于數據庫監控系統建設比較典型。在業務平時運行態，線上系統出現故障，在數萬數據庫中，如何發現異常、快速診斷亦是一件非常具有挑戰的事情。

在雙十一全鏈路壓測中，系統吞吐量未達預期或業務出現了 RT 抖動，快速診斷定位數據庫問題是一個現實課題。

此外，對于復雜數據庫，如何在故障事后排查故障根源、現場還原、歷史事件追蹤也迫使我們建設一個覆蓋線上所有環境、數據庫實例、事件的監控系統，做到：

• 覆蓋阿里全球子公司所有機房。
• 覆蓋阿里生態包含新零售、新金融、新制造、新技術、新能源所有業務。
• 覆蓋所有數據庫主機、操作系統、容器、數據庫、網絡。
• 所有性能指標做到 1 秒級連續不間斷監控。
• 全天候持續穩定運行。

DBPaaS 監控雙 11 運行概況

2017 年雙 11，DBPaaS 平臺秒級監控系統每秒平均處理 1000 萬項性能指標，峰值處理 1400 萬項性能指標，為線上分布在中國、美國、歐洲、東南亞的所有數據庫實例健康運行保駕護航。

系統做到了實時秒級監控，也就是說，任何時候，DBA 同學可以看到任何數據庫實例一秒以前的所有性能趨勢。

DBPaaS 監控系統僅使用 0.5% 的數據庫資源池的機器，支撐整個采集鏈路、計算鏈路、存儲、展現診斷系統。

監控系統***記錄今年每一次全鏈路壓測每個 RT 抖動現場，助力 DBA 快速診斷數據庫問題，并為后續系統優化提供建議。

在雙 11 大促保障期間，我們做到機器不擴容、服務不降級，讓 DBA 同學們喝茶度過雙 11。在日常業務的運行保障方面，我們也具備 7*24 服務能力。

如何做到喝茶度過雙 11

實現一個支持數萬數據庫實例的實時秒級監控系統，要解決許多技術挑戰。都說優秀的架構是演進過來，監控系統的建設也隨著規模和復雜性增加不斷迭代，到 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 提供從宏觀到微觀到診斷路徑顯得越來越迫切：從大盤到集群、到單元、到實例、到主機、容器等一站式服務。

在這樣的診斷需求下，第三代監控架構有點力不從心了，主要表現在查詢：

高維度的性能診斷查詢速度慢

以集群 QPS 為例，由于 OpenTSDB 里存儲著每一個實例的 QPS 數據，當需要查詢集群維度 QPS 就需要掃描集群每一個實例的 QPS，再 group by  時間戳，sum 所有實例 QPS，這需要掃描大量原始數據。

OpenTSDB 無法支持復雜的監控需求

比如查看集群平均 RT 趨勢，集群平均 RT 并不是 avg(所有實例的 RT)，而是 sum(執行時間)/sum(執行次數)。

為了實現目標只能查出 2 條時間線數據，在監控系統內部計算完后再展現在頁面中，用戶響應時間太長。

長時間跨度的性能診斷速度慢

比如查看 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 趨勢曲線。

關鍵優化點

用這么少的計算資源就實現了這么高吞吐量，必然用上了許多黑科技：

• 在預計算中，我們使用增量迭代計算，無論是 5 秒精度的數據，還是 15 分鐘精度數據，我們不需要等時間窗口內所有的性能指標收集滿了，再開始計算；而是來多少性能數據，就算多少，僅保留中間結果，極大的節省內存。這項優化，相比常規計算方法至少節省 95% 內存。
• 采集端，針對性能數據報文進行合并，把相似和相鄰的報文合并在一起上報到 kafka，這樣可以讓 JStorm 程序批量處理數據。
• 利用流式計算的特性實現數據局部性，同一個集群單元的實例采集到的數據在同一個 kafka 分區。

這樣可以減少計算過程的網絡傳輸及 Java 序列化/反序列化。這一項可以減少 50% 的網絡傳輸。有興趣的朋友可以想想為什么不能按實例分區或按集群分區，會有什么問題呢？

• 使用 JStorm 自定義調度特性，讓具有數據相關性的計算 Bolt 調度在同一個 JVM 中，這個是為了配合上面第二步，實現數據流轉盡量發生在同一個 JVM 里。
• 對于不得不發生的 Map-Reduce 數據傳輸，盡量使用批量傳輸，并對傳輸的數據結構進行復用、裁剪，少傳輸重復數據，減少序列化、反序列化壓力。

未來展望

阿里 DBPaaS 全網秒級監控讓數據庫管控實現了數字化，經過這一年，我們積累了許多有價值的結構化數據。

隨著大數據技術、機器學習技術的發展，為數據庫管控進入智能化提供了可能性：

• 智能診斷，基于現有全方位無死角的監控，結合事件追蹤，智能定位問題。
• 調度優化，通過分析每個數據庫實例的畫像特征，讓資源互補性的幾個數據庫實例調度在一起，最終節省成本。
• 預算估計，通過分析數據庫歷史運行狀況,在每次大促前，根據業務交易量目標，確定每一個數據庫集群容量需求，進而為自動化擴容提供依據。

[[211404]]

吳必良，花名未立，阿里巴巴技術專家，2014 年加入阿里巴巴， 2015 年開始專注在數據庫領域，目前負責阿里巴巴混合云數據庫管控平臺方面的建設，見證并推動實現了阿里數據庫監控系統從分鐘級到秒級的變遷， 對系統診斷、實時計算有深入的研究。對管控平臺的數字化、智能化探索***興趣， 期望通過在該領域的深入研究，持續提升數據庫在大規模場景下的穩定性、降低成本，歡迎志同道合的同學能一起加入。