ccf 智能运维 裴丹_智能运维 聊一聊实时计算系统
本文是我在實(shí)時(shí)數(shù)據(jù)計(jì)算系統(tǒng)的設(shè)計(jì)、開(kāi)發(fā)、運(yùn)維生涯的一部分經(jīng)驗(yàn)總結(jié)。主要介紹一些設(shè)計(jì)思路和常見(jiàn)問(wèn)題的解決方案,不關(guān)注具體計(jì)算框架的使用。
本人主要致力于監(jiān)控系統(tǒng)數(shù)據(jù)計(jì)算方向,主要業(yè)務(wù)場(chǎng)景有:監(jiān)控?cái)?shù)據(jù)的ETL、數(shù)據(jù)匯聚、分析、異常檢測(cè)等。
由于監(jiān)控系統(tǒng)對(duì)時(shí)效性有較高需求,所以我們的計(jì)算系統(tǒng)更偏向?qū)崟r(shí)系統(tǒng),根據(jù)業(yè)務(wù)場(chǎng)景的不同,延遲從數(shù)百毫秒到分鐘不等。下文提到的計(jì)算架構(gòu)更多是指整個(gè)計(jì)算處理通路,主要以監(jiān)控場(chǎng)景下的系統(tǒng)設(shè)計(jì)為例,相信與其他場(chǎng)景下的架構(gòu)也有相通之處。
文章從以下幾個(gè)方面展開(kāi):
首先,在第1節(jié),我們簡(jiǎn)述不同數(shù)據(jù)規(guī)模和場(chǎng)景下,監(jiān)控系統(tǒng)計(jì)算架構(gòu)的可選方案。在公司、業(yè)務(wù)發(fā)展的不同階段,主要矛盾不同,能夠投入人力物力資源不同,需要選擇合適的架構(gòu)方案。
實(shí)時(shí)計(jì)算系統(tǒng)的設(shè)計(jì)有一個(gè)核心問(wèn)題:如何同時(shí)滿足高時(shí)效性和數(shù)據(jù)準(zhǔn)確性?在現(xiàn)實(shí)環(huán)境中,高時(shí)效性和準(zhǔn)確性很難同時(shí)達(dá)到,第2節(jié)中介紹了Watermark機(jī)制以實(shí)現(xiàn)兩者的平衡。
第3節(jié)介紹百度監(jiān)控系統(tǒng)的實(shí)時(shí)計(jì)算系統(tǒng)架構(gòu),描述了其基本組成、思路和實(shí)現(xiàn)中一些常見(jiàn)問(wèn)題的解決方案。
最后,簡(jiǎn)單討論了實(shí)時(shí)計(jì)算系統(tǒng)可用性建設(shè)。
監(jiān)控系統(tǒng)計(jì)算架構(gòu)選型
對(duì)于包含數(shù)百到千級(jí)別節(jié)點(diǎn)的小集群,數(shù)據(jù)規(guī)模有限,所有采集、存儲(chǔ)、計(jì)算邏輯都可以集成在一個(gè)模塊中實(shí)現(xiàn),這種多為領(lǐng)域?qū)S孟到y(tǒng)。監(jiān)控系統(tǒng)中,典型的有Prometheus,其采用單服務(wù)節(jié)點(diǎn)架構(gòu),提供簡(jiǎn)單的HA模式進(jìn)行容錯(cuò),這種架構(gòu)的優(yōu)點(diǎn)是部署使用簡(jiǎn)單。受限于單機(jī)資源,適合部署自治的多個(gè)實(shí)例,每個(gè)實(shí)例監(jiān)控不同服務(wù)。大規(guī)模集群情況下,要實(shí)現(xiàn)全局的監(jiān)控,需要合并多個(gè)監(jiān)控實(shí)例的數(shù)據(jù),在配置分發(fā)、可用性、容錯(cuò)、自動(dòng)化部署管理等方面都需要更多的工作。從開(kāi)發(fā)角度考慮,由于功能耦合嚴(yán)重,不利于開(kāi)發(fā)升級(jí)。
比起領(lǐng)域?qū)S孟到y(tǒng),還有一種架構(gòu)是使用通用性更強(qiáng)的OLAP系統(tǒng)來(lái)實(shí)現(xiàn)實(shí)時(shí)或者近實(shí)時(shí)的計(jì)算功能,如TSDB、ElasticSearch等系統(tǒng)都有一定的聚合計(jì)算能力。這些分布式系統(tǒng)都有水平擴(kuò)展能力和容錯(cuò)能力,但難以實(shí)現(xiàn)復(fù)雜業(yè)務(wù)計(jì)算,同時(shí)延遲不可控,復(fù)雜查詢或大批量數(shù)據(jù)查詢的延遲可能會(huì)達(dá)到分鐘級(jí)別。
更多的情況下我們采用存儲(chǔ)計(jì)算分離的方案,以便存儲(chǔ)和計(jì)算的各自演進(jìn)和平臺(tái)化。通常由一個(gè)提供精細(xì)查詢能力的存儲(chǔ)服務(wù)與一個(gè)計(jì)算模塊組成。計(jì)算模塊根據(jù)計(jì)算規(guī)則從存儲(chǔ)系統(tǒng)中拉取數(shù)據(jù)并進(jìn)行計(jì)算,這個(gè)架構(gòu)的瓶頸在于存儲(chǔ)系統(tǒng)能夠支持的查詢規(guī)模。根據(jù)我們的經(jīng)驗(yàn),基于精心設(shè)計(jì)的內(nèi)存數(shù)據(jù)庫(kù)集群,能夠承受百萬(wàn)級(jí)別的并發(fā)查詢。這種架構(gòu)下計(jì)算任務(wù)多為周期性調(diào)度,當(dāng)查詢性能下降時(shí)會(huì)造成任務(wù)的堆積。這個(gè)模型不方便處理延遲數(shù)據(jù),需要一定機(jī)制預(yù)測(cè)數(shù)據(jù)完整時(shí)間,調(diào)度任務(wù)進(jìn)行重算,任務(wù)調(diào)度的復(fù)雜度高。基于索引查詢的計(jì)算系統(tǒng)的延遲取決于計(jì)算輪詢的周期,適用于聚合類的涉及時(shí)間窗口的運(yùn)算操作。
在更高數(shù)據(jù)量和計(jì)算規(guī)則的情況下,流式計(jì)算是一個(gè)自然的選擇,降低了寫(xiě)存儲(chǔ)、索引、查詢的消耗,計(jì)算延遲大幅降低。
當(dāng)數(shù)據(jù)量進(jìn)一步上升,需要的網(wǎng)絡(luò)吞吐、計(jì)算能力驟增,后端的算力難以跟上數(shù)據(jù)量的增長(zhǎng)。這時(shí)候可以將計(jì)算能力分散到全鏈路,將計(jì)算提前到數(shù)據(jù)產(chǎn)生端。在監(jiān)控系統(tǒng)中,通過(guò)在采集端進(jìn)行預(yù)計(jì)算和ETL操作,提取或整合有用信息,對(duì)于實(shí)時(shí)日志采集,能大幅度降低傳輸?shù)胶蠖说臄?shù)據(jù)量。放到更大的視角上,這種將算力下放到數(shù)據(jù)源的思想,是目前大熱的邊緣計(jì)算的一個(gè)主要思路。
近年來(lái),Serverless計(jì)算架構(gòu)得到了更多的重視。這個(gè)模型將計(jì)算抽象為事件以及觸發(fā)的計(jì)算邏輯,計(jì)算邏輯實(shí)際由框架調(diào)度、分配資源執(zhí)行。用戶只需要編寫(xiě)計(jì)算邏輯,而不用關(guān)心可用性、可擴(kuò)展、負(fù)載均衡等后端代碼,極大的降低了開(kāi)發(fā)成本。通過(guò)按需調(diào)度,自動(dòng)擴(kuò)縮容,業(yè)務(wù)運(yùn)維方不再關(guān)心容量規(guī)劃等問(wèn)題。私以為當(dāng)前常見(jiàn)計(jì)算框架的Serverless化是一個(gè)值得嘗試的方向。目前的Serverless框架還存在很多問(wèn)題,例如調(diào)度初始化虛機(jī)、容器的成本高,缺乏狀態(tài)存儲(chǔ)等,比較適用于無(wú)狀態(tài)的計(jì)算。
一般來(lái)說(shuō)根據(jù)場(chǎng)景需求,通常對(duì)不同的架構(gòu)會(huì)組合使用。例如百度監(jiān)控系統(tǒng)內(nèi)部是以流式計(jì)算與近線計(jì)算相結(jié)合的方式提供服務(wù)的,近線計(jì)算從時(shí)序數(shù)據(jù)庫(kù)(TSDB)中拉取數(shù)據(jù)進(jìn)行計(jì)算。對(duì)于Trace、在線數(shù)據(jù)分析等具有比較復(fù)雜查詢需求但是相對(duì)比較低頻的操作,更適合基于索引查詢的架構(gòu)。
準(zhǔn)確性與時(shí)效性
對(duì)于實(shí)時(shí)系統(tǒng),我們對(duì)時(shí)效性有更嚴(yán)格的需求,但是通常高時(shí)效性伴隨著低準(zhǔn)確度,二者不可兼得。在分布式環(huán)境下,天然存在長(zhǎng)尾的延遲數(shù)據(jù),這可能是原始數(shù)據(jù)自身的延遲,也可能是由采集點(diǎn)異常、網(wǎng)絡(luò)延遲、網(wǎng)絡(luò)抖動(dòng)、數(shù)據(jù)通路中負(fù)載等造成的延遲。數(shù)據(jù)源越多,分散的越廣,這個(gè)長(zhǎng)尾效應(yīng)就會(huì)越嚴(yán)重,等待數(shù)據(jù)完整所需要的時(shí)間也越長(zhǎng)。我們需要在最終數(shù)據(jù)的準(zhǔn)確性和時(shí)效性間做折中。
不同場(chǎng)景對(duì)兩者的需求不一致,通常來(lái)說(shuō)報(bào)警、自動(dòng)止損等操作需要最高的時(shí)效性,能夠容忍一定的精度缺失,在審計(jì)、訂單等數(shù)據(jù)上我們更多的追求準(zhǔn)確性,時(shí)效性可以適當(dāng)放寬。解決這個(gè)折衷的常用機(jī)制是Watermark。
Watermark是在數(shù)據(jù)流中增加標(biāo)志信息,用以指示一個(gè)窗口內(nèi)的數(shù)據(jù)已經(jīng)“完全”到達(dá),可以進(jìn)行計(jì)算。
示例:
假設(shè)我們要統(tǒng)計(jì)10s內(nèi)到達(dá)的事件數(shù)目,以事件時(shí)間(Event Time,即事件攜帶的時(shí)間,多為事件產(chǎn)生時(shí)間)作為時(shí)間基準(zhǔn)。如下圖所示,橫線為Wall Time時(shí)間線,單位為s。圓球表示事件,圓球里面的數(shù)字為事件時(shí)間,其虛線指向產(chǎn)生時(shí)間,圓球正對(duì)的Wall Time時(shí)間線上的點(diǎn)為被計(jì)算系統(tǒng)處理的時(shí)間(Process Time),兩個(gè)時(shí)間之間的差值為實(shí)際延遲。每個(gè)事件都或多或少存在延遲,其中數(shù)字為45的圓球延遲最大。對(duì)于事件時(shí)間[40, 50]這個(gè)匯聚窗口,假設(shè)我們將Watermark線畫(huà)在53處,則我們認(rèn)為數(shù)據(jù)在53之前已經(jīng)完全到達(dá),已經(jīng)接收到的那些數(shù)據(jù)可以參與匯聚,Watermark之后到來(lái)的事件則忽略。
具體怎么確定Watermark通常取決于需求,對(duì)于數(shù)據(jù)點(diǎn)數(shù)量級(jí)比較穩(wěn)定的場(chǎng)景,可以設(shè)置一個(gè)到達(dá)的數(shù)據(jù)點(diǎn)的比例,在某一個(gè)判斷周期內(nèi),只要到達(dá)的數(shù)據(jù)點(diǎn)比例滿足閾值則可添加Watermark。主流開(kāi)源計(jì)算框架對(duì)Watermark的實(shí)際定義不盡相同,具體使用參考對(duì)應(yīng)計(jì)算框架的定義。
私以為Watermark機(jī)制隱含的一個(gè)重要思想是將數(shù)據(jù)準(zhǔn)確性的定義交還給用戶,讓用戶決定。產(chǎn)品或者架構(gòu)上的功能,存在多種方案的情況下,選擇最泛化的那個(gè)方案,暴露出參數(shù)然后讓用戶來(lái)選擇,不要自己替用戶做決定。當(dāng)然為了簡(jiǎn)化實(shí)現(xiàn)成本和用戶使用成本,可以設(shè)置固定的一些選項(xiàng),并選擇一個(gè)需求最大的作為默認(rèn)值。
通常Watermark之后的過(guò)期數(shù)據(jù)點(diǎn)會(huì)被丟棄。經(jīng)常的,除了滿足高時(shí)效性需求外,我們也需要在之后保證數(shù)據(jù)的最終準(zhǔn)確性,即在一定時(shí)間段之后的數(shù)據(jù)是準(zhǔn)確的。常用思路是部署兩套計(jì)算系統(tǒng),流式計(jì)算用以實(shí)現(xiàn)低延遲但是準(zhǔn)確性低的需求,批量計(jì)算用于補(bǔ)償計(jì)算數(shù)據(jù)的準(zhǔn)確性,這就是Lambda架構(gòu)。最典型的使用Lambda架構(gòu)的場(chǎng)景是從日志中統(tǒng)計(jì)PV/UV,通常是一個(gè)流式采集系統(tǒng)和流式計(jì)算框架進(jìn)行實(shí)時(shí)的PV/UV計(jì)算,同時(shí)有一套離線系統(tǒng),定期拉取原始日志,通過(guò)批量計(jì)算系統(tǒng)統(tǒng)計(jì)準(zhǔn)確的PV/UV數(shù)值。通常這種架構(gòu)的缺點(diǎn)是兩套系統(tǒng)的資源消耗,開(kāi)發(fā)運(yùn)維成本高。
當(dāng)前主流計(jì)算框架如Spark和Flink對(duì)流式和批量計(jì)算進(jìn)行了統(tǒng)一抽象。可以一定程度降低兩套系統(tǒng)的開(kāi)發(fā)運(yùn)維成本,降低了不同框架的開(kāi)發(fā)運(yùn)維成本,兩次計(jì)算的的資源消耗依舊存在。
對(duì)于滿足交換率和結(jié)合率的算子,如常見(jiàn)的統(tǒng)計(jì)方法(MAX/MIN/SUM/COUNT),在存儲(chǔ)側(cè)支持相同運(yùn)算的情況下,可以將兩次運(yùn)算合并成一次。我們內(nèi)部稱這個(gè)方案為多版本,即數(shù)據(jù)生產(chǎn)一部分就匯聚一部分,每次匯聚產(chǎn)生一個(gè)數(shù)據(jù)版本,由存儲(chǔ)在寫(xiě)入時(shí)合并,或者在查詢時(shí)合并。本質(zhì)上,這是將匯聚的功能遷移了一部分至存儲(chǔ)。
百度監(jiān)控實(shí)時(shí)計(jì)算系統(tǒng)架構(gòu)
百度監(jiān)控系統(tǒng)的實(shí)時(shí)計(jì)算系統(tǒng)承擔(dān)了監(jiān)控系統(tǒng)數(shù)據(jù)處理?xiàng)5闹饕?jì)算功能,每天處理數(shù)千億條消息。本節(jié)在實(shí)際系統(tǒng)的基礎(chǔ)上,進(jìn)行了一定的抽象,介紹一個(gè)較為通用的系統(tǒng)架構(gòu)。
如圖所示,架構(gòu)主要包含以下組件:
接入模塊:包括數(shù)據(jù)拉取和數(shù)據(jù)接收,前者主動(dòng)拉取數(shù)據(jù),后者接收由上游模塊推送的數(shù)據(jù)。
分發(fā)模塊:根據(jù)配置的計(jì)算規(guī)則,過(guò)濾訂閱的數(shù)據(jù),并根據(jù)調(diào)度策略、集群狀態(tài)將規(guī)則對(duì)應(yīng)的數(shù)據(jù)分配到一個(gè)或多個(gè)處理單元進(jìn)行計(jì)算。
處理單元:包括一個(gè)物理計(jì)算模塊和對(duì)應(yīng)的輸入輸出消息隊(duì)列。物理計(jì)算模塊執(zhí)行實(shí)際的業(yè)務(wù)計(jì)算邏輯,不同處理單元間可以是同構(gòu)的也可以是異構(gòu)的,根據(jù)不同的業(yè)務(wù)場(chǎng)景和用戶需求,可以使用不同的技術(shù)棧。
控制模塊:接收用戶提交的計(jì)算規(guī)則和管理操作,分配調(diào)度資源,產(chǎn)生對(duì)其他模塊的控制信息。
數(shù)據(jù)推送模塊:拉取計(jì)算結(jié)果,根據(jù)計(jì)算規(guī)則將數(shù)據(jù)分發(fā)到下游模塊。
每個(gè)物理計(jì)算模塊都對(duì)應(yīng)一個(gè)輸入和輸出消息隊(duì)列,以將數(shù)據(jù)接入、據(jù)輸出與計(jì)算層隔離,增加一個(gè)新的第三方系統(tǒng)的交互不會(huì)影響計(jì)算功能。升級(jí)變更物理框架不會(huì)影響其他組件。
由于大數(shù)據(jù)處理框架,在其數(shù)據(jù)規(guī)模、節(jié)點(diǎn)數(shù)目達(dá)到一定規(guī)模時(shí),其處理性能以及異常恢復(fù)速度都會(huì)下降。我們將一個(gè)固定計(jì)算能力以及配套的資源(如消息隊(duì)列)抽象為一個(gè)處理單元,每個(gè)處理單元處理一部分的數(shù)據(jù),取決于計(jì)算功能的物理實(shí)現(xiàn),這個(gè)處理單元可以對(duì)應(yīng)一個(gè)集群或者一個(gè)作業(yè)。一個(gè)處理單元的具體規(guī)模取決于具體的技術(shù)選型和硬件條件。確認(rèn)處理單元的好處是便于容量規(guī)劃,可以以一個(gè)處理單元作為粒度進(jìn)行擴(kuò)縮容。如果需要嫌粒度過(guò)大,分層次進(jìn)行擴(kuò)縮容,先在一個(gè)處理單元內(nèi)部擴(kuò)展直到極限,之后啟動(dòng)一個(gè)新的處理單元。
實(shí)現(xiàn)中需要考慮以下幾個(gè)點(diǎn):
1、負(fù)載均衡
負(fù)載均衡發(fā)生在系統(tǒng)的每一個(gè)層次。
數(shù)據(jù)接入層與和分發(fā)模塊之間的采用隨機(jī)發(fā)送的策略以均衡分發(fā)模塊的壓力。
數(shù)據(jù)拉取和數(shù)據(jù)推送模塊需要?jiǎng)討B(tài)平衡每個(gè)實(shí)例上的拉取或推送任務(wù),常用的策略是一致性哈希,以每個(gè)任務(wù)的實(shí)際數(shù)據(jù)量作為權(quán)重。
計(jì)算過(guò)程是最需要考慮負(fù)載均衡的場(chǎng)景,聚合計(jì)算通常會(huì)遭遇數(shù)據(jù)傾斜問(wèn)題,即某些key的數(shù)據(jù)量遠(yuǎn)大于其他,這就造成匯聚該Key的任務(wù)OOM。下面提供幾種常用解決思路:
對(duì)于滿足交換率和結(jié)合率的計(jì)算方法,如MAX/MIN/SUM/COUNT等,可以添加多層預(yù)聚合,降低最終聚合的數(shù)據(jù)量。預(yù)聚合層次間可以隨機(jī)方式,最終匯聚之前按Key哈希。
負(fù)載均衡或者說(shuō)任務(wù)調(diào)度對(duì)應(yīng)Bin Packing等一系列等價(jià)的最優(yōu)化問(wèn)題。這些問(wèn)題是NP-Hard的,可以通過(guò)近似算法來(lái)逼近,典型的有First Fit算法。實(shí)現(xiàn)時(shí)一般需要自定義計(jì)算框架的分區(qū)邏輯,如Spark可以通過(guò)自定義Partitioner來(lái)實(shí)現(xiàn)。
2、控制節(jié)點(diǎn)扇入扇出規(guī)模
無(wú)論是具備狀態(tài)副本的分布式存儲(chǔ)系統(tǒng)、基于DAG的分布式計(jì)算系統(tǒng)還是Stateless的接入集群,當(dāng)集群規(guī)模持續(xù)增大時(shí),節(jié)點(diǎn)間交互會(huì)顯著增大,最差的情況下全連接,擴(kuò)容節(jié)點(diǎn)會(huì)有指數(shù)級(jí)的連接增長(zhǎng)。這會(huì)嚴(yán)重影響系統(tǒng)對(duì)水平擴(kuò)容能力,擴(kuò)容帶來(lái)的收益跟不上單機(jī)資源消耗的增長(zhǎng)。
對(duì)于分布式系統(tǒng),通過(guò)控制集群或者作業(yè)規(guī)模可以實(shí)現(xiàn)一定程度的控制,對(duì)于接入模塊,可以限制下游連接到上限。
可用性
對(duì)于可用性要求高的服務(wù)可以多集群熱備的方式,在上述架構(gòu)中,可以通過(guò)運(yùn)行多個(gè)并行的處理單元處理相同的數(shù)據(jù)流來(lái)實(shí)現(xiàn)。也可以部署整個(gè)集群,通過(guò)采集端多寫(xiě)的方式復(fù)制數(shù)據(jù)流。最后需要根據(jù)輸出結(jié)果的延遲、準(zhǔn)確度等判斷策略選擇一個(gè)計(jì)算結(jié)果輸出。
服務(wù)無(wú)損升級(jí),可以通過(guò)啟動(dòng)一個(gè)新的計(jì)算單元,并行處理數(shù)據(jù),待數(shù)據(jù)“預(yù)熱”后,進(jìn)行切換。
在部署時(shí),接入模塊盡可能的靠近數(shù)據(jù)源,保證每個(gè)地域一套。系統(tǒng)多地域部署,每個(gè)地域內(nèi)部模塊間盡量自治。接入端發(fā)送數(shù)據(jù)時(shí)優(yōu)先發(fā)送本地域,異常時(shí)嘗試其他地域。模塊間交互可以打QoS(服務(wù)質(zhì)量)標(biāo)簽增加網(wǎng)絡(luò)優(yōu)先級(jí)以降低網(wǎng)絡(luò)丟包。
監(jiān)控上,除了基礎(chǔ)資源、流量等監(jiān)控外,最重要的是全通路時(shí)延監(jiān)控,常見(jiàn)方案是構(gòu)造業(yè)務(wù)流量,統(tǒng)計(jì)在系統(tǒng)中的延遲。這個(gè)延遲指標(biāo)通常是多維度的,根據(jù)部署和業(yè)務(wù)使用情況可能需要關(guān)注不同地域,不同業(yè)務(wù),不同處理通路的延遲。這些延遲指標(biāo),可以指示系統(tǒng)進(jìn)行流量調(diào)度或者資源的重分配。
總 結(jié)
本文簡(jiǎn)單介紹了百度的分布式監(jiān)控計(jì)算系統(tǒng)架構(gòu)的演進(jìn)和當(dāng)前的實(shí)時(shí)計(jì)算架構(gòu),并提供了部分常見(jiàn)問(wèn)題點(diǎn)解決思路。架構(gòu)是不斷在演進(jìn)的,我們的系統(tǒng)僅僅是“夠用”,還有更多的工作需要開(kāi)展,如架構(gòu)的輕量化,統(tǒng)一易用的計(jì)算表示層,計(jì)算的自動(dòng)優(yōu)化等。
由于個(gè)人水平有限,如果行文中有錯(cuò)誤,或者有需要進(jìn)一步探討的,請(qǐng)?jiān)诹粞灾兄赋觥?/p>
總結(jié)
以上是生活随笔為你收集整理的ccf 智能运维 裴丹_智能运维 聊一聊实时计算系统的全部?jī)?nèi)容,希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇: ffmpeg-win32-v3.2.4
- 下一篇: c语言逆波兰计算器程序,C语言实现的简单