本文是我在實時數(shù)據(jù)計算系統(tǒng)的設(shè)計、開發(fā)、運維生涯的一部分經(jīng)驗總結(jié)。主要介紹一些設(shè)計思路和常見問題的解決方案，不關(guān)注具體計算框架的使用。

本人主要致力于監(jiān)控系統(tǒng)數(shù)據(jù)計算方向，主要業(yè)務(wù)場景有：監(jiān)控數(shù)據(jù)的ETL、數(shù)據(jù)匯聚、分析、異常檢測等。

由于監(jiān)控系統(tǒng)對時效性有較高需求，所以我們的計算系統(tǒng)更偏向?qū)崟r系統(tǒng)，根據(jù)業(yè)務(wù)場景的不同，延遲從數(shù)百毫秒到分鐘不等。下文提到的計算架構(gòu)更多是指整個計算處理通路，主要以監(jiān)控場景下的系統(tǒng)設(shè)計為例，相信與其他場景下的架構(gòu)也有相通之處。

文章從以下幾個方面展開：

首先，在第1節(jié)，我們簡述不同數(shù)據(jù)規(guī)模和場景下，監(jiān)控系統(tǒng)計算架構(gòu)的可選方案。在公司、業(yè)務(wù)發(fā)展的不同階段，主要矛盾不同，能夠投入人力物力資源不同，需要選擇合適的架構(gòu)方案。

實時計算系統(tǒng)的設(shè)計有一個核心問題：如何同時滿足高時效性和數(shù)據(jù)準確性？在現(xiàn)實環(huán)境中，高時效性和準確性很難同時達到，第2節(jié)中介紹了Watermark機制以實現(xiàn)兩者的平衡。

第3節(jié)介紹百度監(jiān)控系統(tǒng)的實時計算系統(tǒng)架構(gòu)，描述了其基本組成、思路和實現(xiàn)中一些常見問題的解決方案。

最后，簡單討論了實時計算系統(tǒng)可用性建設(shè)。

監(jiān)控系統(tǒng)計算架構(gòu)選型

對于包含數(shù)百到千級別節(jié)點的小集群，數(shù)據(jù)規(guī)模有限，所有采集、存儲、計算邏輯都可以集成在一個模塊中實現(xiàn)，這種多為領(lǐng)域?qū)Ｓ孟到y(tǒng)。監(jiān)控系統(tǒng)中，典型的有Prometheus，其采用單服務(wù)節(jié)點架構(gòu)，提供簡單的HA模式進行容錯，這種架構(gòu)的優(yōu)點是部署使用簡單。受限于單機資源，適合部署自治的多個實例，每個實例監(jiān)控不同服務(wù)。大規(guī)模集群情況下，要實現(xiàn)全局的監(jiān)控，需要合并多個監(jiān)控實例的數(shù)據(jù)，在配置分發(fā)、可用性、容錯、自動化部署管理等方面都需要更多的工作。從開發(fā)角度考慮，由于功能耦合嚴重，不利于開發(fā)升級。

比起領(lǐng)域?qū)Ｓ孟到y(tǒng)，還有一種架構(gòu)是使用通用性更強的OLAP系統(tǒng)來實現(xiàn)實時或者近實時的計算功能，如TSDB、ElasticSearch等系統(tǒng)都有一定的聚合計算能力。這些分布式系統(tǒng)都有水平擴展能力和容錯能力，但難以實現(xiàn)復(fù)雜業(yè)務(wù)計算，同時延遲不可控，復(fù)雜查詢或大批量數(shù)據(jù)查詢的延遲可能會達到分鐘級別。

更多的情況下我們采用存儲計算分離的方案，以便存儲和計算的各自演進和平臺化。通常由一個提供精細查詢能力的存儲服務(wù)與一個計算模塊組成。計算模塊根據(jù)計算規(guī)則從存儲系統(tǒng)中拉取數(shù)據(jù)并進行計算，這個架構(gòu)的瓶頸在于存儲系統(tǒng)能夠支持的查詢規(guī)模。根據(jù)我們的經(jīng)驗，基于精心設(shè)計的內(nèi)存數(shù)據(jù)庫集群，能夠承受百萬級別的并發(fā)查詢。這種架構(gòu)下計算任務(wù)多為周期性調(diào)度，當查詢性能下降時會造成任務(wù)的堆積。這個模型不方便處理延遲數(shù)據(jù)，需要一定機制預(yù)測數(shù)據(jù)完整時間，調(diào)度任務(wù)進行重算，任務(wù)調(diào)度的復(fù)雜度高。基于索引查詢的計算系統(tǒng)的延遲取決于計算輪詢的周期，適用于聚合類的涉及時間窗口的運算操作。

在更高數(shù)據(jù)量和計算規(guī)則的情況下，流式計算是一個自然的選擇，降低了寫存儲、索引、查詢的消耗，計算延遲大幅降低。

當數(shù)據(jù)量進一步上升，需要的網(wǎng)絡(luò)吞吐、計算能力驟增，后端的算力難以跟上數(shù)據(jù)量的增長。這時候可以將計算能力分散到全鏈路，將計算提前到數(shù)據(jù)產(chǎn)生端。在監(jiān)控系統(tǒng)中，通過在采集端進行預(yù)計算和ETL操作，提取或整合有用信息，對于實時日志采集，能大幅度降低傳輸?shù)胶蠖说臄?shù)據(jù)量。放到更大的視角上，這種將算力下放到數(shù)據(jù)源的思想，是目前大熱的邊緣計算的一個主要思路。

近年來，Serverless計算架構(gòu)得到了更多的重視。這個模型將計算抽象為事件以及觸發(fā)的計算邏輯，計算邏輯實際由框架調(diào)度、分配資源執(zhí)行。用戶只需要編寫計算邏輯，而不用關(guān)心可用性、可擴展、負載均衡等后端代碼，極大的降低了開發(fā)成本。通過按需調(diào)度，自動擴縮容，業(yè)務(wù)運維方不再關(guān)心容量規(guī)劃等問題。私以為當前常見計算框架的Serverless化是一個值得嘗試的方向。目前的Serverless框架還存在很多問題，例如調(diào)度初始化虛機、容器的成本高，缺乏狀態(tài)存儲等，比較適用于無狀態(tài)的計算。

一般來說根據(jù)場景需求，通常對不同的架構(gòu)會組合使用。例如百度監(jiān)控系統(tǒng)內(nèi)部是以流式計算與近線計算相結(jié)合的方式提供服務(wù)的，近線計算從時序數(shù)據(jù)庫(TSDB)中拉取數(shù)據(jù)進行計算。對于Trace、在線數(shù)據(jù)分析等具有比較復(fù)雜查詢需求但是相對比較低頻的操作，更適合基于索引查詢的架構(gòu)。

準確性與時效性

對于實時系統(tǒng)，我們對時效性有更嚴格的需求，但是通常高時效性伴隨著低準確度，二者不可兼得。在分布式環(huán)境下，天然存在長尾的延遲數(shù)據(jù)，這可能是原始數(shù)據(jù)自身的延遲，也可能是由采集點異常、網(wǎng)絡(luò)延遲、網(wǎng)絡(luò)抖動、數(shù)據(jù)通路中負載等造成的延遲。數(shù)據(jù)源越多，分散的越廣，這個長尾效應(yīng)就會越嚴重，等待數(shù)據(jù)完整所需要的時間也越長。我們需要在最終數(shù)據(jù)的準確性和時效性間做折中。

不同場景對兩者的需求不一致，通常來說報警、自動止損等操作需要最高的時效性，能夠容忍一定的精度缺失，在審計、訂單等數(shù)據(jù)上我們更多的追求準確性，時效性可以適當放寬。解決這個折衷的常用機制是Watermark。

Watermark是在數(shù)據(jù)流中增加標志信息，用以指示一個窗口內(nèi)的數(shù)據(jù)已經(jīng)“完全”到達，可以進行計算。

示例：

假設(shè)我們要統(tǒng)計10s內(nèi)到達的事件數(shù)目，以事件時間(Event Time，即事件攜帶的時間，多為事件產(chǎn)生時間)作為時間基準。如下圖所示，橫線為Wall Time時間線，單位為s。圓球表示事件，圓球里面的數(shù)字為事件時間，其虛線指向產(chǎn)生時間，圓球正對的Wall Time時間線上的點為被計算系統(tǒng)處理的時間(Process Time)，兩個時間之間的差值為實際延遲。每個事件都或多或少存在延遲，其中數(shù)字為45的圓球延遲最大。對于事件時間[40, 50]這個匯聚窗口，假設(shè)我們將Watermark線畫在53處，則我們認為數(shù)據(jù)在53之前已經(jīng)完全到達，已經(jīng)接收到的那些數(shù)據(jù)可以參與匯聚，Watermark之后到來的事件則忽略。

具體怎么確定Watermark通常取決于需求，對于數(shù)據(jù)點數(shù)量級比較穩(wěn)定的場景，可以設(shè)置一個到達的數(shù)據(jù)點的比例，在某一個判斷周期內(nèi)，只要到達的數(shù)據(jù)點比例滿足閾值則可添加Watermark。主流開源計算框架對Watermark的實際定義不盡相同，具體使用參考對應(yīng)計算框架的定義。

私以為Watermark機制隱含的一個重要思想是將數(shù)據(jù)準確性的定義交還給用戶，讓用戶決定。產(chǎn)品或者架構(gòu)上的功能，存在多種方案的情況下，選擇最泛化的那個方案，暴露出參數(shù)然后讓用戶來選擇，不要自己替用戶做決定。當然為了簡化實現(xiàn)成本和用戶使用成本，可以設(shè)置固定的一些選項，并選擇一個需求最大的作為默認值。

通常Watermark之后的過期數(shù)據(jù)點會被丟棄。經(jīng)常的，除了滿足高時效性需求外，我們也需要在之后保證數(shù)據(jù)的最終準確性，即在一定時間段之后的數(shù)據(jù)是準確的。常用思路是部署兩套計算系統(tǒng)，流式計算用以實現(xiàn)低延遲但是準確性低的需求，批量計算用于補償計算數(shù)據(jù)的準確性，這就是Lambda架構(gòu)。最典型的使用Lambda架構(gòu)的場景是從日志中統(tǒng)計PV/UV，通常是一個流式采集系統(tǒng)和流式計算框架進行實時的PV/UV計算，同時有一套離線系統(tǒng)，定期拉取原始日志，通過批量計算系統(tǒng)統(tǒng)計準確的PV/UV數(shù)值。通常這種架構(gòu)的缺點是兩套系統(tǒng)的資源消耗，開發(fā)運維成本高。

當前主流計算框架如Spark和Flink對流式和批量計算進行了統(tǒng)一抽象。可以一定程度降低兩套系統(tǒng)的開發(fā)運維成本，降低了不同框架的開發(fā)運維成本，兩次計算的的資源消耗依舊存在。

對于滿足交換率和結(jié)合率的算子，如常見的統(tǒng)計方法(MAX/MIN/SUM/COUNT)，在存儲側(cè)支持相同運算的情況下，可以將兩次運算合并成一次。我們內(nèi)部稱這個方案為多版本，即數(shù)據(jù)生產(chǎn)一部分就匯聚一部分，每次匯聚產(chǎn)生一個數(shù)據(jù)版本，由存儲在寫入時合并，或者在查詢時合并。本質(zhì)上，這是將匯聚的功能遷移了一部分至存儲。

百度監(jiān)控實時計算系統(tǒng)架構(gòu)

百度監(jiān)控系統(tǒng)的實時計算系統(tǒng)承擔了監(jiān)控系統(tǒng)數(shù)據(jù)處理棧的主要計算功能，每天處理數(shù)千億條消息。本節(jié)在實際系統(tǒng)的基礎(chǔ)上，進行了一定的抽象，介紹一個較為通用的系統(tǒng)架構(gòu)。

如圖所示，架構(gòu)主要包含以下組件：

接入模塊：包括數(shù)據(jù)拉取和數(shù)據(jù)接收，前者主動拉取數(shù)據(jù)，后者接收由上游模塊推送的數(shù)據(jù)。

分發(fā)模塊：根據(jù)配置的計算規(guī)則，過濾訂閱的數(shù)據(jù)，并根據(jù)調(diào)度策略、集群狀態(tài)將規(guī)則對應(yīng)的數(shù)據(jù)分配到一個或多個處理單元進行計算。

處理單元：包括一個物理計算模塊和對應(yīng)的輸入輸出消息隊列。物理計算模塊執(zhí)行實際的業(yè)務(wù)計算邏輯，不同處理單元間可以是同構(gòu)的也可以是異構(gòu)的，根據(jù)不同的業(yè)務(wù)場景和用戶需求，可以使用不同的技術(shù)棧。

控制模塊：接收用戶提交的計算規(guī)則和管理操作，分配調(diào)度資源，產(chǎn)生對其他模塊的控制信息。

數(shù)據(jù)推送模塊：拉取計算結(jié)果，根據(jù)計算規(guī)則將數(shù)據(jù)分發(fā)到下游模塊。

每個物理計算模塊都對應(yīng)一個輸入和輸出消息隊列，以將數(shù)據(jù)接入、據(jù)輸出與計算層隔離，增加一個新的第三方系統(tǒng)的交互不會影響計算功能。升級變更物理框架不會影響其他組件。

由于大數(shù)據(jù)處理框架，在其數(shù)據(jù)規(guī)模、節(jié)點數(shù)目達到一定規(guī)模時，其處理性能以及異常恢復(fù)速度都會下降。我們將一個固定計算能力以及配套的資源(如消息隊列)抽象為一個處理單元，每個處理單元處理一部分的數(shù)據(jù)，取決于計算功能的物理實現(xiàn)，這個處理單元可以對應(yīng)一個集群或者一個作業(yè)。一個處理單元的具體規(guī)模取決于具體的技術(shù)選型和硬件條件。確認處理單元的好處是便于容量規(guī)劃，可以以一個處理單元作為粒度進行擴縮容。如果需要嫌粒度過大，分層次進行擴縮容，先在一個處理單元內(nèi)部擴展直到極限，之后啟動一個新的處理單元。

實現(xiàn)中需要考慮以下幾個點：

1、負載均衡

負載均衡發(fā)生在系統(tǒng)的每一個層次。

數(shù)據(jù)接入層與和分發(fā)模塊之間的采用隨機發(fā)送的策略以均衡分發(fā)模塊的壓力。

數(shù)據(jù)拉取和數(shù)據(jù)推送模塊需要動態(tài)平衡每個實例上的拉取或推送任務(wù)，常用的策略是一致性哈希，以每個任務(wù)的實際數(shù)據(jù)量作為權(quán)重。

計算過程是最需要考慮負載均衡的場景，聚合計算通常會遭遇數(shù)據(jù)傾斜問題，即某些key的數(shù)據(jù)量遠大于其他，這就造成匯聚該Key的任務(wù)OOM。下面提供幾種常用解決思路：

對于滿足交換率和結(jié)合率的計算方法，如MAX/MIN/SUM/COUNT等，可以添加多層預(yù)聚合，降低最終聚合的數(shù)據(jù)量。預(yù)聚合層次間可以隨機方式，最終匯聚之前按Key哈希。

負載均衡或者說任務(wù)調(diào)度對應(yīng)Bin Packing等一系列等價的最優(yōu)化問題。這些問題是NP-Hard的，可以通過近似算法來逼近，典型的有First Fit算法。實現(xiàn)時一般需要自定義計算框架的分區(qū)邏輯，如Spark可以通過自定義Partitioner來實現(xiàn)。

2、控制節(jié)點扇入扇出規(guī)模

無論是具備狀態(tài)副本的分布式存儲系統(tǒng)、基于DAG的分布式計算系統(tǒng)還是Stateless的接入集群，當集群規(guī)模持續(xù)增大時，節(jié)點間交互會顯著增大，最差的情況下全連接，擴容節(jié)點會有指數(shù)級的連接增長。這會嚴重影響系統(tǒng)對水平擴容能力，擴容帶來的收益跟不上單機資源消耗的增長。

對于分布式系統(tǒng)，通過控制集群或者作業(yè)規(guī)模可以實現(xiàn)一定程度的控制，對于接入模塊，可以限制下游連接到上限。

可用性

對于可用性要求高的服務(wù)可以多集群熱備的方式，在上述架構(gòu)中，可以通過運行多個并行的處理單元處理相同的數(shù)據(jù)流來實現(xiàn)。也可以部署整個集群，通過采集端多寫的方式復(fù)制數(shù)據(jù)流。最后需要根據(jù)輸出結(jié)果的延遲、準確度等判斷策略選擇一個計算結(jié)果輸出。

服務(wù)無損升級，可以通過啟動一個新的計算單元，并行處理數(shù)據(jù)，待數(shù)據(jù)“預(yù)熱”后，進行切換。

在部署時，接入模塊盡可能的靠近數(shù)據(jù)源，保證每個地域一套。系統(tǒng)多地域部署，每個地域內(nèi)部模塊間盡量自治。接入端發(fā)送數(shù)據(jù)時優(yōu)先發(fā)送本地域，異常時嘗試其他地域。模塊間交互可以打QoS(服務(wù)質(zhì)量)標簽增加網(wǎng)絡(luò)優(yōu)先級以降低網(wǎng)絡(luò)丟包。

監(jiān)控上，除了基礎(chǔ)資源、流量等監(jiān)控外，最重要的是全通路時延監(jiān)控，常見方案是構(gòu)造業(yè)務(wù)流量，統(tǒng)計在系統(tǒng)中的延遲。這個延遲指標通常是多維度的，根據(jù)部署和業(yè)務(wù)使用情況可能需要關(guān)注不同地域，不同業(yè)務(wù)，不同處理通路的延遲。這些延遲指標，可以指示系統(tǒng)進行流量調(diào)度或者資源的重分配。

總 結(jié)

本文簡單介紹了百度的分布式監(jiān)控計算系統(tǒng)架構(gòu)的演進和當前的實時計算架構(gòu)，并提供了部分常見問題點解決思路。架構(gòu)是不斷在演進的，我們的系統(tǒng)僅僅是“夠用”，還有更多的工作需要開展，如架構(gòu)的輕量化，統(tǒng)一易用的計算表示層，計算的自動優(yōu)化等。

由于個人水平有限，如果行文中有錯誤，或者有需要進一步探討的，請在留言中指出。

總結(jié)

以上是生活随笔為你收集整理的ccf 智能运维 裴丹_智能运维 聊一聊实时计算系统的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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