0.摘要

需要實(shí)時(shí)處理大量數(shù)據(jù)流的應(yīng)用正在推動(dòng)傳統(tǒng)數(shù)據(jù)處理基礎(chǔ)設(shè)施的極限。這些基于流的應(yīng)用包括華爾街的市場(chǎng)資訊處理和電子交易、網(wǎng)絡(luò)和基礎(chǔ)設(shè)施監(jiān)控、欺詐檢測(cè)以及軍事環(huán)境中的指揮和控制。此外，隨著廉價(jià)微型傳感器技術(shù)所帶來的“巨變”逐漸到來，我們預(yù)計(jì)會(huì)看到地球上所有有意義的物質(zhì)都被“傳感器標(biāo)記”，并實(shí)時(shí)報(bào)告其狀態(tài)或位置。這種對(duì)實(shí)際世界的傳感器化將引領(lǐng)一片“綠地”，涌現(xiàn)出具有大容量和低延遲處理要求的新型監(jiān)測(cè)和控制應(yīng)用。

最近，出現(xiàn)了幾種技術(shù)，包括現(xiàn)成的流處理引擎，專門解決高容量、實(shí)時(shí)數(shù)據(jù)處理的挑戰(zhàn)，而無需使用自定義代碼。同時(shí)，一些現(xiàn)有的軟件技術(shù)，如數(shù)據(jù)庫(kù)管理系統(tǒng)和規(guī)則引擎，也被營(yíng)銷部門“重新定位”，以解決這些應(yīng)用的問題。

在本文中，我們概述了一個(gè)系統(tǒng)應(yīng)該滿足的八個(gè)要求，以在各種實(shí)時(shí)流處理應(yīng)用中表現(xiàn)出色。我們的目標(biāo)是為信息技術(shù)人員提供高級(jí)別的指導(dǎo)，讓他們知道在評(píng)估備選流處理解決方案時(shí)該關(guān)注什么。因此，本文的目的類似于關(guān)系型數(shù)據(jù)庫(kù)管理系統(tǒng)和在線分析處理的需求文檔。在我們的要求框架下，我們還簡(jiǎn)要回顧了替代軟件技術(shù)。本文試圖保持中立，因此沒有提及任何具體的商業(yè)產(chǎn)品。

1. 簡(jiǎn)介

在華爾街和其他全球交易所，電子交易量呈指數(shù)級(jí)增長(zhǎng)。市場(chǎng)數(shù)據(jù)源可以每秒生成數(shù)萬條消息。Options Price Reporting Authority（OPRA）匯總所有期權(quán)交易所的報(bào)價(jià)和交易，估計(jì)2005年峰值速率為每秒122,000條消息，并以每年翻倍的速度增長(zhǎng)。這種龐大的流量增加正在壓力或破壞傳統(tǒng)的資訊處理系統(tǒng)。此外，在電子交易中，即使延遲一秒鐘也是不可接受的，而引擎產(chǎn)生最新結(jié)果的交易操作將最大化套利利潤(rùn)。這個(gè)事實(shí)導(dǎo)致金融服務(wù)公司要求非常高容量的資訊處理，同時(shí)具有非常低的延遲。

在監(jiān)控計(jì)算機(jī)網(wǎng)絡(luò)的拒絕服務(wù)和其他安全攻擊方面也存在類似的要求。從金融服務(wù)網(wǎng)絡(luò)到手機(jī)網(wǎng)絡(luò)的實(shí)時(shí)欺詐檢測(cè)表現(xiàn)出類似的特征。隨著時(shí)間的推移，工業(yè)設(shè)施的過程控制和自動(dòng)化，從煉油廠到玉米片工廠，也將轉(zhuǎn)移到這樣的“消防水龍帶”數(shù)據(jù)量和亞秒級(jí)延遲要求。

微傳感器技術(shù)的進(jìn)步正在帶來一種“巨變”。雖然近來RFID技術(shù)獲得了最多的關(guān)注，但還有各種價(jià)格、能力和占地面積不同的其他技術(shù)（例如mote和Lojack）。隨著時(shí)間的推移，這種巨變將導(dǎo)致所有具有物質(zhì)意義的物體都被傳感器標(biāo)記以實(shí)時(shí)報(bào)告其位置和/或狀態(tài)。

軍隊(duì)一直是無線傳感器網(wǎng)絡(luò)技術(shù)的早期推動(dòng)者和采用者。例如，美國(guó)陸軍一直在研究給所有士兵配備生命體征監(jiān)測(cè)器。此外，許多軍用車輛已經(jīng)配備了GPS系統(tǒng)，但尚未連接到閉環(huán)系統(tǒng)中。軍隊(duì)希望利用這項(xiàng)技術(shù)監(jiān)測(cè)所有車輛的位置，并實(shí)時(shí)確定它們是否偏離航線。

基于其他傳感器的監(jiān)測(cè)應(yīng)用將逐漸在非軍事領(lǐng)域出現(xiàn)。標(biāo)記將應(yīng)用于游樂園客戶的乘車管理和防止孩子走失。更復(fù)雜的“易通行”系統(tǒng)將允許基于擁堵的高速公路收費(fèi)，同時(shí)優(yōu)化都市地區(qū)的汽車路線。來自現(xiàn)有和新興監(jiān)測(cè)應(yīng)用的“火水管”實(shí)時(shí)數(shù)據(jù)處理提供了一個(gè)重要的流處理挑戰(zhàn)和機(jī)遇。

傳統(tǒng)上，使用定制編碼來解決高容量、低延遲的流處理問題。盡管“自己動(dòng)手”的方法因其缺乏靈活性、高開發(fā)和維護(hù)成本以及對(duì)新功能請(qǐng)求的響應(yīng)時(shí)間慢而普遍受到鄙視，但應(yīng)用程序開發(fā)人員不得不采用這種方法，因?yàn)樗麄冊(cè)趥鹘y(tǒng)現(xiàn)成軟件方面運(yùn)氣不佳。

最近，一些傳統(tǒng)軟件技術(shù)，如數(shù)據(jù)庫(kù)管理系統(tǒng)和規(guī)則引擎，已被重新定位并重新包裝以適應(yīng)這個(gè)應(yīng)用領(lǐng)域。此外，一種新的基礎(chǔ)設(shè)施軟件類別——流處理引擎（例如，Aurora 、STREAM 、TelegraphCQ ）已經(jīng)出現(xiàn)，專門支持高容量、低延遲的流處理應(yīng)用。

在本文中，我們描述了一個(gè)系統(tǒng)必須具備的八個(gè)特性，才能在各種實(shí)時(shí)流處理應(yīng)用程序中表現(xiàn)出色。我們的目標(biāo)是為信息技術(shù)人員提供高層次的指導(dǎo)，以便他們?cè)谠u(píng)估選項(xiàng)時(shí)知道該尋找什么。因此，本文與早期針對(duì)關(guān)系型DBSMs和在線分析處理的需求的論文具有相似的目標(biāo)。

我們?cè)谙乱还?jié)中將這些特性作為八條規(guī)則的集合呈現(xiàn)。然后我們?cè)诘谌?jié)中回顧替代技術(shù)，并總結(jié)它們?cè)趯?shí)時(shí)流處理方面的表現(xiàn)如何。最后，我們?cè)诘谒墓?jié)中做出最后的結(jié)論。

2.八項(xiàng)實(shí)時(shí)流處理規(guī)則

規(guī)則1：保持?jǐn)?shù)據(jù)運(yùn)動(dòng)

為了實(shí)現(xiàn)低延遲，系統(tǒng)必須能夠在關(guān)鍵處理路徑中執(zhí)行消息處理，而不需要進(jìn)行昂貴的存儲(chǔ)操作。存儲(chǔ)操作會(huì)為過程增加大量不必要的延遲（例如，提交數(shù)據(jù)庫(kù)記錄需要寫入日志記錄）。對(duì)于許多流處理應(yīng)用程序來說，要求在消息處理之前執(zhí)行這樣一個(gè)耗時(shí)的操作既不可接受，也不必要。相反，消息應(yīng)該在流中“即時(shí)”處理。請(qǐng)參見下圖，了解這種直通式處理范例的架構(gòu)示意圖。

“直通式”消息處理，可選存儲(chǔ)。

另一個(gè)延遲問題存在于被動(dòng)系統(tǒng)中，這些系統(tǒng)在進(jìn)行處理之前等待應(yīng)用程序告訴它們?cè)撟鍪裁?。被?dòng)系統(tǒng)要求應(yīng)用程序不斷輪詢感興趣的條件。不幸的是，輪詢會(huì)增加系統(tǒng)和應(yīng)用程序的額外開銷，并增加延遲，因?yàn)椋ㄆ骄裕┹喸冮g隔的一半會(huì)加到處理延遲中。主動(dòng)系統(tǒng)通過集成內(nèi)置的事件/數(shù)據(jù)驅(qū)動(dòng)處理能力來避免這種開銷。

實(shí)時(shí)流處理系統(tǒng)的第一個(gè)要求是在流中處理消息，無需將其存儲(chǔ)以執(zhí)行任何操作或操作序列。理想情況下，該系統(tǒng)還應(yīng)使用主動(dòng)（即非輪詢）處理模型。

規(guī)則2：使用SQL在流數(shù)據(jù)上進(jìn)行查詢（StreamSQL）

在流應(yīng)用程序中，必須使用某種查詢機(jī)制來查找感興趣的輸出事件或計(jì)算實(shí)時(shí)分析。歷史上，在流應(yīng)用程序中，通常使用C 或Java等通用語言作為開發(fā)和編程工具。不幸的是，依賴低級(jí)編程方案會(huì)導(dǎo)致長(zhǎng)時(shí)間的開發(fā)周期和高維護(hù)成本。

相比之下，使用高級(jí)語言（如SQL）處理移動(dòng)實(shí)時(shí)數(shù)據(jù)非常理想。 SQL已經(jīng)成為數(shù)據(jù)庫(kù)語言的持久標(biāo)準(zhǔn)超過三十年了。 SQL之所以能成功地表達(dá)復(fù)雜的數(shù)據(jù)轉(zhuǎn)換，是因?yàn)樗谝唤M非常強(qiáng)大的數(shù)據(jù)處理原語，可以進(jìn)行過濾、合并、相關(guān)和聚合。 SQL明確了這些基元如何相互作用，使得它的含義可以獨(dú)立于運(yùn)行時(shí)條件而輕松理解。此外，SQL是一個(gè)廣泛傳播的標(biāo)準(zhǔn)，被數(shù)十萬個(gè)數(shù)據(jù)庫(kù)程序員所理解，并且由目前所有重要的商業(yè)DBMS實(shí)現(xiàn)，由于其功能、強(qiáng)大和相對(duì)易用性的結(jié)合。鑒于全球已經(jīng)安裝和運(yùn)行了數(shù)百萬個(gè)運(yùn)行SQL的關(guān)系數(shù)據(jù)庫(kù)服務(wù)器，因此利用熟悉的SQL查詢模型和運(yùn)算符并簡(jiǎn)單地?cái)U(kuò)展它們以對(duì)連續(xù)數(shù)據(jù)流執(zhí)行處理是很有意義的。通過使用SQL風(fēng)格的構(gòu)造來捕獲應(yīng)用程序邏輯，可以降低編程成本并提高上市時(shí)間。

為了滿足流處理的獨(dú)特需求，需要StreamSQL，這是SQL語言的一種變體，專門設(shè)計(jì)用于處理連續(xù)的數(shù)據(jù)流。StreamSQL應(yīng)該通過添加豐富的窗口構(gòu)造和流特定的運(yùn)算符，擴(kuò)展標(biāo)準(zhǔn)SQL的語義（假定記錄在有限的存儲(chǔ)數(shù)據(jù)集中）。

雖然傳統(tǒng)的SQL系統(tǒng)在到達(dá)表的末尾時(shí)知道它已經(jīng)完成計(jì)算，但是由于流數(shù)據(jù)永遠(yuǎn)不會(huì)結(jié)束，因此流處理引擎必須指示何時(shí)完成此類操作并輸出答案。窗口構(gòu)造通過定義多消息運(yùn)算符（例如聚合或連接）的“范圍”來實(shí)現(xiàn)此目的。

窗口應(yīng)該可以根據(jù)時(shí)間（可能是最常見的用例）、消息數(shù)量或消息中其他屬性的斷點(diǎn)來定義。這樣的窗口應(yīng)該能夠從當(dāng)前窗口滑動(dòng)可變量（例如，一個(gè)窗口可以是五個(gè)時(shí)刻寬度，下一個(gè)窗口可以從當(dāng)前窗口滑動(dòng)一個(gè)時(shí)刻）。因此，根據(jù)窗口大小和滑動(dòng)參數(shù)的選擇，窗口可以是不相交的或重疊的。下圖展示了滑動(dòng)窗口的示例。

窗口定義了操作的范圍。該窗口的大小為5條消息，并且每次執(zhí)行相關(guān)運(yùn)算符時(shí)，該窗口滑動(dòng)1個(gè)。連續(xù)的窗口重疊

此外，需要一些在標(biāo)準(zhǔn)SQL中不存在的新的面向流的操作符。一個(gè)例子是“合并”（Merge）操作符，它以對(duì)數(shù)據(jù)消息的到達(dá)時(shí)間和順序敏感的方式多路復(fù)用來自多個(gè)流的消息。

最后，操作符集必須是可擴(kuò)展的，以便開發(fā)人員可以輕松地在系統(tǒng)內(nèi)實(shí)現(xiàn)新的處理功能（例如，在流數(shù)據(jù)上實(shí)現(xiàn)專有的分析算法）。

第二個(gè)要求是支持具有內(nèi)置可擴(kuò)展流定向基元和運(yùn)算符的高級(jí)“StreamSQL”語言。

規(guī)則三：處理流的缺陷（延遲、丟失和亂序數(shù)據(jù)）

在傳統(tǒng)數(shù)據(jù)庫(kù)中，數(shù)據(jù)在被查詢之前總是存在的，但在實(shí)時(shí)系統(tǒng)中，由于數(shù)據(jù)從未存儲(chǔ)，基礎(chǔ)設(shè)施必須提供處理延遲、丟失或亂序數(shù)據(jù)的功能。

其中一個(gè)要求是能夠超時(shí)單個(gè)計(jì)算或操作。例如，考慮一個(gè)簡(jiǎn)單的實(shí)時(shí)業(yè)務(wù)分析，它計(jì)算25個(gè)證券的最后一個(gè)標(biāo)記的平均價(jià)格。只需要等待每個(gè)證券的標(biāo)記，然后輸出平均價(jià)格。然而，假設(shè)其中一個(gè)25個(gè)股票的交易量較小，并且該股票的標(biāo)記不會(huì)在接下來的10分鐘內(nèi)收到。這是一個(gè)必須阻塞等待輸入完成計(jì)算的計(jì)算示例。這些輸入可能會(huì)及時(shí)到達(dá)，也可能不會(huì)。實(shí)際上，如果證券交易委員會(huì)下令停止交易其中的任何一個(gè)25個(gè)證券之一，則計(jì)算將無限期地阻塞。

在實(shí)時(shí)系統(tǒng)中，讓程序無限期等待從來不是一個(gè)好主意。因此，任何可能阻塞的操作都必須允許超時(shí)，以便應(yīng)用程序可以繼續(xù)處理部分?jǐn)?shù)據(jù)。任何實(shí)時(shí)處理系統(tǒng)必須為任何潛在的阻塞操作設(shè)置這樣的超時(shí)。

處理亂序數(shù)據(jù)引入了類似的挑戰(zhàn)。通常情況下，時(shí)間窗口（例如 [9:00 – 9:01]）會(huì)在收到時(shí)間戳大于窗口關(guān)閉時(shí)間的消息時(shí)關(guān)閉。但是，這種操作假定數(shù)據(jù)按照時(shí)間戳的順序到達(dá)，這并不一定是實(shí)際情況。為了處理亂序數(shù)據(jù)，必須提供一種機(jī)制，允許窗口在額外的時(shí)間內(nèi)保持打開狀態(tài)。在 Aurora 中指定的一種解決方案是“彈性期”的概念。

第三個(gè)需求是具有內(nèi)置機(jī)制來提供對(duì)流“缺陷”的韌性，包括缺失和亂序數(shù)據(jù)，這些通常存在于實(shí)際數(shù)據(jù)流中。

規(guī)則4：產(chǎn)生可預(yù)測(cè)的結(jié)果

流處理系統(tǒng)必須以可預(yù)測(cè)的方式處理時(shí)間序列消息，以確保處理結(jié)果是確定性的和可重復(fù)的。

例如，考慮兩個(gè)數(shù)據(jù)流，一個(gè)包含具有字段的TICKS數(shù)據(jù)：

TICKS (stock_symbol, volume, price, time)

另一個(gè)是SPLITS數(shù)據(jù)流，它指示股票何時(shí)拆分，格式如下：

SPLITS (symbol, time, split_factor)

一個(gè)典型的流處理應(yīng)用是為一組股票生成實(shí)時(shí)的拆分調(diào)整后的價(jià)格。價(jià)格必須根據(jù)已經(jīng)發(fā)生的分割系數(shù)進(jìn)行調(diào)整。只有當(dāng)消息以升序時(shí)間順序被系統(tǒng)處理時(shí)，才能生成正確的答案，而不考慮消息到達(dá)系統(tǒng)的時(shí)間。如果分割消息被無序地處理，則涉及的股票的拆分調(diào)整后的價(jià)格將在一個(gè)或多個(gè)時(shí)間段上是錯(cuò)誤的。請(qǐng)注意，僅在輸入到系統(tǒng)之前對(duì)消息進(jìn)行排序是不足夠的——只有在整個(gè)處理管道中維護(hù)時(shí)間順序和確定性處理，才能保證正確性。

能夠產(chǎn)生可預(yù)測(cè)的結(jié)果也從容錯(cuò)和恢復(fù)的角度非常重要，因?yàn)橹夭ズ椭匦绿幚硐嗤妮斎肓鲬?yīng)該無論執(zhí)行時(shí)間如何都會(huì)產(chǎn)生相同的結(jié)果。

第四個(gè)要求是流處理引擎必須保證可預(yù)測(cè)和可重復(fù)的結(jié)果。

第五條規(guī)則：整合存儲(chǔ)和流數(shù)據(jù)

對(duì)于許多流處理應(yīng)用程序，比較“現(xiàn)在”和“過去”是一項(xiàng)常見任務(wù)。因此，流處理系統(tǒng)必須也提供對(duì)存儲(chǔ)狀態(tài)的仔細(xì)管理。例如，在在線數(shù)據(jù)挖掘應(yīng)用程序（例如檢測(cè)信用卡或其他交易欺詐）中，識(shí)別活動(dòng)是否“不尋?！毙枰谝欢螘r(shí)間內(nèi)收集通常的活動(dòng)模式，將它們匯總為“簽名”，并在實(shí)時(shí)中與當(dāng)前活動(dòng)進(jìn)行比較。為了實(shí)現(xiàn)這個(gè)任務(wù)，歷史數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)需要在同一個(gè)應(yīng)用程序中集成，以進(jìn)行比較。

這個(gè)要求的一個(gè)非常流行的擴(kuò)展來自于具有電子交易應(yīng)用程序的公司，他們想編寫一個(gè)交易算法，然后在歷史數(shù)據(jù)上測(cè)試它，以查看它在其他情況下的表現(xiàn)如何。當(dāng)算法在歷史數(shù)據(jù)上運(yùn)行良好時(shí)，客戶想無縫切換到實(shí)時(shí)數(shù)據(jù)，即在不修改應(yīng)用程序代碼的情況下。

自動(dòng)無縫切換的另一個(gè)原因是希望從過去某個(gè)時(shí)間點(diǎn)（例如兩小時(shí)前）開始計(jì)算某種業(yè)務(wù)分析，趕上實(shí)時(shí)，并在實(shí)時(shí)數(shù)據(jù)上無縫繼續(xù)進(jìn)行計(jì)算。這需要自動(dòng)從歷史數(shù)據(jù)切換到實(shí)時(shí)數(shù)據(jù)，而不需要人為干預(yù)。

對(duì)于低延遲的流數(shù)據(jù)應(yīng)用程序，通過客戶端-服務(wù)器數(shù)據(jù)庫(kù)連接來高效存儲(chǔ)和訪問持久狀態(tài)會(huì)增加過多的延遲和開銷。因此，狀態(tài)必須存儲(chǔ)在與應(yīng)用程序相同的操作系統(tǒng)地址空間中，使用嵌入式數(shù)據(jù)庫(kù)系統(tǒng)。因此，StreamSQL命令的范圍應(yīng)該是實(shí)時(shí)流或嵌入式數(shù)據(jù)庫(kù)系統(tǒng)中的存儲(chǔ)表。

第五個(gè)要求是具備有效地存儲(chǔ)、訪問和修改狀態(tài)信息的能力，并將其與實(shí)時(shí)流數(shù)據(jù)結(jié)合使用。為了實(shí)現(xiàn)無縫集成，系統(tǒng)在處理這兩種類型的數(shù)據(jù)時(shí)應(yīng)使用統(tǒng)一的語言。

規(guī)則6：保證數(shù)據(jù)安全和可用性

為了保護(hù)關(guān)鍵信息的完整性并避免實(shí)時(shí)處理中的中斷，流處理系統(tǒng)必須使用高可用性（HA）解決方案。

高可用性是大多數(shù)流處理應(yīng)用的關(guān)鍵問題。例如，幾乎所有金融服務(wù)公司都希望他們的應(yīng)用程序始終保持運(yùn)行狀態(tài)，無論發(fā)生什么情況。如果發(fā)生故障，應(yīng)用程序需要故障轉(zhuǎn)移至備份硬件并繼續(xù)運(yùn)行。重新啟動(dòng)操作系統(tǒng)并從日志中恢復(fù)應(yīng)用程序會(huì)產(chǎn)生過多的開銷，因此對(duì)于實(shí)時(shí)處理來說是不可接受的。因此，“Tandem-style”熱備份和實(shí)時(shí)故障轉(zhuǎn)移方案 [6]是這些類型應(yīng)用程序的最佳合理替代方案，其中輔助系統(tǒng)定期將其處理狀態(tài)與主系統(tǒng)同步，并在主系統(tǒng)失敗時(shí)接管。該HA模型如圖所示。

“Tandem-style” 熱備份和故障轉(zhuǎn)移可以確保實(shí)時(shí)流處理的高可用性。

第六個(gè)要求是確保應(yīng)用程序在任何時(shí)候都處于運(yùn)行狀態(tài)，數(shù)據(jù)的完整性得以維護(hù)，即使出現(xiàn)故障。

規(guī)則7：自動(dòng)分區(qū)和擴(kuò)展應(yīng)用程序

隨著低成本的通用集群具有有利的性價(jià)比特性，分布式操作變得越來越重要。因此，在處理的輸入流量或處理的復(fù)雜性增加時(shí)，應(yīng)該能夠?qū)?yīng)用程序分割到多臺(tái)計(jì)算機(jī)上實(shí)現(xiàn)可伸縮性，而無需開發(fā)人員編寫底層代碼。

流處理系統(tǒng)還應(yīng)支持多線程操作，以利用現(xiàn)代多處理器（或多核）計(jì)算機(jī)架構(gòu)。即使在單處理器機(jī)器上，也應(yīng)支持多線程操作以避免因外部事件而阻塞，從而促進(jìn)低延遲。

不僅必須輕松地提供可擴(kuò)展性，而且生成的應(yīng)用程序應(yīng)自動(dòng)透明地在可用計(jì)算機(jī)上進(jìn)行負(fù)載平衡，以便應(yīng)用程序不會(huì)被單個(gè)超負(fù)荷計(jì)算機(jī)拖垮。

第七個(gè)要求是具有在多個(gè)處理器和機(jī)器之間分布處理以實(shí)現(xiàn)增量可擴(kuò)展性的能力。理想情況下，分布應(yīng)該是自動(dòng)和透明的。

第八個(gè)規(guī)則是實(shí)時(shí)處理和響應(yīng)

沒有上述規(guī)則單獨(dú)存在時(shí)都不能讓應(yīng)用程序做出任何差異，除非應(yīng)用程序可以“跟得上”，即能夠在COTS硬件上以微秒到毫秒的延遲范圍內(nèi)處理數(shù)萬到數(shù)十萬條流數(shù)據(jù)。

為了實(shí)現(xiàn)如此高的性能，系統(tǒng)應(yīng)該有一個(gè)高度優(yōu)化的執(zhí)行路徑，使得開銷與有用工作的比例最小化。正如前面規(guī)則所示，一個(gè)關(guān)鍵問題是通過將所有關(guān)鍵功能（如處理和存儲(chǔ)）集成到單個(gè)系統(tǒng)進(jìn)程中來最小化“邊界穿越”的數(shù)量。但這本身并不足夠；所有系統(tǒng)組件都需要考慮高性能設(shè)計(jì)。

為確保系統(tǒng)能夠滿足這一要求，任何具有高速流應(yīng)用程序的用戶都必須仔細(xì)測(cè)試他所考慮的任何產(chǎn)品在目標(biāo)工作負(fù)載上的吞吐量和延遲。

第八個(gè)要求是流處理系統(tǒng)必須具備高度優(yōu)化、最小化開銷的執(zhí)行引擎，以滿足高容量應(yīng)用程序的實(shí)時(shí)響應(yīng)需求。

3.軟件技術(shù)與流處理

3.1 基本架構(gòu)

除了自定義編程外，還有至少三種不同的軟件系統(tǒng)技術(shù)可以潛在地應(yīng)用于解決高容量低延遲的流處理問題。它們分別是數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）、規(guī)則引擎和流處理引擎，我們將在下面進(jìn)行討論：

• 數(shù)據(jù)庫(kù)管理系統(tǒng)（DBMS）由于其可靠存儲(chǔ)大型數(shù)據(jù)集和高效處理人工發(fā)起的查詢的能力而被廣泛使用。如果有足夠的主存，主存儲(chǔ)器DBMS可以通過避免大多數(shù)操作使用磁盤來提供比傳統(tǒng)DBMS更高的性能。
  流數(shù)據(jù)直接或通過加載應(yīng)用程序輸入到DBMS中。一組應(yīng)用程序可以操縱DBMS數(shù)據(jù)?？蛻舳丝梢允褂眠@些預(yù)構(gòu)建的應(yīng)用程序，通常帶有運(yùn)行時(shí)參數(shù)，并且還可以使用嵌入式SQL調(diào)用將附加應(yīng)用程序編碼為通用語言，如C 或Java。
• 規(guī)則引擎最早出現(xiàn)在20世紀(jì)70年代，當(dāng)時(shí)人工智能界最初提出了諸如PLANNER和Conniver之類的系統(tǒng)。稍后的更廣泛的規(guī)則引擎是Prolog（1980年代），還有幾個(gè)更近期的例子（例如OPS5 ）。規(guī)則引擎通常接受條件/動(dòng)作對(duì)，通常使用“如果-那么”符號(hào)表示，監(jiān)視輸入流以獲取任何感興趣的條件，然后在滿足條件時(shí)采取適當(dāng)?shù)牟僮?。換句話說，規(guī)則引擎執(zhí)行存儲(chǔ)在規(guī)則庫(kù)中的一組規(guī)則。
  規(guī)則庫(kù)為規(guī)則提供持久存儲(chǔ)。當(dāng)流數(shù)據(jù)進(jìn)入系統(tǒng)時(shí)，它們立即與現(xiàn)有規(guī)則匹配。當(dāng)規(guī)則的條件匹配時(shí)，規(guī)則被稱為“觸發(fā)”。然后采取相應(yīng)的操作可能會(huì)向外部應(yīng)用程序產(chǎn)生警報(bào)/輸出，也可能僅修改內(nèi)部變量的狀態(tài)，這可能會(huì)導(dǎo)致進(jìn)一步的規(guī)則觸發(fā)。
• 流處理引擎(SPEs)專門設(shè)計(jì)用于處理流數(shù)據(jù)，并最近作為第三種選擇受到關(guān)注。它們的基本架構(gòu)如圖所示。SPEs可以像SQL處理一樣處理傳入的消息，而無需必要時(shí)存儲(chǔ)它們。顯然，為了在必要時(shí)存儲(chǔ)狀態(tài)，可以在系統(tǒng)中嵌入傳統(tǒng)的SQL數(shù)據(jù)庫(kù)以提高效率。SPEs使用專用原語和構(gòu)造（例如時(shí)間窗口）來表達(dá)面向流的處理邏輯。

(i) 數(shù)據(jù)庫(kù)系統(tǒng)，(ii) 規(guī)則引擎和 (iii) 流處理引擎的基本架構(gòu)。

接下來，我們將根據(jù)第2節(jié)提出的要求對(duì)這些系統(tǒng)進(jìn)行簡(jiǎn)要評(píng)估。

3.2 它們的優(yōu)缺點(diǎn)如何？

DBMS使用“存儲(chǔ)后處理”模型，輸入數(shù)據(jù)首先存儲(chǔ)，可能被索引，然后再進(jìn)行處理。主存儲(chǔ)DBMS更快，因?yàn)樗鼈兛梢员苊獯蟛糠指虏僮魃婕按疟P，但否則使用相同的基本模型。DBMS是被動(dòng)的，即它們等待應(yīng)用程序告訴它們?cè)撟鍪裁础Ｒ恍〥BMS具有內(nèi)置的觸發(fā)機(jī)制，但眾所周知，觸發(fā)器的可擴(kuò)展性較差。另一方面，規(guī)則引擎和SPE都是主動(dòng)的，并且不需要在處理之前存儲(chǔ)任何數(shù)據(jù)。因此，DBMS不會(huì)使數(shù)據(jù)保持流動(dòng)，而規(guī)則引擎和SPE會(huì)。

SQL是設(shè)計(jì)用于有限大小的存儲(chǔ)數(shù)據(jù)，因此需要擴(kuò)展才能處理潛在的無界時(shí)間序列數(shù)據(jù)流。SQL/Temporal仍處于起步階段，DBMS供應(yīng)商實(shí)現(xiàn)的SQL僅支持窗口操作的基本概念。規(guī)則語言需要類似的擴(kuò)展，以便它們可以表達(dá)對(duì)時(shí)間感興趣的條件。此外，規(guī)則語言還需要聚合的概念，在許多流處理應(yīng)用中都是常見操作。因此，SPE支持對(duì)流進(jìn)行SQL樣式處理，而DBMS和規(guī)則引擎則不支持。

在規(guī)則引擎和SPE中，編寫可能阻塞的操作是可能的，但也很容易支持超時(shí)。在DBMS解決方案中，應(yīng)用程序必須明確指定其輪詢行為以模擬超時(shí)的效果并接收部分?jǐn)?shù)據(jù)。同樣，DBMS觸發(fā)系統(tǒng)沒有明顯的超時(shí)方式。對(duì)于DBMS來說，無序數(shù)據(jù)也存在類似的挑戰(zhàn)?？傮w而言，規(guī)則引擎和SPE相比于DBMS更容易處理流數(shù)據(jù)的不完美性。

為了產(chǎn)生可預(yù)測(cè)的結(jié)果，SPE或規(guī)則引擎必須具有利用輸入消息的時(shí)間戳順序的確定性執(zhí)行模式。DBMS對(duì)這一要求特別困難。ACID事務(wù)提供的同步和正確性保證針對(duì)傳統(tǒng)數(shù)據(jù)庫(kù)應(yīng)用程序的要求，并且單獨(dú)不能確保流處理的可預(yù)測(cè)和確定性執(zhí)行語義。主要原因是DBMS不需要可重復(fù)的執(zhí)行，而是強(qiáng)制實(shí)施較弱的可串行化條件。在沒有任何內(nèi)置正確性標(biāo)準(zhǔn)的情況下，獨(dú)立應(yīng)用程序的執(zhí)行順序必須由某些外部軟件控制，這可能會(huì)對(duì)性能和復(fù)雜性產(chǎn)生不利影響。

無縫地集成存儲(chǔ)和流數(shù)據(jù)對(duì)DBMS和規(guī)則引擎都是問題。存儲(chǔ)狀態(tài)是DBMS自然而然的功能。然而，正如之前所述，DBMS無法很好地處理流數(shù)據(jù)。即使在流應(yīng)用程序中僅用于狀態(tài)存儲(chǔ)，客戶端-服務(wù)器DBMS也將無效，因?yàn)樗鼘a(chǎn)生高延遲和開銷。因此，只有在DBMS可以嵌入應(yīng)用程序時(shí)，DBMS解決方案才是可接受的。

3.3 表格結(jié)果

在表1中，我們總結(jié)了本節(jié)討論的結(jié)果。表中的每個(gè)條目包含以下四個(gè)值之一：

• Yes：架構(gòu)自然支持該功能。
• No：架構(gòu)不支持該功能。
• Possible：架構(gòu)可以支持該功能。應(yīng)檢查供應(yīng)商是否符合要求。
• Difficult：架構(gòu)可以支持該功能，但由于需要進(jìn)行巨大的修改，因此難度較大。應(yīng)檢查供應(yīng)商是否符合要求。

SPEs提供了最好的功能，因?yàn)樗鼈兪菑念^開始設(shè)計(jì)和優(yōu)化以滿足流處理的要求。DBMS和規(guī)則引擎最初是為不同類別的應(yīng)用程序設(shè)計(jì)的，具有不同的基本假設(shè)和要求。因此，這兩個(gè)系統(tǒng)根本上是將流處理“硬塞”到它們自己的模型中。因此，不足為奇地看到它們?cè)谶@個(gè)領(lǐng)域有根本性的局限性。特別是，兩個(gè)系統(tǒng)都無法有效且統(tǒng)一地處理流數(shù)據(jù)和存儲(chǔ)數(shù)據(jù)。

4.結(jié)論

存在大量現(xiàn)有和新興應(yīng)用程序需要對(duì)高容量數(shù)據(jù)流進(jìn)行復(fù)雜的實(shí)時(shí)處理。雖然這些應(yīng)用程序傳統(tǒng)上是通過定制編碼的“點(diǎn)解決方案”來服務(wù)的，但專門針對(duì)它們的基礎(chǔ)設(shè)施軟件也最近開始在研究實(shí)驗(yàn)室和市場(chǎng)上出現(xiàn)。

基于我們對(duì)各種流應(yīng)用程序的經(jīng)驗(yàn)，我們提出了八條規(guī)則來描述實(shí)時(shí)流處理的要求。這些規(guī)則用于說明任何用于高容量低延遲流處理應(yīng)用程序的系統(tǒng)所需的必要功能。我們還觀察到，傳統(tǒng)的系統(tǒng)軟件未能滿足這些要求，這證明了SPE的必要性和相對(duì)優(yōu)勢(shì)。

本文由聞數(shù)起舞翻譯自論文 《The 8 requirements of real-time stream processing》https://dl.acm.org/doi/10.1145/1107499.1107504