軟件學報大數(shù)據(jù)流式計算：關(guān)鍵技術(shù)及系統(tǒng)實例bookmark0孫大為張廣艷U鄭緯民1bookmark1中國科學院軟件研究所版權(quán)所有。

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

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

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

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

　　本文第1節(jié)分析大數(shù)據(jù)流式計算的典型應(yīng)用領(lǐng)域及其特征。第2節(jié)論述設(shè)計優(yōu)良的大數(shù)據(jù)流式計算系統(tǒng)在系統(tǒng)結(jié)構(gòu)、數(shù)據(jù)傳輸、應(yīng)用接口、高可用技術(shù)等方面應(yīng)該滿足的關(guān)鍵技術(shù)要求。第3節(jié)分析對比5款比較典型的大數(shù)據(jù)流式計算系統(tǒng)。第4節(jié)具體闡述大數(shù)據(jù)流式計算在系統(tǒng)的可伸縮性、系統(tǒng)容錯、狀態(tài)一致性、負載均衡、數(shù)據(jù)吞吐量等方面所面臨的新的挑戰(zhàn)。最后，第5節(jié)對全文進行總結(jié)。

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

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

　　金融銀行業(yè)的應(yīng)用在金融銀行領(lǐng)域的日常運營過程中，往往會產(chǎn)生大量數(shù)據(jù)，這些數(shù)據(jù)的時效性往往較短。因此，金融銀行領(lǐng)域是大數(shù)據(jù)流式計算最典型的應(yīng)用場景之一，也是大數(shù)據(jù)流式計算最早的應(yīng)用領(lǐng)域。在金融銀行系統(tǒng)內(nèi)部，每時每刻都有大量的往往是結(jié)構(gòu)化的數(shù)據(jù)在各個系統(tǒng)間流動，并需要實時計算。同時，金融銀行系統(tǒng)與其他系統(tǒng)也有著大量的數(shù)據(jù)流動，這些數(shù)據(jù)不僅有結(jié)構(gòu)化數(shù)據(jù)，也會有半結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。通過對這些大數(shù)據(jù)的流式計算，發(fā)現(xiàn)隱含于其中的內(nèi)在特征，可以幫助金融銀行系統(tǒng)進行實時決策。

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

　　互聯(lián)網(wǎng)領(lǐng)域的應(yīng)用隨著互聯(lián)網(wǎng)技術(shù)的不斷發(fā)展，特別是Web 2.0時代的到來，用戶可以實時分享和提供各類數(shù)據(jù)。不僅使得數(shù)據(jù)量大為增加，也使得數(shù)據(jù)更多地以半結(jié)構(gòu)化和非結(jié)構(gòu)化的形態(tài)呈現(xiàn)。據(jù)統(tǒng)計，目前互聯(lián)網(wǎng)中75%的數(shù)據(jù)來源于個人，主要以圖片、音頻、視頻數(shù)據(jù)形式存在，需要實時分析和計算這些大量、動態(tài)的數(shù)據(jù)。

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

　　物聯(lián)網(wǎng)領(lǐng)域的應(yīng)用在物聯(lián)網(wǎng)環(huán)境中，各個傳感器產(chǎn)生大量數(shù)據(jù)。這些數(shù)據(jù)通常包含時間、位置、環(huán)境和行為等內(nèi)容，具有明顯的顆粒性。由于傳感器的多元化、差異化以及環(huán)境的多樣化，這些數(shù)據(jù)呈現(xiàn)出鮮明的異構(gòu)性、多樣性、非結(jié)構(gòu)化、有噪聲、高增長率等特征。所產(chǎn)生的數(shù)據(jù)量之密集、實時性之強、價值密度之低是前所未有的，需要進行實時、高效的計算。

　　在物聯(lián)網(wǎng)領(lǐng)域中，大數(shù)據(jù)流式計算的典型應(yīng)用場景包括：智能交通。通過傳感器實時感知車輛、道路的狀態(tài)，并分析和預測一定范圍、一段時間內(nèi)的道路流量情況，以便有效地進行分流、調(diào)度和指揮；環(huán)境監(jiān)控。通過傳感器和移動終端，對一個地區(qū)的環(huán)境綜合指標進行實時監(jiān)控、遠程查看、智能聯(lián)動、遠程控制，系統(tǒng)地解決綜合環(huán)境問題。

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

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

　　金融銀行互聯(lián)網(wǎng)物聯(lián)網(wǎng)動動動被主自小中大高中低表1大數(shù)據(jù)流式計算應(yīng)用場景對比1.2流式大數(shù)據(jù)特征用有向無環(huán)圖（directedacyclicgraph，簡稱DAG）描述了大數(shù)據(jù)流的計算過程，其中，圓形表示數(shù)據(jù)的計算節(jié)點，箭頭表示數(shù)據(jù)的流動方向。

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

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

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

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

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

　　表2對比了大數(shù)據(jù)流式計算和大數(shù)據(jù)批量計算的需求。

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

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

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

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

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

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

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

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

　　如所示：系統(tǒng)在為主節(jié)點5傳輸數(shù)據(jù)的同時，也為副本節(jié)點5'傳輸一份數(shù)據(jù)副本。以主節(jié)點5為主進行數(shù)據(jù)計算，當主節(jié)點5出現(xiàn)故障時，副本節(jié)點5'完全接管主節(jié)點5的工作，主副節(jié)點需要分配同樣的系統(tǒng)資源。

　　該種方式故障恢復時間最短，但數(shù)據(jù)吞吐量較小，也浪費了較多的系統(tǒng)資源。在廣域網(wǎng)環(huán)境中，系統(tǒng)負載往往不是過大時，主動等待策略是一個比較好的選擇，可以在較短的時間內(nèi)實現(xiàn)系統(tǒng)恢復。

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

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

　　表33種高可用策略對比性能指標被動等待策略主動等待策略上游備份策略系統(tǒng)性能低高恢復速度中高低資源使用中高低精準恢復是否適用范圍局域網(wǎng)廣域網(wǎng)局域網(wǎng)或廣域網(wǎng)2.5其他關(guān)鍵技術(shù)此外，大數(shù)據(jù)流式計算系統(tǒng)也離不開其他相關(guān)關(guān)鍵技術(shù)的支持，包括：系統(tǒng)故障恢復。快速地實現(xiàn)從故障狀態(tài)到一種正確狀態(tài)的恢復，滿足系統(tǒng)的高效運行需求；系統(tǒng)資源調(diào)度。實現(xiàn)對系統(tǒng)中資源的最佳利用，提高資源的利用率，保證任務(wù)的完成和能耗的節(jié)省；負載均衡策略。實現(xiàn)對系統(tǒng)中的任務(wù)的動態(tài)、合理的分配，動態(tài)適應(yīng)系統(tǒng)負載情況，保證系統(tǒng)中的任務(wù)均衡和穩(wěn)定地運行；數(shù)據(jù)在任務(wù)拓撲中的路由策略。促進系統(tǒng)中負載均衡策略的高效實現(xiàn)、數(shù)據(jù)的合理流動及快速處理。

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

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

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

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

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

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

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

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

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

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

　　Storm系統(tǒng)存在的不足主要包括：資源分配沒有考慮任務(wù)拓撲的結(jié)構(gòu)特征，無法適應(yīng)數(shù)據(jù)負載的動態(tài)變化；采用集中式的作業(yè)級容錯機制，在一定程度上限制了系統(tǒng)的可擴展性。

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

　　（函數(shù)）（事件類型）（主鍵）（鍵值）4處理單元PE處理單元PE只關(guān)心與其事件類型相匹配的事件，并僅僅處理與其主鍵、鍵值相一致的事件，即，只有事件類型、主鍵、鍵值全部匹配后，處理單元PE才會處理該類事件。當一個新事件沒有可以匹配的處理單元PE時，系統(tǒng)將會為該事件新創(chuàng)建一個處理單元PE.因此，需要高效、動態(tài)地創(chuàng)建、管理和刪除處理單元PE；同時，處理單元PE的類型設(shè)計及其拓撲結(jié)構(gòu)也需要更合理地規(guī)劃。

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

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

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

　　5描述了一個統(tǒng)計Topi熱點單詞的實例。

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

　　表4數(shù)據(jù)流內(nèi)容數(shù)據(jù)流事件類型主鍵鍵值查詢無單詞統(tǒng)計單詞數(shù)更新匯總降序輸出無在S4的處理節(jié)點Pnode中，如6所示，由處理空間和傳輸空間組成，其中，84處理節(jié)點空間在處理空間中，事件監(jiān)聽系統(tǒng)主要用于監(jiān)聽并分發(fā)接收到的事件計算請求，并由調(diào)度分配系統(tǒng)將事件分配到處理單元集PEC（processingelementcontainer）上進行計算，處理單元集PEC以適當?shù)捻樞蛘{(diào)用適當?shù)奶幚韱卧狿E，并保證每個主鍵A：e>的處理單元PE都會被映射到一個確定的處理節(jié)點Pnode上。

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

　　系統(tǒng)架構(gòu)處理單元集PEC用戶空間S4采用了對等式系統(tǒng)架構(gòu)，如7所示。

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

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

　　數(shù)據(jù)傳輸通道和大數(shù)據(jù)流式計算系統(tǒng)。

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

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

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

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

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

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

　　數(shù)據(jù)存儲Kafka消息系統(tǒng)通過僅僅進行數(shù)據(jù)追加的方式實現(xiàn)對磁盤數(shù)據(jù)的持久化保存，實現(xiàn)了對大數(shù)據(jù)的穩(wěn)定存儲，并有效地提高了系統(tǒng)的計算能力。通過采用Sendfile系統(tǒng)調(diào)用方式優(yōu)化了網(wǎng)絡(luò)傳輸，減少了1次內(nèi)存拷貝，提高了系統(tǒng)的吞吐量，即使對于普通的硬件，Kafka消息系統(tǒng)也可以支持每秒數(shù)十萬的消息處理能力。此外，在Kafka消息系統(tǒng)中，通過僅保存訂閱者已經(jīng)計算數(shù)據(jù)的偏量信息，一方面可以有效地節(jié)省數(shù)據(jù)的存儲空間，另一方面，也簡化了系統(tǒng)的計算方式，方便了系統(tǒng)的故障恢復。

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

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

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

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

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

　　TimeStream中的數(shù)據(jù)計算邏輯是基于數(shù)據(jù)流DAG實現(xiàn)的，如1所示，在數(shù)據(jù)流DAG中的每個頂點V，在獲取輸入數(shù)據(jù)流/后，觸發(fā)相關(guān)操作/產(chǎn)生新數(shù)據(jù)流，并更新頂點v的狀態(tài)從ljA即，（A）=/v（M）。

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

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

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

　　狀態(tài)的恢復是通過對數(shù)據(jù)流DAG中的依賴關(guān)系跟蹤機制來實現(xiàn)，并盡可能全面地進行系統(tǒng)狀態(tài)的恢復。

　　在TimeStream的系統(tǒng)結(jié)構(gòu)中，實現(xiàn)了資源分配、節(jié)點調(diào)度、故障檢測等功能。

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

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

　　3.6對比分析系統(tǒng)進行了對比分析。

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

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

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

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

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

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

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

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

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

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

　　大數(shù)據(jù)流式計算環(huán)境中的負載均衡問題的解決，需要結(jié)合具體的應(yīng)用場景，系統(tǒng)地分析和總結(jié)隱藏在大數(shù)據(jù)流式計算中的數(shù)據(jù)流變化的基本特征和內(nèi)在規(guī)律，結(jié)合傳統(tǒng)系統(tǒng)負載均衡的經(jīng)驗，根據(jù)實踐檢驗情況，不斷進行相關(guān)機制的持續(xù)優(yōu)化和逐步完善。

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

　　大數(shù)據(jù)流式計算環(huán)境中的數(shù)據(jù)吞吐量問題的解決，一方面需要從硬件的角度進行系統(tǒng)的優(yōu)化，設(shè)計出更符合大數(shù)據(jù)流式計算環(huán)境的硬件產(chǎn)品，在數(shù)據(jù)的計算能力上實現(xiàn)大幅提升；另一方面，更為重要的是，從系統(tǒng)架構(gòu)的設(shè)計中進行優(yōu)化和提升，設(shè)計出更加符合大數(shù)據(jù)流式計算特征的數(shù)據(jù)計算邏輯。

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

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

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

　　在未來的研究工作中，將進一步深化對大數(shù)據(jù)流式計算架構(gòu)及其關(guān)鍵技術(shù)的研究，并結(jié)合詳細的應(yīng)用需求，開發(fā)、部署、測試并優(yōu)化面向特定應(yīng)用領(lǐng)域的大數(shù)據(jù)流式計算系統(tǒng)，進一步推動大數(shù)據(jù)流式計算理論、方法、技術(shù)與系統(tǒng)的研究與發(fā)展。