摘要： 2017雙11再次創(chuàng)下了32.5萬筆/秒交易創(chuàng)建的紀(jì)錄，在這個(gè)數(shù)字后面，更是每秒多達(dá)幾千萬次的數(shù)據(jù)庫寫入，如何大規(guī)模進(jìn)行自動(dòng)化操作、保證數(shù)據(jù)庫的穩(wěn)定性、快速發(fā)現(xiàn)問題是一個(gè)巨大的難題， 這也是數(shù)據(jù)庫管控平臺(tái)要完成的任務(wù)。

作者：吳必良（未立）

前言
2017雙11再次創(chuàng)下了32.5萬筆/秒交易創(chuàng)建的紀(jì)錄，在這個(gè)數(shù)字后面，更是每秒多達(dá)幾千萬次的數(shù)據(jù)庫寫入，如何大規(guī)模進(jìn)行自動(dòng)化操作、保證數(shù)據(jù)庫的穩(wěn)定性、快速發(fā)現(xiàn)問題是一個(gè)巨大的難題， 這也是數(shù)據(jù)庫管控平臺(tái)要完成的任務(wù)。

隨著阿里巴巴數(shù)據(jù)庫規(guī)模的不斷擴(kuò)大，我們建設(shè)數(shù)據(jù)庫管控平臺(tái)也經(jīng)歷了很多階段，從腳本化、工具化、平臺(tái)化到目前的DBPaaS，DBPaaS在今年雙11中， 首次全面覆蓋集團(tuán)、各子公司下的本地?cái)?shù)據(jù)庫、公有云、混合云等多種場景。今年雙11，數(shù)據(jù)庫已經(jīng)全面實(shí)現(xiàn)容器化部署，彈性使用離線資源、公有云資源支持大促。全面優(yōu)化的監(jiān)控采集鏈路，實(shí)現(xiàn)了全網(wǎng)所有數(shù)據(jù)庫實(shí)例的秒級(jí)采集、監(jiān)控、展現(xiàn)、診斷。每秒實(shí)時(shí)處理超過1000萬項(xiàng)監(jiān)控指標(biāo)，讓異常無所遁形。DBPaaS也持續(xù)在數(shù)據(jù)庫管理的自動(dòng)化、規(guī)模化、數(shù)字化、智能化等方向進(jìn)行突破。

在這其中，關(guān)于數(shù)據(jù)庫監(jiān)控系統(tǒng)建設(shè)比較典型。

在業(yè)務(wù)平時(shí)運(yùn)行態(tài)，線上系統(tǒng)出現(xiàn)故障，在數(shù)萬數(shù)據(jù)庫中，如何發(fā)現(xiàn)異常、快速診斷亦是一件非常具有挑戰(zhàn)的事情。在雙十一全鏈路壓測中，系統(tǒng)吞吐量未達(dá)預(yù)期或業(yè)務(wù)出現(xiàn)了RT抖動(dòng)，快速診斷定位數(shù)據(jù)庫問題是一個(gè)現(xiàn)實(shí)課題。此外，對于復(fù)雜數(shù)據(jù)庫故障事后排查故障根源、現(xiàn)場還原、歷史事件追蹤也迫使我們建設(shè)一個(gè)覆蓋線上所有環(huán)境、數(shù)據(jù)庫實(shí)例、事件的監(jiān)控系統(tǒng)，做到：

覆蓋阿里全球子公司所有機(jī)房。
覆蓋阿里生態(tài)包含新零售、新金融、新制造、新技術(shù)、新能源所有業(yè)務(wù)。
覆蓋所有數(shù)據(jù)庫主機(jī)、操作系統(tǒng)、容器、數(shù)據(jù)庫、網(wǎng)絡(luò)。
所有性能指標(biāo)做到1秒級(jí)連續(xù)不間斷監(jiān)控。
全天候持續(xù)穩(wěn)定運(yùn)行。
DBPaaS監(jiān)控雙11運(yùn)行概況
2017年雙11，DBPaaS平臺(tái)秒級(jí)監(jiān)控系統(tǒng)每秒平均處理1000萬項(xiàng)性能指標(biāo)，峰值處理1400萬項(xiàng)性能指標(biāo)，為線上分布在中國、美國、歐洲、東南亞的、所有數(shù)據(jù)庫實(shí)例健康運(yùn)行保駕護(hù)航。做到了實(shí)時(shí)秒級(jí)監(jiān)控，也就是說，任何時(shí)候，DBA同學(xué)可以看到任何數(shù)據(jù)庫實(shí)例一秒以前的所有性能趨勢。

DBPaaS監(jiān)控系統(tǒng)僅使用0.5%的數(shù)據(jù)庫資源池的機(jī)器，支撐整個(gè)采集鏈路、計(jì)算鏈路、存儲(chǔ)、展現(xiàn)診斷系統(tǒng)。監(jiān)控系統(tǒng)完美記錄今年每一次全鏈路壓測每個(gè)RT抖動(dòng)現(xiàn)場，助力DBA快速診斷數(shù)據(jù)庫問題，并為后續(xù)系統(tǒng)優(yōu)化提供建議。

在雙11大促保障期間，我們做到機(jī)器不擴(kuò)容、服務(wù)不降級(jí)，讓DBA同學(xué)們喝茶度過雙11。在日常業(yè)務(wù)運(yùn)行保障,我們也具備7*24服務(wù)能力。

我們是如何做到的
實(shí)現(xiàn)一個(gè)支持?jǐn)?shù)萬數(shù)據(jù)庫實(shí)例的實(shí)時(shí)秒級(jí)監(jiān)控系統(tǒng)，要解決許多技術(shù)挑戰(zhàn)。都說優(yōu)秀的架構(gòu)是演進(jìn)過來，監(jiān)控系統(tǒng)的建設(shè)也隨著規(guī)模和復(fù)雜性增加不斷迭代，到2017年，監(jiān)控系統(tǒng)經(jīng)歷了四個(gè)階段改進(jìn)。

第一代監(jiān)控系統(tǒng)
第一代監(jiān)控系統(tǒng)架構(gòu)非常簡單，采集Agent直接把性能數(shù)據(jù)寫入數(shù)據(jù)庫，監(jiān)控系統(tǒng)直接查詢數(shù)據(jù)庫即可。

隨著數(shù)據(jù)庫集群規(guī)模擴(kuò)大，簡易架構(gòu)的缺點(diǎn)也非常明顯。

首先，單機(jī)數(shù)據(jù)庫容量擴(kuò)展性不足，隨著監(jiān)控的數(shù)據(jù)庫規(guī)模擴(kuò)大，日常性能指標(biāo)寫入量非常大，數(shù)據(jù)庫容量捉襟見肘，長時(shí)間積累的監(jiān)控歷史數(shù)據(jù)經(jīng)常觸發(fā)磁盤空間預(yù)警，我們經(jīng)常被迫刪除遠(yuǎn)期數(shù)據(jù)。

其次，監(jiān)控指標(biāo)的擴(kuò)展性不足。一開始數(shù)據(jù)庫監(jiān)控項(xiàng)只有十幾項(xiàng)，但是很快就發(fā)現(xiàn)不夠用。因?yàn)榻?jīng)常有人拿著MySQL的文檔說，我想看這個(gè)，我想看那個(gè)，能不能放到監(jiān)控系統(tǒng)里。性能指標(biāo)展現(xiàn)的前提是存儲(chǔ)，在存儲(chǔ)層的擴(kuò)展性缺陷讓我們頭痛不已。對于這種功能需求，無論是寬表還是窄表，都存在明顯的缺陷。如果用寬表，每新增一批性能指標(biāo)，就要執(zhí)行一次DDL，雖然預(yù)定義擴(kuò)展字段可以緩解，但終究約束了產(chǎn)品想象空間。窄表在結(jié)構(gòu)上解決了任意個(gè)性能指標(biāo)的存儲(chǔ)問題，但是它也帶來了寫入數(shù)據(jù)量放大和存儲(chǔ)空間膨脹的弊病。

最后，系統(tǒng)整體讀寫能力也不高，而且不具備水平擴(kuò)展性。

以上所有原因催生了第二代監(jiān)控系統(tǒng)的誕生。

第二代監(jiān)控系統(tǒng)
第二代監(jiān)控系統(tǒng)引入了DataHub模塊和分布式文檔數(shù)據(jù)庫。數(shù)據(jù)鏈路變成由采集Agent到DataHub到分布式文檔數(shù)據(jù)庫，監(jiān)控系統(tǒng)從分布式文檔。

采集Agent專注于性能數(shù)據(jù)采集邏輯，構(gòu)造統(tǒng)一數(shù)據(jù)格式，調(diào)用DataHub接口把數(shù)據(jù)傳輸?shù)紻ataHub，采集Agent不需要關(guān)心性能數(shù)據(jù)存在哪里。DataHub作為承上啟下的節(jié)點(diǎn)，實(shí)現(xiàn)了采集與存儲(chǔ)的解耦。第一，它對采集Agent屏蔽了數(shù)據(jù)存儲(chǔ)細(xì)節(jié)，僅暴露最簡單數(shù)據(jù)投遞接口；第二，DataHub收到根據(jù)存儲(chǔ)引擎特性使用最優(yōu)寫入模型，比如使用批量寫入、壓縮等方式；第三，使用LVS、LSB技術(shù)可以實(shí)現(xiàn)DataHub水平擴(kuò)展。分布式文檔數(shù)據(jù)庫部分了解決擴(kuò)展性問題，水平擴(kuò)容用于解決存儲(chǔ)容量不足的問題，schema free的特性可以性能指標(biāo)擴(kuò)展性問題。

隨著監(jiān)控系統(tǒng)持續(xù)運(yùn)行，數(shù)據(jù)庫實(shí)例規(guī)模擴(kuò)大，性能指標(biāo)持續(xù)增加，監(jiān)控系統(tǒng)用戶擴(kuò)大，又遇到新的問題。第一，DBA同學(xué)常常需要查看數(shù)據(jù)庫跨越數(shù)月的性能趨勢，以預(yù)估數(shù)據(jù)庫流量未來趨勢，這時(shí)系統(tǒng)查詢速度基本不可用。第二，存儲(chǔ)長達(dá)一年的全量性能數(shù)據(jù)，成本變得越來越不可承受，每年雙11壓測時(shí)，DBA同學(xué)總會(huì)問起去年雙11的性能趨勢。第三，DataHub存在丟失采集數(shù)據(jù)的隱患，由于采集原始數(shù)據(jù)是先buffer在DataHub內(nèi)存中，只要進(jìn)程重啟，內(nèi)存中的采集數(shù)據(jù)就會(huì)丟失。

第三代監(jiān)控系統(tǒng)
關(guān)于查詢速度慢的問題，文檔型數(shù)據(jù)庫和關(guān)系型數(shù)據(jù)庫一樣，都是面向行的數(shù)據(jù)庫，即讀寫的基本數(shù)據(jù)，每一秒的性能數(shù)據(jù)存儲(chǔ)一行，一行N個(gè)性能指標(biāo)，性能指標(biāo)被存儲(chǔ)在以時(shí)間為key的一個(gè)表格中。雖然同一時(shí)刻的所有性能指標(biāo)被存在同一行，但是它們的關(guān)系卻沒那么緊密。因?yàn)榈湫偷谋O(jiān)控診斷需求是查同一個(gè)或幾個(gè)指標(biāo)在一段時(shí)間的變化趨勢，而不是查同一時(shí)刻的指標(biāo)（瞬時(shí)值），比如這樣的：

數(shù)據(jù)庫存儲(chǔ)引擎為了查出某個(gè)指標(biāo)的性能趨勢，卻要掃描所有指標(biāo)的數(shù)據(jù)，CPU和內(nèi)存都開銷巨大，顯而易見，這些都是在浪費(fèi)。雖然Column Family技術(shù)可以在一定程度上緩解上面說的問題，但是如何設(shè)定Column Family是個(gè)巨大挑戰(zhàn)，難道要存儲(chǔ)層的策略要和監(jiān)控診斷層的需求耦合嗎？這看起來不是好辦法。

所以，我們把目光投向列式數(shù)據(jù)庫，監(jiān)控性能指標(biāo)讀寫特征非常合適列式數(shù)據(jù)庫，以O(shè)penTSDB為代表的時(shí)序數(shù)據(jù)庫，進(jìn)入我們考察視野。OpenTSDB用時(shí)間線來描述每一個(gè)帶有時(shí)間序列的特定對象，時(shí)間線的讀寫都是獨(dú)立的。

毫無疑問，OpenTSDB成為第三代監(jiān)控系統(tǒng)架構(gòu)的一部分。

為了消除DataHub穩(wěn)定性隱患，引入分布式消息隊(duì)列，起到削峰填谷作用，即使DataHub全線崩潰，也可以采用重新消費(fèi)消息的方式解決。分布式消息隊(duì)列，可以選擇Kafka 或 RocketMQ，這些分布式消息隊(duì)列已經(jīng)具備了高可用能力。

第三代架構(gòu)相比過去有巨大的進(jìn)步，在2016年雙11實(shí)現(xiàn)了全網(wǎng)數(shù)據(jù)庫10秒級(jí)監(jiān)控，核心數(shù)據(jù)庫集群1秒級(jí)監(jiān)控。

隨著阿里生態(tài)擴(kuò)大，全球化深入，各類全資子公司業(yè)務(wù)全面融合到阿里體系，除了中國大陸，還有美國、歐洲、俄羅斯、東南亞的業(yè)務(wù)。同時(shí)在阿里數(shù)據(jù)庫領(lǐng)域的新技術(shù)應(yīng)用層出不窮，單元化部署已經(jīng)成為常態(tài)，容器化調(diào)度正在覆蓋全網(wǎng)，存儲(chǔ)計(jì)算分離正在不斷推進(jìn)，同一個(gè)業(yè)務(wù)數(shù)據(jù)庫集群，在不同單元的部署策略可能也不同。與之對應(yīng)的，DBA團(tuán)隊(duì)的規(guī)模并沒有相應(yīng)擴(kuò)大，一個(gè)DBA同學(xué)支持多個(gè)子公司業(yè)務(wù)是常態(tài)，有的DBA還要兼任新技術(shù)推廣等工作。在數(shù)據(jù)庫性能診斷這個(gè)環(huán)節(jié)，必須為DBA爭效率，為DBA提供從宏觀到微觀到診斷路徑顯得越來越迫切：從大盤到集群、到單元、到實(shí)例、到主機(jī)、容器等一站式服務(wù)。

在這樣的診斷需求下，第三代監(jiān)控架構(gòu)有點(diǎn)力不從心了，主要表現(xiàn)在查詢：

高維度的性能診斷查詢速度慢，以集群QPS為例，由于OpenTSDB里存儲(chǔ)的每一個(gè)實(shí)例的QPS數(shù)據(jù)，當(dāng)需要查詢集群維度QPS就需要對掃描集群每一個(gè)實(shí)例的QPS，再group by 時(shí)間戳 sum所有實(shí)例QPS。這需要掃描大量原始數(shù)據(jù)。
OpenTSDB無法支持復(fù)雜的監(jiān)控需求，比如查看集群平均RT趨勢，集群平均RT并不是avg(所有實(shí)例的RT)，而是sum(執(zhí)行時(shí)間)/sum(執(zhí)行次數(shù))。為了實(shí)現(xiàn)目標(biāo)只能查出2條時(shí)間線數(shù)據(jù)，在監(jiān)控系統(tǒng)內(nèi)部計(jì)算完后再展現(xiàn)在頁面中，用戶響應(yīng)時(shí)間太長。
長時(shí)間跨度的性能診斷速度慢，比如1個(gè)月的性能趨勢，需要掃描原始的秒級(jí)2592000個(gè)數(shù)據(jù)點(diǎn)到瀏覽器中展現(xiàn)，考慮到瀏覽器展現(xiàn)性能，實(shí)際并不能也沒必要展現(xiàn)原始秒級(jí)數(shù)據(jù)。展示15分鐘時(shí)間精度的數(shù)據(jù)就夠了。
上述提到的預(yù)計(jì)算問題，OpenTSDB也意識(shí)到，其2.4版本開始，具備了簡陋預(yù)計(jì)算能力，無論從功能靈活性還是系統(tǒng)穩(wěn)定性、性能，OpenTSDB都無法滿足DBPaaS秒級(jí)監(jiān)控需求。

DBPaaS新一代架構(gòu)
新一代架構(gòu)，我們把OpenTSDB升級(jí)為更強(qiáng)勁的HiTSDB，同時(shí)基于流式計(jì)算開發(fā)的實(shí)時(shí)預(yù)聚合引擎代替簡單的DataHub，讓秒級(jí)監(jiān)控飛。

在職責(zé)界定上，監(jiān)控診斷需求的復(fù)雜性留給實(shí)時(shí)預(yù)聚合引擎來解決，對時(shí)序數(shù)據(jù)庫的查詢需求都限定在一條時(shí)間線內(nèi)。這要求時(shí)序數(shù)據(jù)庫必須把單一時(shí)間線性能做到極致，由兄弟團(tuán)隊(duì)開發(fā)的阿里巴巴高性能序數(shù)據(jù)庫HiTSDB做到了極致壓縮和極致讀寫能力，利用時(shí)序數(shù)據(jù)等距時(shí)間戳和數(shù)值小幅變化的特征，它做了大量壓縮。同時(shí)它全面兼容OpenTSDB協(xié)議，已經(jīng)在阿里云公測。

新架構(gòu)讓我們放開雙手專注思考監(jiān)控與診斷需求，不再受存儲(chǔ)層的束縛。第一，為了高維度性能趨勢查詢性能，預(yù)聚合引擎做到了預(yù)先按業(yè)務(wù)數(shù)據(jù)庫集群、單元、實(shí)例把性能指標(biāo)計(jì)算好，寫入HiTSDB。第二，建立性能指標(biāo)聚合計(jì)算函數(shù)庫，所有性能指標(biāo)的聚合計(jì)算公式都是可以配置的，實(shí)現(xiàn)了自由的設(shè)定監(jiān)控指標(biāo)。第三，事先降時(shí)間精度，分為6個(gè)精度：1秒、5秒、15秒、1分鐘、5分鐘、15分鐘。不同時(shí)間精度的性能數(shù)據(jù)，才有不同的壓縮策略。

實(shí)時(shí)計(jì)算引擎
實(shí)時(shí)計(jì)算引擎實(shí)現(xiàn)了實(shí)例、單元、集群三個(gè)維度逐級(jí)聚合，每一級(jí)聚合Bolt各自寫入HiTSDB。流式計(jì)算平臺(tái)的選擇是自由，目前我們的程序運(yùn)行在JStorm計(jì)算平臺(tái)上，JStorm讓我們具備天生的高可用能力。

實(shí)時(shí)計(jì)算引擎性能
實(shí)時(shí)計(jì)算引擎使用了數(shù)據(jù)庫總機(jī)器規(guī)模0.1%的資源,實(shí)現(xiàn)了全網(wǎng)秒級(jí)監(jiān)控?cái)?shù)據(jù)的計(jì)算，平均每秒處理超過1000萬項(xiàng)性能指標(biāo)，平均寫入TPS 600萬，峰值TPS 1400萬，下圖是雙11期間HiTSDB TPS趨勢曲線。

關(guān)鍵優(yōu)化點(diǎn)
用這么少的計(jì)算資源就實(shí)現(xiàn)了這么高吞吐量，必然用上了許多黑科技。

在預(yù)計(jì)算中，我們使用增量迭代計(jì)算，無論是5秒精度的數(shù)據(jù)，還是15分鐘精度數(shù)據(jù)，我們不需要等時(shí)間窗口內(nèi)所有的性能指標(biāo)收集滿了，再開始計(jì)算，而是來多少性能數(shù)據(jù)，就算多少，僅保留中間結(jié)果，極大的節(jié)省內(nèi)存。這項(xiàng)優(yōu)化，相比常規(guī)計(jì)算方法至少節(jié)省95%內(nèi)存。
采集端，針對性能數(shù)據(jù)報(bào)文進(jìn)行合并，把相似和相鄰的報(bào)文合并在一起上報(bào)到kafka，這樣可以讓JStorm程序批量處理數(shù)據(jù)。
利用流式計(jì)算的特性實(shí)現(xiàn)數(shù)據(jù)局部性，同一個(gè)集群單元的實(shí)例采集到的數(shù)據(jù)在同一個(gè)kafka分區(qū)。這樣可以減少計(jì)算過程的網(wǎng)絡(luò)傳輸及java 序列化/反序列化。這一項(xiàng)可以減少50%的網(wǎng)絡(luò)傳輸。有興趣的朋友可以想想為什么不能按實(shí)例分區(qū)或按集群分區(qū)，會(huì)有什么問題呢？
使用JStorm自定義調(diào)度特性，讓具有數(shù)據(jù)相關(guān)性的計(jì)算Bolt調(diào)度在同一個(gè)JVM中，這個(gè)是為了配合上面第二步，實(shí)現(xiàn)數(shù)據(jù)流轉(zhuǎn)盡量發(fā)生在同一個(gè)JVM里。
對于不得不發(fā)生的Map-Reduce數(shù)據(jù)傳輸，盡量使用批量傳輸，并對傳輸?shù)臄?shù)據(jù)結(jié)構(gòu)進(jìn)行復(fù)用、裁剪，少傳輸重復(fù)數(shù)據(jù)，減少序列化、反序列化壓力。
未來展望
阿里DBPaaS全網(wǎng)秒級(jí)監(jiān)控讓數(shù)據(jù)庫管控實(shí)現(xiàn)了數(shù)字化，經(jīng)過這一年，我們積累了許多有價(jià)值的結(jié)構(gòu)化數(shù)據(jù)。隨著大數(shù)據(jù)技術(shù)、機(jī)器學(xué)習(xí)技術(shù)的發(fā)展，為數(shù)據(jù)庫管控進(jìn)入智能化提供了可能性。

智能診斷，基于現(xiàn)有全方位無死角的監(jiān)控，結(jié)合事件追蹤，智能定位問題。
調(diào)度優(yōu)化，通過分析每個(gè)數(shù)據(jù)庫實(shí)例的畫像特征，讓資源互補(bǔ)性的幾個(gè)數(shù)據(jù)庫實(shí)例調(diào)度在一起，最終節(jié)省成本。
預(yù)算估計(jì)，通過分析數(shù)據(jù)庫歷史運(yùn)行狀況,在每次大促前，根據(jù)業(yè)務(wù)交易量目標(biāo)，確定每一個(gè)數(shù)據(jù)庫集群容量需求，進(jìn)而為自動(dòng)化擴(kuò)容提供依據(jù)。

總結(jié)

以上是生活随笔為你收集整理的2017双11技术揭秘—阿里数据库进入全网秒级实时监控时代的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。