0.摘要

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

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

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

1. 簡介

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

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

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

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

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

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

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

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

我們在下一節(jié)中將這些特性作為八條規(guī)則的集合呈現(xiàn)。然后我們在第三節(jié)中回顧替代技術(shù)，并總結(jié)它們在實時流處理方面的表現(xiàn)如何。最后，我們在第四節(jié)中做出最后的結(jié)論。

2.八項實時流處理規(guī)則

規(guī)則1：保持數(shù)據(jù)運動

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

“直通式”消息處理，可選存儲。

另一個延遲問題存在于被動系統(tǒng)中，這些系統(tǒng)在進行處理之前等待應(yīng)用程序告訴它們該做什么。被動系統(tǒng)要求應(yīng)用程序不斷輪詢感興趣的條件。不幸的是，輪詢會增加系統(tǒng)和應(yīng)用程序的額外開銷，并增加延遲，因為（平均而言）輪詢間隔的一半會加到處理延遲中。主動系統(tǒng)通過集成內(nèi)置的事件/數(shù)據(jù)驅(qū)動處理能力來避免這種開銷。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

TICKS (stock_symbol, volume, price, time)

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

SPLITS (symbol, time, split_factor)

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

能夠產(chǎn)生可預(yù)測的結(jié)果也從容錯和恢復(fù)的角度非常重要，因為重播和重新處理相同的輸入流應(yīng)該無論執(zhí)行時間如何都會產(chǎn)生相同的結(jié)果。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 基本架構(gòu)

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

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

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

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

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

DBMS使用“存儲后處理”模型，輸入數(shù)據(jù)首先存儲，可能被索引，然后再進行處理。主存儲DBMS更快，因為它們可以避免大部分更新操作涉及磁盤，但否則使用相同的基本模型。DBMS是被動的，即它們等待應(yīng)用程序告訴它們該做什么。一些DBMS具有內(nèi)置的觸發(fā)機制，但眾所周知，觸發(fā)器的可擴展性較差。另一方面，規(guī)則引擎和SPE都是主動的，并且不需要在處理之前存儲任何數(shù)據(jù)。因此，DBMS不會使數(shù)據(jù)保持流動，而規(guī)則引擎和SPE會。

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

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

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

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

3.3 表格結(jié)果

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

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

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

4.結(jié)論

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

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

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