作者：吳必良（未立）
2017雙11再次創下了32.5萬筆/秒交易建立的紀錄，在這個數字後面，更是每秒多達幾千萬次的資料庫寫入，如何大規模進行自動化操作、保證資料庫的穩定性、快速發現問題是一個巨大的難題， 這也是資料庫管控平台要完成的任務。
随着阿裡巴巴資料庫規模的不斷擴大，我們建設資料庫管控平台也經曆了很多階段，從腳本化、工具化、平台化到目前的DBPaaS，DBPaaS在今年雙11中， 首次全面覆寫集團、各子公司下的本地資料庫、公有雲、混合雲等多種場景。今年雙11，資料庫已經全面實作容器化部署，彈性使用離線資源、公有雲資源支援大促。全面優化的監控采集鍊路，實作了全網所有資料庫執行個體的秒級采集、監控、展現、診斷。每秒實時處理超過1000萬項監控名額，讓異常無所遁形。DBPaaS也持續在資料庫管理的自動化、規模化、數字化、智能化等方向進行突破。
在這其中，關于資料庫監控系統建設比較典型。
在業務平時運作态，線上系統出現故障，在數萬資料庫中，如何發現異常、快速診斷亦是一件非常具有挑戰的事情。在雙十一全鍊路壓測中，系統吞吐量未達預期或業務出現了RT抖動，快速診斷定位資料庫問題是一個現實課題。此外，對于複雜資料庫故障事後排查故障根源、現場還原、曆史事件追蹤也迫使我們建設一個覆寫線上所有環境、資料庫執行個體、事件的監控系統，做到：
覆寫阿裡全球子公司所有機房。
覆寫阿裡生态包含新零售、新金融、新制造、新技術、新能源所有業務。
覆寫所有資料庫主機、作業系統、容器、資料庫、網絡。
所有性能名額做到1秒級連續不間斷監控。
全天候持續穩定運作。
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提供從宏觀到微觀到診斷路徑顯得越來越迫切：從大盤到叢集、到單元、到執行個體、到主機、容器等一站式服務。
在這樣的診斷需求下，第三代監控架構有點力不從心了，主要表現在查詢：
高次元的性能診斷查詢速度慢，以叢集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秒級監控需求。
新一代架構，我們把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全網秒級監控讓資料庫管控實作了數字化，經過這一年，我們積累了許多有價值的結構化資料。随着大資料技術、機器學習技術的發展，為資料庫管控進入智能化提供了可能性。
智能診斷，基于現有全方位無死角的監控，結合事件追蹤，智能定位問題。
排程優化，通過分析每個資料庫執行個體的畫像特征，讓資源互補性的幾個資料庫執行個體排程在一起，最終節省成本。
預算估計，通過分析資料庫曆史運作狀況,在每次大促前，根據業務交易量目标，确定每一個資料庫叢集容量需求，進而為自動化擴容提供依據。