軟件學報大數據流式計算：關鍵技術及系統實例bookmark0孫大為張廣艷U鄭緯民1bookmark1中國科學院軟件研究所版權所有。

　　清華大學計算機科學與技術系，北京100084）2（符號計算與知識工程教育部重點，批量計算首先進行數據的存儲，然后再對存儲的靜態數據進行集中計算。Hadoop是典型的大數據批量計算架構，由HDFS分布式文件系統負責靜態數據的存儲，并通過MapReduce將計算邏輯分配到各數據節點進行數據計算和價值發現；如所示，流式計算中，無法確定數據的到來時刻和到來順序，也無法將全部數據存儲起來。因此，不再進行流式數據的存儲，而是當流動的數據到來后在內存中直接進行數據的實時計算。如Twitter的Storm、Yahoo的S4就是典型的流式數據計算架構，數據在任務拓撲中被計算，并輸出有價值的信息。

　　流式計算和批量計算分別適用于不同的大數據應用場景：對于先存儲后計算，實時性要求不高，同時，數據的準確性、全面性更為重要的應用場景，批量計算模式更合適；對于無需先存儲，可以直接進行數據計算，實時性要求很嚴格，但數據的精確度要求稍微寬松的應用場景，流式計算具有明顯優勢。流式計算中，數據往往是最近一個時間窗口內的，因此數據延遲往往較短，實時性較強，但數據的精確程度往往較低。流式計算和批量計算具有明顯的優劣互補特征，在多種應用場合下可以將兩者結合起來使用。通過發揮流式計算的實時性優勢和批量計算的計算精度優勢，滿足多種應用場景在不同階段的數據計算要求。

　　目前，關于大數據批量計算相關技術的研究相對成熟，形成了以Google的MapReduce編程模型、開源的Hadoop計算系統為代表的高效、穩定的批量計算系統，在理論上和實踐中均取得了顯著成果。關于流式計算的早期研究往往集中在數據庫環境中開展數據計算的流式化，數據規模較小，數據對象比較單一。由于新時期的流式大數據呈現出實時性、易失性、突發性、無序性、無限性等特征，對系統提出了很多新的更高的要求。2010年，Yahoo推出S4流式計算系統，2011年，Twitter推出Storm流式計算系統，在一定程度上推動了大數據流式計算技術的發展和應用。但是，這些系統在可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等諸多方面仍然存在著明顯不足。如何構建低延遲、高吞吐且持續可靠運行的大數據流式計算系統，是當前亟待解決的問題。

　　本文以大數據流式計算系統的設計、優化和挑戰為核心，系統地梳理和分析了當前大數據流式計算系統的研究和發展現狀，總結了在金融銀行業應用、互聯網應用和物聯網應用這三大典型領域中，流式大數據所呈現出的實時性、易失性、突發性、無序性、無限性等特征。給出了理想的大數據流式計算系統在系統結構、數據傳輸、應用接口、高可用技術等方面應該具有的關鍵技術特性，論述并對比了5款大數據流式計算系統，即，Twitter的Storm系統、Yahoo的S4系統、Facebook的DataFreewayandPuma系統、Linkedin的Kafka系統、Microsoft的TimeStream系統。闡述了大數據流式計算系統在可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等方面所面臨的技術挑戰。本文工作為構建低延遲、高吞吐且持續可靠運行的大數據流式計算系統提供了一些指導性原則，彌補了當前關于大數據流式計算的研究成果不足的局面。

　　本文第1節分析大數據流式計算的典型應用領域及其特征。第2節論述設計優良的大數據流式計算系統在系統結構、數據傳輸、應用接口、高可用技術等方面應該滿足的關鍵技術要求。第3節分析對比5款比較典型的大數據流式計算系統。第4節具體闡述大數據流式計算在系統的可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等方面所面臨的新的挑戰。最后，第5節對全文進行總結。

　　1應用場景及數據特征大數據流式計算主要用于對動態產生的數據進行實時計算并及時反饋結果，但往往不要求結果絕對精確的應用場景。在數據的有效時間內獲取其價值，是大數據流式計算系統的首要設計目標，因此，當數據到來后將立即對其進行計算，而不再對其進行緩存等待后續全部數據到來再進行計算。

　　1.1應用場景大數據流式計算的應用場景較多，本文按照數據產生方式、數據規模大小以及技術成熟度高低這3個不同維度，選擇金融銀行業應用、互聯網應用和物聯網應用這3種典型應用場景，用于分析說明大數據流式計算的基本特征。從數據產生方式上看，它們分別是被動產生數據、主動產生數據和自動產生數據；從數據規模上看，它們處理的數據分別是小規模、中規模和大規模；從技術成熟度上看，它們分別是成熟度高、成熟度中和成熟度低的數據。

　　金融銀行業的應用在金融銀行領域的日常運營過程中，往往會產生大量數據，這些數據的時效性往往較短。因此，金融銀行領域是大數據流式計算最典型的應用場景之一，也是大數據流式計算最早的應用領域。在金融銀行系統內部，每時每刻都有大量的往往是結構化的數據在各個系統間流動，并需要實時計算。同時，金融銀行系統與其他系統也有著大量的數據流動，這些數據不僅有結構化數據，也會有半結構化和非結構化數據。通過對這些大數據的流式計算，發現隱含于其中的內在特征，可以幫助金融銀行系統進行實時決策。

　　在金融銀行的實時監控場景中，大數據流式計算往往體現出了自身的優勢。如：風險管理。包括信用卡詐騙、保險詐騙、證券交易詐騙、程序交易等，需要實時跟蹤發現；營銷管理。如，根據客戶信用卡消費記錄，掌握客戶的消費習慣和偏好，預測客戶未來的消費需求，并為其推薦個性化的金融產品和服務；商業智能。如，掌握金融銀行系統內部各系統的實時數據，實現對全局狀態的監控和優化，并提供決策支持。

　　互聯網領域的應用隨著互聯網技術的不斷發展，特別是Web 2.0時代的到來，用戶可以實時分享和提供各類數據。不僅使得數據量大為增加，也使得數據更多地以半結構化和非結構化的形態呈現。據統計，目前互聯網中75%的數據來源于個人，主要以圖片、音頻、視頻數據形式存在，需要實時分析和計算這些大量、動態的數據。

　　在互聯網領域中，大數據流式計算的典型應用場景包括：搜索引擎。搜索引擎提供商們往往會在反饋給客戶的搜索頁面中加入點擊付費的廣告信息。插入什么廣告、在什么位置插入這些廣告才能得到最佳效果，往往需要根據客戶的查詢偏好、瀏覽歷史、地理位置等綜合語義進行決定。而這種計算對于搜索服務器而言往往是大量的：一方面，每時每刻都會有大量客戶進行搜索請求；另一方面，數據計算的時效性極低，需要保證極短的響應時間；社交網站。需要實時分析用戶的狀態信息，及時提供最新的用戶分享信息到相關的朋友，準確地推薦朋友，推薦主題，提升用戶體驗，并能及時發現和屏蔽各種欺騙行為。

　　物聯網領域的應用在物聯網環境中，各個傳感器產生大量數據。這些數據通常包含時間、位置、環境和行為等內容，具有明顯的顆粒性。由于傳感器的多元化、差異化以及環境的多樣化，這些數據呈現出鮮明的異構性、多樣性、非結構化、有噪聲、高增長率等特征。所產生的數據量之密集、實時性之強、價值密度之低是前所未有的，需要進行實時、高效的計算。

　　在物聯網領域中，大數據流式計算的典型應用場景包括：智能交通。通過傳感器實時感知車輛、道路的狀態，并分析和預測一定范圍、一段時間內的道路流量情況，以便有效地進行分流、調度和指揮；環境監控。通過傳感器和移動終端，對一個地區的環境綜合指標進行實時監控、遠程查看、智能聯動、遠程控制，系統地解決綜合環境問題。

　　這些對計算系統的實時性、吞吐量、可靠性等方面都提出很高要求。

　　大數據流式計算的3種典型應用場景的對比見表1.從數據的產生方式看，金融銀行領域的數據往往是在系統中被動產生的，互聯網領域的數據往往是人為主動產生的，物聯網領域的數據往往是由傳感器等設備自動產生的；從數據的規模來看：金融銀行領域的數據與互聯網、物聯網領域的數據相比較少；物聯網領域的數據規模是最大的，但受制于物聯網的發展階段，當前實際擁有數據規模最大的是互聯網領域；從技術成熟度來看：金融銀行領域的流式大數據應用最為成熟，從早期的復雜事件處理開始就呈現了大數據流式計算的思想；互聯網領域的發展，將大數據流式計算真正推向歷史舞臺；物聯網領域的發展為大數據流式計算提供了重要的歷史機遇。

　　金融銀行互聯網物聯網動動動被主自小中大高中低表1大數據流式計算應用場景對比1.2流式大數據特征用有向無環圖（directedacyclicgraph，簡稱DAG）描述了大數據流的計算過程，其中，圓形表示數據的計算節點，箭頭表示數據的流動方向。

　　與大數據批量計算不同，大數據流式計算中的數據流主要體現了如下5個特征：流式大數據是實時產生、實時計算，結果反饋往往也需要保證及時性。流式大數據價值的有效時間往往較短，大部分數據到來后直接在內存中進行計算并丟棄，只有少量數據才被長久保存到硬盤中。這就需要系統有足夠的低延遲計算能力，可以快速地進行數據計算，在數據價值有效的時間內，體現數據的有用性。對于時效性特別短、潛在價值又很大的數據可以優先計算。

　　在大數據流式計算環境中，數據流往往是到達后立即被計算并使用，只有極少數的數據才會被持久化地保存下來，大多數數據往往會被直接丟棄。數據的使用往往是一次性的、易失的，即使重放，得到的數據流和之前的數據流往往也是不同的。這就需要系統具有一定的容錯能力，要充分地利用好僅有的一次數據計算機會，盡可能全面、準確、有效地從數據流中得出有價值的信息。

　　在大數據流式計算環境中，數據的產生完全由數據源確定，由于不同的數據源在不同時空范圍內的狀態不統一且發生動態變化，導致數據流的速率呈現出了突發性的特征。前一時刻數據速率和后一時刻數據速率可能會有巨大的差異，這就需要系統具有很好的可伸縮性，能夠動態適應不確定流入的數據流，具有很強的系統計算能力和大數據流量動態匹配的能力。一方面，在突發高數據流速的情況下，保證不丟棄數據，或者識別并選擇性地丟棄部分不重要的數據；另一方面，在低數據速率的情況下，保證不會太久或過多地占用系統資源。

　　在大數據流式計算環境中，各數據流之間、同一數據流內部各數據元素之間是無序的：一方面，由于各個數據源之間是相互獨立的，所處的時空環境也不盡相同，因此無法保證數據流間的各個數據元素的相對順序；另一方面，即使是同一個數據流，由于時間和環境的動態變化，也無法保證重放數據流和之前數據流中數據元素順序的一致性。這就需要系統在數據計算過程中具有很好的數據分析和發現規律的能力，不能過多地依賴數據流間的內在邏輯或者數據流內部的內在邏輯。

　　無限性在大數據流式計算中，數據是實時產生、動態增加的，只要數據源處于活動狀態，數據就會一直產生和持續增加下去?？梢哉f，潛在的數據量是無限的，無法用一個具體確定的數據實現對其進行量化。系統在數據計算過程中，無法保存全部數據：一方面，硬件中沒有足夠大的空間來存儲這些無限增長的數據；另一方面，也沒有合適的軟件來有效地管理這么多數據；并且，需要系統具有很好的穩定性，保證系統長期而穩定地運行。

　　表2對比了大數據流式計算和大數據批量計算的需求。

　　表2大數據流式、批量需求對比性能指標大數據流式計算大數據批量計算計算方式實時批量常駐空間內存硬盤時效性短長有序性無有數據量無限有限數據速率突發穩定是否可重現難易移動對象數據移動程序移動數據精確度較低較高2大數據流式計算關鍵技術針對具有實時性、易失性、突發性、無序性、無限性等特征的流式大數據，理想的大數據流式計算系統應該表現出低延遲、高吞吐、持續穩定運行和彈性可伸縮等特性，這其中離不開系統架構、數據傳輸、編程接口、高可用技術等關鍵技術的合理規劃和良好設計。

　　2.1系統架構系統架構是系統中各子系統間的組合方式，屬于大數據計算所共有的關鍵技術，大數據流式計算需要選擇特定的系統架構進行流式計算任務的部署。當前，大數據流式計算系統采用的系統架構可以分為無中心節點的對稱式系統架構（如S4，Puma等系統）以及有中心節點的主從式架構（如Storm系統）：對稱式架構。如所示：系統中各個節點的功能是相同的，具有良好的可伸縮性；但由于不存在中心節點，在資源調度、系統容錯、負載均衡等方面需要通過分布式協議實現。例如，S4通過Zookeeper實現系統容錯、負載均衡等功能；主從式系統架構。如所示：系統存在一個主節點和多個從節點，主節點負責系統資源的管理和任務的協調，并完成系統容錯、負載均衡等方面的工作；從節點負責接收來自于主節點的任務，并在計算完成后進行反饋。各個從節點間沒有數據往來，整個系統的運行完全依賴于主節點控制。

　　2.2數據傳輸數據傳輸是指完成有向任務圖到物理計算節點的部署之后，各個計算節點之間的數據傳輸方式。在大數據流式計算環境中，為了實現高吞吐和低延遲，需要更加系統地優化有向任務圖以及有向任務圖到物理計算節點的映射方式。如所示，在大數據流式計算環境中，數據的傳輸方式分為主動推送方式（基于push方式）和被動拉取方式（基于pull方式）：主動推送方式。在上游節點產生或計算完數據后，主動將數據發送到相應的下游節點，其本質是讓相關數據主動尋找下游的計算節點，當下游節點報告發生故障或負載過重時，將后續數據流推送到其他相應節點。主動推送方式的優勢在于數據計算的主動性和及時性，但由于數據是主動推送到下游節點，往往不會過多地考慮到下游節點的負載狀態、工作狀態等因素，可能會導致下游部分節點負載不夠均衡；被動拉取方式。只有下游節點顯式進行數據請求，上游節點才會將數據傳輸到下游節點，其本質是讓相關數據被動地傳輸到下游計算節點。被動拉取方式的優勢在于下游節點可以根據自身的負載狀態、工作狀態適時地進行數據請求，但上游節點的數據可能未必得到及時的計算。

　　大數據流式計算的實時性要求較高，數據需要得到及時處理，往往選擇主動推送的數據傳輸方式。當然，主動推送方式和被動拉取方式不是完全對立的，也可以將兩者進行融合，從而在一定程度上實現更好的效果。

　　2.3編程接口編程接口是方便用戶根據流式計算的任務特征，通過有向任務圖來描述任務內在邏輯和依賴關系，并編程實現任務圖中各節點的處理功能。用戶策略的定制、業務流程的描述和具體應用的實現，需要通過大數據流式計算系統提供的應用編程接口。良好的應用編程接口可以方便用戶實現業務邏輯，可以減少用戶的編程工作量，并降低用戶系統功能的實現門檻。

　　當前，大多數開源大數據流式計算系統均提供了類似于MapReduce的類MR用戶編程接口。例如：Storm提供Spout和Bolt應用編程接口，用戶只需要定制Spout和Bolt的功能，并規定數據流在各個Bolt間的內在流向，明確數據流的有向無環圖，其他具體細節的實現方式用戶不需要太多關心，即可滿足對流式大數據的高效、實時計算；也有部分大數據流式計算系統為用戶提供了類SQL的應用編程接口，并給出了相應的組件，便于應用功能的實現；StreamBase系統不僅為用戶提供了類SQL的應用編程接口來描述計算過程，也借助圖形化用戶視窗為用戶提供了豐富的組件。

　　2.4高可用技術大數據批量計算將數據事先存儲到持久設備上，節點失效后容易實現數據重放；而大數據流式計算對數據不進行持久化存儲。因此，批量計算中的高可用技術不完全適用于流式計算環境，需要根據流式計算新特征及其新的高可用要求，有針對性地研究更加輕量、高效的高可用技術和方法。

　　大數據流式計算系統高可用是通過狀態備份和故障恢復策略實現的。當故障發生后，系統根據預先定義的策略進行數據的重放和恢復。按照實現策略，可以細分為被動等待（passivestandby）、主動等待（activestandby）和上游備份（upstreambackup）這3種策略：如所示：主節點5進行數據計算，副本節點5'處于待命狀態，系統會定期地將主節點5上的最新的狀態備份到副本節點5'上。出現故障時，系統從備份數據中進行狀態恢復。被動等待策略支持數據負載較高、吞吐量較大的場景，但故障恢復時間較長，可以通過對備份數據的分布式存儲縮短恢復時間。該方式更適合于精確式數據恢復，可以很好地支持不確定性計算應用，在當前流式數據計算中應用最為廣泛。

　　如所示：系統在為主節點5傳輸數據的同時，也為副本節點5'傳輸一份數據副本。以主節點5為主進行數據計算，當主節點5出現故障時，副本節點5'完全接管主節點5的工作，主副節點需要分配同樣的系統資源。

　　該種方式故障恢復時間最短，但數據吞吐量較小，也浪費了較多的系統資源。在廣域網環境中，系統負載往往不是過大時，主動等待策略是一個比較好的選擇，可以在較短的時間內實現系統恢復。

　　如所示：每個主節點均記錄其自身的狀態和輸出數據到日志文件，當某個主節點5出現故障后，上游主節點會重放日志文件中的數據到相應副本節點5'中，進行數據的重新計算。上游備份策略所占用的系統資源最小，在無故障期間，由于副本節點5'保持空閑狀態，數據的執行效率很高。但由于其需要較長的時間進行恢復狀態的重構，故障的恢復時間往往較長。如當需要恢復時間窗口為30分鐘的聚類計算，就需要重放該30分鐘內的所有元組?？梢?，對于系統資源比較稀缺、算子狀態較少的情況，上游備份策略是一個比較好的選擇方案。

　　上游備份策略表3從5個方面詳細對比了上述3種高可用策略，實際應用中可以根據具體環境進行選擇。

　　表33種高可用策略對比性能指標被動等待策略主動等待策略上游備份策略系統性能低高恢復速度中高低資源使用中高低精準恢復是否適用范圍局域網廣域網局域網或廣域網2.5其他關鍵技術此外，大數據流式計算系統也離不開其他相關關鍵技術的支持，包括：系統故障恢復?？焖俚貙崿F從故障狀態到一種正確狀態的恢復，滿足系統的高效運行需求；系統資源調度。實現對系統中資源的最佳利用，提高資源的利用率，保證任務的完成和能耗的節?。回撦d均衡策略。實現對系統中的任務的動態、合理的分配，動態適應系統負載情況，保證系統中的任務均衡和穩定地運行；數據在任務拓撲中的路由策略。促進系統中負載均衡策略的高效實現、數據的合理流動及快速處理。

　　3系統實例分析文選擇當前比較典型的、應用較為廣泛的、具有代表性的前5款大數據流式計算系統進行實例分析。

　　Storm是Twitter支持開發的一款分布式的、開源的、實時的、主從式大數據流式計算系統，最新版本是Storm0.8.2，使用的協議為EclipsePublicLicense1.0，其核心部分使用了高效流式計算的函數式語言Clojure編寫，極大地提高了系統性能。但為了方便用戶使用，支持用戶使用任意編程語言進行項目的開發。

　　任務拓撲（topology）是Storm的邏輯單元，一個實時應用的計算任務將被打包為任務拓撲后發布，任務拓撲一旦提交后將會一直運行著，除非顯式地去中止。一個任務拓撲是由一系列Spout和Bolt構成的有向無環圖，通過數據流（stream）實現Spout和Bolt之間的關聯，如0所示。其中，Spout負責從外部數據源不間斷地讀取數據，并以Tuple元組的形式發送給相應的Bolt；Bolt負責對接收到的數據流進行計算，實現過濾、聚合、查詢等具體功能，可以級聯，也可以向外發送數據流。

　　數據流是Storm對數據進行的抽象，它是時間上無窮的Tuple元組序列，如1所示，數據流是通過流分組（streamgrouping）所提供的不同策略實現在任務拓撲中流動。此外，為了滿足確保消息能且僅能被計算1次的需求，Storm還提供了事務任務拓撲。

　　作業級容錯機制用戶可以為一個或多個數據流作業（以下簡稱數據流）進行編號，分配一個唯一的ID，Storm可以保障每個編號的數據流在任務拓撲中被完全執行。所謂的完全執行，是指由該ID綁定的源數據流以及由該源數據流后續生成的新數據流經過任務拓撲中每一個應該到達的Bolt，并被完全執行。如2所示，兩個數據流被分配一個TD=1，當且僅當兩個數據流分別經過Bolt 2，最終都到達Bolt3并均被完全處理后，才表明數據流被完全執行。

　　Storm通過系統級組件Acker實現對數據流的全局計算路徑的跟蹤，并保證該數據流被完全執行。其基本原理是為數據流中的每個分組進行編號，并通過異或運算來實現對其計算路徑的跟蹤。

　　作業級容錯的基本原理是：作業級容錯的基本流程是：在Spout中，系統會為數據流的每個分組生成一個唯一的64位整數，作為該分組的根ID.根ID會被傳遞給Acker及后續的Bolt作為該分組單元的唯一標識符。同時，無論是Spout還是Bolt，每次新生成一個分組的時候，都會重新賦予該分組一個新的64位的整數的ID.Spout發送完某個數據流對應的源分組后，并告知Acker自己所發射分組的根ID及生成的那些分組的新ID，而Bolt每次接受到一個輸入分組并計算完之后，也將告知Acker自己計算的輸入分組的ID及新生成的那些分組的ID，Acker只需要對這些ID做一個簡單的異或運算，就能判斷出該根ID對應的消息單元是否計算完成。

　　Storm采用主從系統架構，如3所示，在一個Storm系統中有兩類節點（即，一個主節點Nimbus、多個從主節點Nimbus運行在master環境中，是無狀態的，負責全局的資源分配、任務調度、狀態監控和故障檢測：一方面，主節點Nimbus接收客戶端提交來的任務，驗證后分配任務到從節點Supervisor上，同時把該任務的元信息寫入Zookeeper目錄中；另一方面，主節點Nimbus需要通過Zookeeper實時監控任務的執行情況，當出現故障時進行故障檢測，并重啟失敗的從節點Supervisor和工作進程Worker；從節點Supervisor運行在slaves環境中，也是無狀態的，負責監聽并接受來自于主節點Nimbus所分配的任務，并啟動或停止自己所管理的工作進程Worker，其中，工作進程Worker負責具體任務的執行。一個完整的任務拓撲往往由分布在多個從節點Supervisor上的Worker進程來協調執行，每個Worker都執行且僅執行任務拓撲中的一個子集。在每個Worker內部，會有多個Executor，每個Executor對應一個線程。Task負責具體數據的計算，即，用戶所實現的Spout/Blot實例。每個Executor會對應一個或多個Task，因此，系統中Executor的數量總是小于等于Task的數量。

　　Zookeeper是一個針對大型分布式系統的可靠協調服務和元數據存儲系統，通過配置Zookeeper集群，可以使用Zookeeper系統所提供的高可靠性服務。Storm系統引入Zookeeper，極大地簡化了Nimbus，Supervisor，Worker之間的設計，保障了系統的穩定性。Zookeeper在Storm系統中具體實現了以下功能：⑷存儲客戶端提交的任務拓撲信息、任務分配信息、任務的執行狀態信息等，便于主節點Nimbus監控任務的執行情況；（b）存儲從節點Supervisor、工作進程Worker的狀態和心跳信息，便于主節點Nimbus監控系統各節點運行狀態；（c）存儲整個集群的所有狀態信息和配置信息，便于主節點Nimbus監控Zookeeper集群的狀態，在出現主Zookeeper節點掛掉后可以重新選取一個節點作為主Zookeeper節點，并進行恢復。

　　3Storm系統架構Storm系統的主要特征為：⑻簡單編程模型。用戶只需編寫Spout和Bolt部分的實現，因此極大地降低了實時大數據流式計算的復雜性；（b）支持多種編程語言。默認支持ClojureJava，Ruby和Python，也可以通過添加相關協議實現對新增語言的支持；（c）作業級容錯性。可以保證每個數據流作業被完全執行；（d）水平可擴展。計算可以在多個線程、進程和服務器之間并發執行；（e）快速消息計算。通過ZeroMQ作為其底層消息隊列，保證了消息能夠得到快速的計算。

　　Storm系統存在的不足主要包括：資源分配沒有考慮任務拓撲的結構特征，無法適應數據負載的動態變化；采用集中式的作業級容錯機制，在一定程度上限制了系統的可擴展性。

　　S4是Yahoo支持開發的一款分布式的、可擴展的、可插拔的、對稱的大數據流式計算系統，最新版本是S4處理單元PE（processingelement）如4所示，是S4中的基本計算單元，由4個組件構成，即：（a）函數。實現了與該處理單元PE相對應的功能和配置；（b）事件類型。規定了該處理單元PE所接收的事件類型；（c）主鍵。規定了該處理單元PE所關心的事件主鍵；（d）鍵值。規定了該處理單元PE所匹配的鍵值。

　?。ê瘮担ㄊ录愋停ㄖ麈I）（鍵值）4處理單元PE處理單元PE只關心與其事件類型相匹配的事件，并僅僅處理與其主鍵、鍵值相一致的事件，即，只有事件類型、主鍵、鍵值全部匹配后，處理單元PE才會處理該類事件。當一個新事件沒有可以匹配的處理單元PE時，系統將會為該事件新創建一個處理單元PE.因此，需要高效、動態地創建、管理和刪除處理單元PE；同時，處理單元PE的類型設計及其拓撲結構也需要更合理地規劃。

　　有一類處理單元PE位于S4的輸入層，它們沒有主鍵、鍵值，只需事件類型相匹配，即對該類事件進行處理。

　　通常情況下，該類處理單元PE所計算的事件為原始輸入事件，其輸出事件會被新增主鍵、鍵值，以便后續處理單元PE進行計算。

　　在S4系統中，數據流是由事件的有序序列構成的，其中，分別表示該類型事件的若干個和若干個和都是tap/e-va/Me式即，fcey=va/Me的元組值。事件在各個處理單元PE中被計算，在處理單元PE之間流動，處理單元PE之間的邏輯構成了一個有向無環圖。

　　5描述了一個統計Topi熱點單詞的實例。

　　在5所示的有向無環圖中，節點表示處理單元PE，實現對數據流的計算和新數據流的輸出，有向邊表示事件的有序序列（r，4）及其流向。在該實例中，實現了對于流式數據中的Topr熱點單詞的統計，其數據流的具體內容見表4，其中，數據流1是初始化數據流，因此其主鍵值為空，鍵值為實時流入的文本數據，在處理單元PE1中被分割為各個單詞，形成了新的數據流，其事件類型為單詞統計，主鍵為word=x，鍵值為counts，并分別分流到處理單元PE2、處理單元PE3、處理單元PE4等節點中進行計算，并再次形成了新的數據流，其事件類型為單詞數更新，主鍵為SortID=x，鍵值為word=y，count=z，并分別分流到處理單元PE5、處理單元PE6、處理單元PE7等節點中進行計算，最后在處理單元PE8中進行匯總和排序，得出當前的Topr個熱點單詞。

　　表4數據流內容數據流事件類型主鍵鍵值查詢無單詞統計單詞數更新匯總降序輸出無在S4的處理節點Pnode中，如6所示，由處理空間和傳輸空間組成，其中，84處理節點空間在處理空間中，事件監聽系統主要用于監聽并分發接收到的事件計算請求，并由調度分配系統將事件分配到處理單元集PEC（processingelementcontainer）上進行計算，處理單元集PEC以適當的順序調用適當的處理單元PE，并保證每個主鍵A：e>的處理單元PE都會被映射到一個確定的處理節點Pnode上。

　　之后，處理節點Pnode或者發出輸出事件，或者向傳輸層請求協助，向指定邏輯節點發送消息。其中，處理單元集PEC由一個處理節點Pnode中內部的多個處理單元PE組成。處理單元PE是事件計算的最小單元，接受一個或多個來自于事件源或其他處理單元PE的事件進行計算，之后，分發一個或多個計算后的事件到其他處理單元PE或輸出結果。各個處理單元PE間相互獨立，它們之間通過事件構成關聯，事件在各處理單元PE間以數據流的形式進行傳輸；在傳輸空間中，主要通過路由管理、負載均衡、集群管理、容錯管理等實現對事件流的路由選擇、負載均衡、邏輯影射、故障恢復到備用節點等方面的管理和功能，并通過Zookeeper系統在S4集群節點間實現一致性協作。S4通過插件式的架構來動態選擇信息傳輸協議，對于控制信息，通常采用可靠傳輸協議，如TCP，保障控制信息傳輸的可靠性。對于數據信息，通常采用不可靠傳輸協議，如UDP，保障數據信息的高吞吐量。

　　系統架構處理單元集PEC用戶空間S4采用了對等式系統架構，如7所示。

　?。ㄐ阅鼙O控（客戶適配器）c配置維護（T名字服務）7S4系統結構在一個S4系統中，由用戶空間、資源調度空間和S4處理節點空間組成，其中，在用戶空間中，多個用戶可以通過本地的客戶端驅動實現服務的請求訪問；在資源調度空間中，為用戶提供了客戶適配器，通過TCP/IP協議實現用戶的客戶端驅動與客戶適配器間的連接和通信，多個用戶可以并發地與多個客戶適配器進行服務請求；在S4處理節點空間中，提供了多個處理節點Pnode，進行用戶服務請求的計算。各個處理節點間保持相對的獨立性、對等性和高并發性，極大地提高了系統的性能，并通過Hash方式將事件路由到一個或多個目標處理節點Pnode上。

　　S4系統存在的不足主要包括：當數據流到達速度超過一定界限時，到達速度越高，系統數據處理的錯誤率越大；不支持系統節點的熱插拔，所有對節點的調整都必須離線進行；僅支持部分容錯，即，節點失效轉移時會丟失原節點內存中的狀態信息。

　　數據傳輸通道和大數據流式計算系統。

　　系統ZK節點DataFreeway是Facebook支持開發的一款可擴展數據流架構（scalabledatastreamframework），可以有效地支持4種數據間的傳輸，即，文件到文件、文件到消息、消息到消息和消息到文件。其系統結構如8所示，DataFreeway數據流架構由4個組件構成，即，Scribe，Calligraphus，ContinuousCopier和PTail.Scribe組件位于用戶端，其功能是將用戶的數據通過RPC發送到服務器端；Calligraphus組件實現了對日志類型的維護與管理，其功能是通過Zookeeper系統，將位于緩沖區中的數據并發寫到HDFS中；ContinuousCopier組件的功能是實現在各個HDFS系統間進行文件的遷移；PTail組件實現了并行地將文件輸出。

　　所示，當前最新寫數據流備份數據流| PTail子系統Puma3子系統讀數據流。HBase節點1 HBase子系統Serving子系統；統延遲。Puma3哈希表，每個表從Puma3中將中讀取副本，進系統實現時，在Calligraphus階項對應一個Key及用戶定義的內存中的數據備份到HBase中了數據聚合功能，極大地提高了數據的計算能力，有效地降低了系段通過聚合主鍵完成對數據的分片，其中，每個分片都是內存中的聚合方法，如統計、求和、平均值等操作。HBase子系統會定期地，進行數據的持久化存儲。只有當Puma3發生故障時，才從HBase行數據的重放，實現對因故障丟失數據的恢復；在無故障的情況下，HBase子系統不參與數據的計算，因此提高了數據的計算能力。

　　DataFreewayandPuma系統存在的不足主要包括：數據延遲在秒級，無法滿足大數據流式計算所需要的毫秒級應用需求；將哈希表完全放入內存的加速機制，導致內存需求量大；資源調度策略不夠簡單、高效，不能靈活適應連續的工作負載。

　　KafW38，54-56是Lrnkedm所支持的一款開源的、分布式的、高吞吐量的發布訂閱消息系統，可以有效地處理互聯網中活躍的流式數據，如網站的頁面瀏覽量、用戶訪問頻率、訪問統計、好友動態等，最新版本是Kafka0.8，開發語言是Scala，可以使用Java進行編寫。

　　Kafka系統在設計過程中主要考慮到了以下需求特征：消息持久化是一種常態需求；吞吐量是系統需要滿足的首要目標；消息的狀態作為訂閱者（consumer）存儲信息的一部分，在訂閱者服務器中進行存儲；將發布者（producer）、代理（broker）和訂閱者（consumer）顯式地分布在多臺機器上，構成顯式的分布式系統。形成了以下關鍵特性：在磁盤中實現消息持久化的時間復雜度為0（1），數據規模可以達到TB級別；實現了數據的高吞吐量，可以滿足每秒數十萬條消息的處理需求；實現了在服務器集群中進行消息的分片和序列管理；實現了對Hadoop系統的兼容，可以將數據并行地加載到Hadoop集群中。

　　Kafka消息系統的架構是由發布者（producer）、代理（broker）和訂閱者（consumer）共同構成的顯式分布式架發布訂閱者構，即，分別位于不同的節點上，如0所示。各部分構成一個完整的邏輯組，并對外界提供服務，各部分間通過消息（message）進行數據傳輸。其中，發布者可以向一個主題（topic）推送相關消息，訂閱者以組為單位，可以關注并拉取自己感興趣的消息，通過Zookeeper實現對訂閱者和代理的全局狀態信息的管理，及其負載均衡的實現。

　　數據存儲Kafka消息系統通過僅僅進行數據追加的方式實現對磁盤數據的持久化保存，實現了對大數據的穩定存儲，并有效地提高了系統的計算能力。通過采用Sendfile系統調用方式優化了網絡傳輸，減少了1次內存拷貝，提高了系統的吞吐量，即使對于普通的硬件，Kafka消息系統也可以支持每秒數十萬的消息處理能力。此外，在Kafka消息系統中，通過僅保存訂閱者已經計算數據的偏量信息，一方面可以有效地節省數據的存儲空間，另一方面，也簡化了系統的計算方式，方便了系統的故障恢復。

　　Kafka消息系統采用了推送、拉取相結合的方式進行消息的傳輸，其中，當發布者需要傳輸消息時，會主動地推送該消息到相關的代理節點；當訂閱者需要訪問數據時，其會從代理節點中進行拉取。通常情況下，訂閱者可以從代理節點中拉取自己感興趣的主題消息。

　　在Kafka消息系統中，發布者和代理節點之間沒有負載均衡機制，但可以通過專用的第4層負載均衡器在Kafka代理之上實現基于TCP連接的負載均衡的調整。訂閱者和代理節點之間通過Zookeeper實現了負載均衡機制，在Zookeeper中管理全部活動的訂閱者和代理節點信息，當有訂閱者和代理節點的狀態發生變化時，才實時進行系統的負載均衡的調整，保障整個系統處于一個良好的均衡狀態。

　　Kafka系統存在的不足主要包括：只支持部分容錯，即，節點失效轉移時會丟失原節點內存中的狀態信息；代理節點沒有副本機制保護，一旦代理節點出現故障，該代理節點中的數據將不再可用；代理節點不保存訂閱者的狀態，刪除消息時無法判斷該消息是否已被閱讀。

　　TimeStream是Microsoft在Streamlnsight的基礎上開發的一款分布式的、低延遲的、實時連續的大數據流式計算系統，通過彈性替代機制，可以自適應因故障恢復和動態配置所導致的系統負載均衡的變化，使用C.NET來編寫。

　　TimeStream的開發是基于大數據流式計算以下兩點來考慮的：（a）連續到達的流式大數據已經遠遠超出了單臺物理機器的計算能力，分布式的計算架構成為必然的選擇；（b）新產生的流式大數據必須在極短的時間延遲內，經過相關任務拓撲進行計算后，產生出能夠反映該輸入數據特征的計算結果。

　　TimeStream中的數據計算邏輯是基于數據流DAG實現的，如1所示，在數據流DAG中的每個頂點V，在獲取輸入數據流/后，觸發相關操作/產生新數據流，并更新頂點v的狀態從ljA即，（A）=/v（M）。

　　1數據流任務拓撲頂點在TimeStream中，一個數據流子圖sub-DAG是指在數據流DAG中，兩頂點及該兩頂點間的全部頂點和有向邊的集合，即，滿足：對于數據流子圖sub-DAG中任意兩頂點vi和v2，以及數據流DAG中任意一頂點V，若頂點V位于頂點V1和V2的有向邊上，那么頂點V?定是數據流子圖sub-DAG的一個頂點。數據流子圖sub-DAG在邏輯上可以簡化為一個與其功能相同的頂點，如2所示，在一個由7個頂點所組成的數據流DAG中，由頂點V2，V3，V4和V5及其有向邊所構成的數據流子圖sub-DAG，可以簡化為一個輸入數據流為/、輸出數據流為的邏輯頂點。

　　在TimeStream中，當出現服務器故障或系統負載劇烈持續變化的情況時，可以通過數據流子圖sub-DAG間、數據流子圖sub-DAG與頂點間以及各頂點間的彈性等價替代，動態、實時地適應系統的負載變化需求。具體而言，彈性等價替代可以進一步細分為3種情況：頂點間的彈性等價替代。當數據流DAG中的任意一頂點v出現故障不能正常工作時，系統會啟動一個具有相同功能的頂點V，并接管頂點v的工作；數據流子圖sub-DAG與頂點間的彈性等價替代。如2所示，當整個系統的負載過輕時，為了節省系統的資源，可以通過一個新的頂點v代替由頂點V2，V3，V4和V5所組成的數據流子圖sub-DAG，該新頂點v將實現數據流子圖sub-DAG的全部功能；反之，當系統的負載過重時，也可以用一個數據流子圖sub-DAG代替任意一個頂點v，實現功能的分解和任務的分擔；數據流子圖sub-DAG間的彈性等價替代。如3所示，右側由頂點V2，V3，V4和V5所組成的數據流子圖sub-DAG實現了HashPartition，Computation和Union等功能，但當系統的Computation功能的計算量突然持續增大后，用左側由頂點V8，v9，vi0，v，vi2和vn所組成的數據流子圖sub-DAG彈性等價替代右側的子圖，實現了將Computation計算節點由2個增加到4個，提高了Computation的計算能力。

　　通過彈性等價替代機制可以有效地適應系統因故障和負載的變化對系統性能產生的影響，保證系統性能的穩定性；但在彈性等價替代的過程中，一定要實現替代子圖或頂點間的等價，并盡可能地進行狀態的恢復。所謂的等價，即對于相同的輸入，子圖或頂點可以在功能上產生相同的輸出，唯一存在的區別在于其性能的不同。

　　狀態的恢復是通過對數據流DAG中的依賴關系跟蹤機制來實現，并盡可能全面地進行系統狀態的恢復。

　　在TimeStream的系統結構中，實現了資源分配、節點調度、故障檢測等功能。

　　如4所示，位于頭節點（headnode）中的集群管理器（clustermanager，簡稱CM）實現了對系統資源的管理和任務的分配，位于計算節點（computenode）的節點服務器（nodeservice，簡稱NS）實現了對計算節點的管理和維護。當一個新的數據流任務進入系統被計算時：首先，系統為該任務分配一個全局唯一的查詢協調器（querycoordinator，簡稱QC），查詢協調器QC向集群管理器CM請求資源運行任務的數據流DAG；其次，向節點服務器NS請求調度頂點處理器（vertexprocesses，簡稱VP），并實現數據流DAG的構建；再次，實施數據計算；最后，查詢協調器QC和頂點處理器VP均會實時地跟蹤系統的運行情況，并定期地將相關元數據信息保持到數據庫中，在出現系統故障或負載劇烈持續變化的情況時，可以通過這些被永久保存的元數據進行系統狀態的恢復和實時動態的調整。

　　存在不足TimeStream系統存在的不足主要包括：數據延遲在秒級，無法滿足毫秒級的應用需求；基于依賴關系跟蹤的容錯機制降低了系統性能，當系統規模為16個節點時，系統吞吐量下降了10%左右。

　　3.6對比分析系統進行了對比分析。

　　表5數據流系統對比性能指標S4系統系統架構主從對稱主從數據傳輸拉取推送推送拉取拉取應用接口MR接口SQL接口高可用性上游備份策略被動等待策略主動等待策略被動等待策略上游備份策略開發語言容錯機制作業級容錯部分容錯依賴關系跟蹤精確恢復否是資源利用率高低高狀態持久化否是否是數據去重否是否編程模型純編程編程+XML純編程負載均衡不支持部分支持支持典型應用社交網絡廣告投放站點統計好友動態微博情感分析可以看到：在體系結構方面：Storm，Kafka，TimeStream選擇了主從式體系結構，S4和DataFreewayandPuma均選擇了對稱式體系結構；在應用接口方面：Storm，S4，Puma，Kafka均選擇了類MapReduce接口，簡化了用戶的編程；TimeStream選擇了用戶更為熟悉的類SQL接口。此外，HStreammg已為用戶提供了更為方便的基于拖拽的可視化接口；在開發語言方面：S4和Puma均選擇了Java語言；Storm的核心代碼雖然選擇了Clojure語言，但也支持在高可用策略方面：S4和Kafka均選擇了被動等待策略，因此其資源利用率比較低；DataFreewayandPuma選擇了主動等待策略；Storm，TimeStream選擇了上游備份策略，相應的資源利用率比較高；Storm，S4，DataFreewayandPuma和Kafka目前均不支持數據的精確恢復、負載均衡等功能，但面向金融領域的StreamBase支持數據的精確恢復。

　　如5所示，批量計算相關的大數據系統，如批量處理系統（如MapReduce）、大規模并行數據庫等，在數據吞吐量方面具有明顯優勢，但在系統響應時間方面往往在秒級以上。而當前的流式計算相關的大數據系統，如流式處理系統、內存數據庫、CEP（復雜事件處理）等，在系統響應時間方面雖然維持在毫秒級的水平，但數據吞吐量往往在GB級別，遠遠滿足不了大數據流式計算系統對數據吞吐量的要求。通常情況下，一個理想的大數據流式計算系統在響應時間方面應維持在毫秒級的水平，并且數據吞吐量應該提高到PB級及其以上水平。

　　4面臨的技術挑戰流式大數據在實時性、無序性、無限性、易失性、突發性等方面均呈現出了諸多新的鮮明特征，因此，傳統的先存儲后計算的批量數據計算理念不適用于大數據流式計算的環境中，使得大數據流式環境中的數據計算在系統的可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等方面均面臨著前所未有的新的挑戰。

　　4.1可伸縮性在大數據流式計算環境中，系統的可伸縮性是制約大數據流式計算系統廣泛應用的一個重要因素。Storm，Kafka，TimeStream等系統沒有實現對系統可伸縮性的良好支持：一方面，流式數據的產生速率在高峰時期會不斷增加且數據量巨大，持續時間往往很長，因此需要大數據流式系統具有很好的“可伸”的特征，可以實時適應數據增長的需求，實現對系統資源進行動態調整和快速部署，并保證整個系統的穩定性；另一方面，當流式數據的產生速率持續減少時，需要及時回收在高峰時期所分配的但目前已處于閑置或低效利用的資源，實現整個系統架構和有效的分配，是保障整個系統可伸縮性的基礎，同時，又盡可能地減少不必要的資源和能源的浪費。

　　大數據流式計算環境中的可伸縮性問題的解決，需要實現對系統架構的合理布局、系統資源的有序組織、高效管理和靈活調度，在保證系統完成計算的前提下，盡量少地太久、太多地占用系統資源，通過虛擬化機制實現軟、硬件之間的低耦合，實現資源的在線遷移，并最終解決大數據流式計算環境中的可伸縮性問題。

　　4.2系統容錯在大數據流式計算環境中，系統容錯機制是進一步改善整個系統性能、提高計算結果的滿意度、保證系統可靠持續運行的一個重要措施，也是當前大多數大數據流式計算系統所缺失的。如S4，Puma，Kafka等系統實現了對部分容錯的支持，Storm系統實現了對作業級容錯的支持，TimeStream系統通過依賴關系跟蹤實現了對容錯的部分支持。大數據流式計算環境對容錯機制提出了新的挑戰：一方面，數據流是實時、持續地到來，呈現出時間上不可逆的特征，一旦數據流流過，再次重放數據流的成本是很大的，甚至是不現實的。由于數據流所呈現出的持續性和無限性，也無法預測未來流量的變化趨勢；另一方面，在流式大數據的計算過程中，大部分“無用”的數據將被直接丟棄，能被永久保存下來的數據量是極少的，當需要進行系統容錯時，其中不可避免地會出現一個時間段內數據不完整的情況；再則，需要針對不同類型的應用，從系統層面上設計符合其應用特征的數據容錯級別和容錯策略，避免不必要的資源浪費及應用需求的不吻合。

　　大數據流式計算環境中的容錯策略的確定，需要根據具體的應用場景進行系統的設計和權衡，并且需要充分考慮到流式大數據的持續性、無限性、不可恢復性等關鍵特征。但是，沒有任何數據丟失的容錯策略也未必是最佳的，需要綜合統籌容錯級別和資源利用、維護代價等要素間的關系。但在對系統資源占用合理、對系統性能影響可接受的情況下，容錯的精度越高必將越好。

　　4.3狀態一致性在大數據流式計算環境中，維持系統中各節點間狀態的一致性對于系統的穩定、高效運行、故障恢復都至關重要。然而，當前多數系統不能有效地支持系統狀態的一致性，如Storm，Kafka等系統尚不支持維護系統狀態的一致性，S4，TimeStream等系統也僅實現了在一定程度上對狀態一致性的支持。大數據流式計算環境對狀態一致性提出了新的挑戰：一方面，在系統實時性要求極高、數據速率動態變化的環境中，維護哪些數據的狀態一致性，如何從高速、海量的數據流中識別這些數據是一個巨大的挑戰；另一方面，在大規模分布式環境中，如何組織和管理實現系統狀態一致性的相關數據，滿足系統對數據的高效組織和精準管理的要求，也是一個巨大的挑戰。

　　大數據流式計算環境中的狀態一致性問題的解決，需要從系統架構的設計層面上著手。存在全局唯一的中心節點的主從式架構方案無疑是實現系統狀態一致性的最佳解決方案，但需要有效避免單點故障問題。通常情況下，在大數據流式計算環境中，程序和數據一旦啟動后，將會常駐內容，對系統的資源占用也往往相對穩定。因此，單點故障問題在大數據流式計算環境中并沒有批量計算環境中那么復雜。批量計算環境中的很多策略將具有很好的和借鑒價值。

　　4.4負載均衡在大數據流式計算環境中，系統的負載均衡機制是制約系統穩定運行、高吞吐量計算、快速響應的一個關鍵因素。然而，當前多數系統不能有效地支持系統的負載均衡，如Storm，S4等系統均不支持負載均衡機制，Kafka系統實現了對負載均衡機制的部分支持：一方面，在大數據流式計算環境中，系統的數據速率具有明顯的突變性，并且持續時間往往無法有效預測，這就導致在傳統環境中具有很好的理論和實踐效果的負載均衡策略在大數據流式計算環境中將不再適用；另一方面，當前大多數開源的大數據流式計算系統在架構的設計上尚未充分地、全面地考慮整個系統的負載均衡問題，在實踐應用中，相關經驗的積累又相對缺乏，因此，給大數據流式計算環境中負載均衡問題的研究帶來了諸多實踐中的困難和挑戰。

　　大數據流式計算環境中的負載均衡問題的解決，需要結合具體的應用場景，系統地分析和總結隱藏在大數據流式計算中的數據流變化的基本特征和內在規律，結合傳統系統負載均衡的經驗，根據實踐檢驗情況，不斷進行相關機制的持續優化和逐步完善。

　　4.5數據吞吐量在大數據流式計算環境中，數據吞吐量呈現出了根本性的增加。在傳統的流式數據環境中，如CEP，所處理的數據吞吐量往往在GB級別，滿足不了大數據流式計算環境對數據的吞吐量的要求。在大數據流式計算環境中，數據的吞吐量往往在TB級別以上，且其增長的趨勢是顯著的。然而，當前流式數據處理系統，如Storm，S4等，均無法滿足TB級別的應用需求。

　　大數據流式計算環境中的數據吞吐量問題的解決，一方面需要從硬件的角度進行系統的優化，設計出更符合大數據流式計算環境的硬件產品，在數據的計算能力上實現大幅提升；另一方面，更為重要的是，從系統架構的設計中進行優化和提升，設計出更加符合大數據流式計算特征的數據計算邏輯。

　　5結論流式大數據作為大數據的一種重要形態，在商業智能、市場營銷和公共服務等諸多領域有著廣泛的應用前景，并已在金融銀行業、互聯網、物聯網等場景的應用中取得了顯著的成效。但流式大數據以其實時性、無序性、無限性、易失性、突發性等顯著特征，使得其與傳統批量大數據在數據計算的要求、方式等方面有著明顯的不同，也使得當前諸多數據計算系統無法進一步更好地適應流式大數據在系統可伸縮性、容錯、狀態一致性、負載均衡、數據吞吐量等方面所帶來的諸多新的技術挑戰。

　　本文從大數據環境中流式數據的特征切入，以大數據流式計算架構的設計、優化和挑戰為核心，系統地梳理和分析了當前大數據環境中的關于大數據流式計算系統的研究和發展現狀，從系統架構的角度分析了一個設計優良的大數據流式計算系統應該在系統結構、數據傳輸、應用接口、高可用技術等諸多關鍵技術上進行優化。同時，本文詳細地分析和對比了當前在實踐中具有很好的應用基礎、較為典型的5款大數據流式計算系統，并具體闡述了大數據流式計算在系統的可伸縮性、系統容錯、狀態一致性、負載均衡、數據吞吐量等方面所面臨的新的挑戰，實現了對流式大數據環境中數據計算架構、關鍵問題及其技術挑戰的深入研究。

　　可以看出，大數據流式計算的研究和應用仍處于很不成熟的階段，這與其廣泛的市場需求和應用前景很不吻合。為了促進大數據流式計算的成熟、穩健發展，亟待全面、系統、深入地開展相關理論和實踐的研究工作。

　　在未來的研究工作中，將進一步深化對大數據流式計算架構及其關鍵技術的研究，并結合詳細的應用需求，開發、部署、測試并優化面向特定應用領域的大數據流式計算系統，進一步推動大數據流式計算理論、方法、技術與系統的研究與發展。