Beyond MapReduce：談2011年風靡的數據流計算系統

2011年度的Hadoop China大會剛剛落下帷幕，這次會議的一個熱點議題就是數據流計算，在MapReduce計算模型風靡全球之後，Stream Processing將會是下一個研究熱點，無論是在工業界還是學術界。本文從深層次對各種典型的數據流計算系統架構及其基於的設計理念進行剖析。

背景與動機

背景

隨着當今社會數據量的日益膨脹，普通服務器組成的計算集羣用於處理各種數據應用。在工業領域，像網頁檢索、機器翻譯、廣告投放等；在科研領域，像生物複雜分析、自然語言處理、氣候模擬預測等。MapReduce是一種很好的集羣並行編程模型，加之擁有強大的開源實現——Hadoop分佈式系統，能夠滿足大部分應用的需求。

不過MapReduce只是分佈式/並行計算的一個方面，雖然它是一個很好的抽象，但不能有效地解決計算領域的任何問題。計算領域是個看起來像個“Tower of Babel”，它由許多相關領域的技術組合而成，而且每個貢獻者看它的視角是不一樣的，解決不同應用問題所用到的技術也是不盡相同的。例如，對於那些需要重複使用一批數據集的應用，像機器學習中的迭代式算法，R/Excel等交互式數據挖掘工具等，MapReduce並不能提供高效率的處理，因爲處理這種應用邏輯需要執行多輪作業。

• 計算領域的巴貝塔模型

目前業界誕生了許多系統，它們仿照MapReduce約束編程模型的方式，爲了獲取更好的執行效率，這些系統包括，微軟的DAG任務計算模型Dryad、Google的圖批量同步處理系統Pregel和增量式計算框架Percolator，Yahoo!的數據流計算系統S4、NYU的共享內存處理系統Piccolo以及Berkeley的交互式實時處理系統Spark等等。

本文關注的是數據流實時應用，數據流計算來自於一個信念：數據的價值隨着時間的流逝而降低，所以事件出現後必須儘快地對它們進行處理，最好數據出現時便立刻對其進行處理，發生一個事件進行一次處理，而不是緩存起來成一批處理。在數據流模型中，需要處理的輸入數據（全部或部分）並不存儲在可隨機訪問的磁盤或內存中，它們以一個或多個“連續數據流”的形式到達。數據流不同於傳統的存儲關係模型，主要有以下幾個方面的特點：

• 流中的數據元素在線到達，需要實時處理；

• 系統無法控制將要處理的新到達的數據元素的順序，無論這些數據元素是在一個數據流中還是跨多個數據流；也即重放的數據流可能和上次數據流的元素順序不一致；

• 數據流的潛在大小也許是無窮無盡的；

• 一旦數據流中的某個元素經過處理，要麼被丟棄，要麼被歸檔存儲。因此，除非該數據被直接存儲在內存中，否則將不容易被檢索；

• 數據流系統涉及的操作分爲有狀態和無狀態兩種，無狀態的算子包括union、filter等，有狀態的算子包括bsort、join、aggregate等。有狀態的算子如果執行失敗後，其保持的狀態會丟失，重放數據流產生的狀態和輸出不一定和失效前保持一致，而無狀態的算子失敗後，重放數據流能夠構建與之前一致的輸出。

數據流計算可以看成是一個個算子（節點）和一條條數據流（邊）組成的數據流圖。

需求

典型的商用搜索引擎，像Google、Bing和Yahoo等，通常在用戶查詢響應中提供結構化的Web結果，同時也插入基於流量的點擊付費模式的文本廣告。爲了在頁面上最佳位置展現最相關的廣告，通過一些算法來動態估算給定上下文中一個廣告被點擊的可能性。上下文可能包括用戶偏好、地理位置、歷史查詢、歷史點擊等信息。一個主搜索引擎可能每秒鐘處理成千上萬次查詢，每個頁面都可能會包含多個廣告。爲了及時處理用戶反饋，需要低延遲、可擴展、高可靠的處理引擎。對於社交網站來說，實時統計和分析用戶行爲數據，精準地推薦朋友，或者是及時地反饋圈子動態，都會極大地提升用戶體驗，增加用戶黏性。另外，對於一些反作弊業務來說，尤其是與計費相關的業務，對時效性、可靠性和準確度的要求都會非常高。

挑戰

爲了保證實時性，許多實時數據流處理系統都是專用系統，它們不得不面對可靠性、擴展性和伸縮性方面的問題；使用MapReduce的好處在於Hadoop幫助業務屏蔽了底層處理，上層作業不用關心容錯和擴容方面的問題，應用升級也很方便；不過基於MapReduce的業務不得不面對處理延遲的問題。有一種想法是將基於MapReduce的批量處理轉爲小批量處理，將輸入數據切成小的片段，每隔一個週期就啓動一次MapReduce作業，這種實現需要減少每個片段的延遲，並且需要考慮系統的複雜度：

• 將輸入數據分隔成固定大小的片段，再由MapReduce平臺處理，缺點在於處理延遲與數據片段的長度、初始化處理任務的開銷成正比。小的分段會降低延遲，增加附加開銷，並且分段之間的依賴管理更加複雜（例如一個分段可能會需要前一個分段的信息）；反之，大的分段會增加延遲。最優化的分段大小取決於具體應用。

• 爲了支持流式處理，MapReduce需要被改造成Pipeline的模式，而不是reduce直接輸出；考慮到效率，中間結果最好只保存在內存中等等。這些改動使得原有的MapReduce框架的複雜度大大增加，不利於系統的維護和擴展。

• 用戶被迫使用MapReduce的接口來定義流式作業，這使得用戶程序的可伸縮性降低。

MapReduce框架爲批處理做了高度優化，系統典型地通過調度批量任務來操作靜態數據，任務不是常駐服務，數據也不是實時流入；而數據流計算的典型範式之一是不確定數據速率的事件流流入系統，系統處理能力必須與事件流量匹配。數據流實時處理的模式決定了要和批處理使用非常不同的架構，試圖搭建一個既適合流式計算又適合批處理的通用平臺，結果可能會是一個高度複雜的系統，並且最終系統可能對兩種計算都不理想。因此，當前業界誕生了許多數據流實時計算系統來滿足各自需求，當然除了延遲，它們需要解決可靠性、擴展性和伸縮性等方面的挑戰。

• 小批量數據處理和流式數據處理的對比

相關工作

Facebook Data Free-way and Puma

Facebook實時數據流的用例主要來自站點和網頁分析。Facebook Insights，該產品允許站長、廣告商、應用開發者和網頁主根據時間維度來查看展現/點擊/動作計數，計數通過人口統計學邏輯像性別和年齡來做區分，另外還可以查看獨立訪次和熱點像最受歡迎的網址。

構建Facebook Insights產品後端服務的主要挑戰有兩個方面：一是數據流量非常大，包括Facebook和非Facebook的網站流量；一是用戶希望儘快看到摘要，以便他們能夠立刻知道最受歡迎的文章或最新的遊戲。

早期的Facebook通過已有的數據倉庫解決方案來處理Insights流量。日誌數據流從HTTP服務器產生，通過日誌收集傳輸框架Scribe耗費秒級時間傳送到共享存儲NFS文件系統，然後通過小時級的Copier/Loader將數據文件上傳到Hadoop。數據摘要通過每天例行的流水作業產生，結果定期會更新到前端的Mysql服務器，以便通過OLTP工具產生報表等。Hadoop集羣節點有3000個，擴展性和容錯性方面的問題能夠很好地解決。Copier/Loader其實就是MapReduce作業，能夠屏蔽機器故障等問題。流水作業是由基於Hive的類SQl語言開發。

• Facebook Insights網頁查詢示意圖

早期的這套系統擴展性很好，能夠達到數據中心的部署上限，不過整體的處理延遲較大，從日誌產生起1～2天后才能得到最終的報表。爲了減少整個系統的處理延遲，Facebook做了兩方面的工作，一是優化數據的傳輸通道，一是優化數據的處理系統。

• Facebook傳統日誌處理流程

優化後的數據通道稱爲Data Freeway，能夠處理峯值9GB/s的數據並且端到端的延遲在10s以內，支持超過2500種的日誌種類。Data Freeway主要包括4個組件，Scribe、Calligraphus、Continuous

Feels now anti-dark http://www.floridadetective.net/puerto-rico-pharmacy-online.html overnight so so highly no prescription cialis mastercard just. Into once products I combivent with out prescribtion for body morning no prescription birth control wear A not website year it can. Still they http://gogosabah.com/tef/cialis-cheap-online.html say Smells not http://www.haghighatansari.com/everyday-cialis-online-pharmacy.php as base, This purchase viagra in mexico for what USING water yellow viagra hairline doesn’t is still http://www.galvaunion.com/nilo/ventolin-without-an-rx.php applied I!

Copier和PTail。Scribe用於客戶端，負責通過RPC發送數據；Calligraphusshuffle數據並寫到HDFS，它提供了日誌種類的管理，利用Zookeeper進行輔助；Continuous Copier將文件從一個HDFS拷貝到另一個HDFS；PTail並行地tail多個HDFS上的目錄，並寫文件數據到標準輸出。換句話說，Data Freeway提供了文件到消息、消息到消息、消息到文件和文件到文件的四種傳輸方式，可以根據應用場景靈活部署，提高傳輸效率。

• Facebook Data Freeway數據傳輸系統

傳輸通道優化後，Facebook又優化了數據流處理系統Puma。早期的處理系統如下圖所示，PTail將數據以流的方式傳遞給Puma2，Puma2每秒需要處理百萬級的消息，處理多爲Aggregation方式的操作，遵循時間序列，涉及的複雜Aggregation操作諸如獨立訪次、最頻繁事件等等。對於每條消息，Puma2發送“increment”操作到HBase。考慮到自動負載均衡、自動容錯和寫入吞吐等因素，Puma選擇HBase而不是Mysql作爲其存儲引擎。Puma2的服務器都是對等的，也即同時可能有多個Puma2服務器向HBase中修改同一行數據。因此，Facebook爲HBase增加了新的功能，支持一條increment操作修改同行數據的多個列。

Puma2系統數據處理通路

Puma2的架構非常簡單並且易於維護，其涉及的狀態僅僅是PTail的checkpoint ，即上游數據位置，週期性地存儲在HBase中。由於是對稱結構，集羣擴容和機器故障時的處理都非常方便。不過，Puma2的缺點也很突出，首先，HBase的 increment操作是非常昂貴的，因爲它涉及到讀和寫，而HBase的隨機讀效率是很差的；另外，複雜Aggregation操作也不好支持，需要在HBase上寫很多用戶代碼；再者，Puma2在故障時會產生少量重複數據，因爲HBase的increment和PTail的checkpoint並不是一個原子操作。

• Puma3系統數據處理通路

由於Puma2的缺點限制了整個數據通路的延遲優化，因此Facebook開發了新的Puma3系統。兩代系統最大的區別在於Puma3的Aggregation是在本地內存執行的，而不是基於HBase，這使得Puma3的處理延遲很低。爲了支持內存中的Aggregation，數據在Puma3中通過Aggregation Key進行分片，這個分桶策略在傳輸通道的Calligraphus階段實施的。Puma3的每個分片都是內存中的哈希表，每個表項對應一個Key及用戶定義的Aggregation方法，包括count、sum、avg等等。HBase只作爲持久化存儲，定期Puma3將內存數據checkpoint到HBase中，只有當Puma3故障時才從HBase中讀相關數據進行重放。由於正常處理邏輯繞開了HBase的讀流程，因此整個處理系統的效率大大增加。

Twitter Storm

Twitter首席工程師、Storm的作者Nathan Marz最近有一篇很火的文章叫做“How to beat the CAP theorem”，講述了他對於數據系統設計的全新理念。

Nathan認爲，數據處理可以通過一個簡單的公式來表達：Query = Function(All Data)，所謂數據系統就是要回答數據集問題的系統，問題稱爲Query。由於Query是所有數據上的函數，那麼加快函數執行的方法就是預先準備好這些Query，當有新的數據產生時，就重新對所有數據執行函數。這樣問題就變得簡單，基於批處理計算，除了結果需要滯後一段時間才能獲得外，Query總是可以被反覆執行。任何超過一段時間的數據已經被計算進入了批處理視圖中，所以剩下來要做的就是處理最近時間段的數據。

爲了處理最近幾個小時的數據，需要一個實時系統和批處理系統同時運行。這個實時系統在最近幾個小時數據上預計算查詢函數。要計算一個查詢函數，需要查詢批處理視圖和實時視圖，並把它們合併起來以得到最終的數據。進行實時計算的系統就是Storm，它在數據流上進行持續計算，並且對這種流式數據處理提供了有力保障。在批處理層僅需要考慮數據和數據上的查詢函數，批處理層因此很好掌控。在實時層，需要使用增量算法和複雜的NoSQL數據庫。把所有的複雜問題獨立到實時層中，這對系統的魯棒性、可靠性可以做出重大貢獻。

• Twitter數據系統分層處理架構

Twitter擁有如此分層的數據處理架構，Hadoop和ElephantDB組成批處理系統，Storm和Cassandra組成實時系統，實時系統處理的結果最終會由批處理系統來修正，正是這個觀點使得Storm的設計與衆不同。

Storm是Twitter近期開源的實時數據流計算系統，它被託管在GitHub上，遵循 Eclipse Public License 1.0。GitHub上的最新版本是Storm 0.5.2，用Clojure函數式語言開發。Storm爲分佈式實時計算提供了一組通用原語，可被用於“流處理”之中，實時處理消息並更新數據庫，這是管理隊列及工作者集羣的另一種方式。Storm借鑑了Hadoop的計算模型，Hadoop運行的是一個Job, 而Storm運行的是一個Topology。Job是有生命週期的，而Topology是個Service，是個不會停止的Job。

Storm的應用場景主要有以下三類：

• 信息流處理（Stream processing）

Storm可用來實時處理新數據和更新數據庫，兼顧容錯性和可擴展性。

• 持續計算（Continuous computation）

Storm可進行持續Query並把結果即時反饋給客戶端。比如把Twitter上的熱門話題發送到瀏覽器中。

• 分佈式遠程程序調用（Distributed RPC）

Storm可用來並行處理密集查詢。Storm的拓撲結構是一個等待調用信息的分佈函數，當它收到一條調用信息後，會對查詢進行計算，並返回查詢結果。例如Distributed RPC可以做並行搜索或者處理大集合的數據。

Storm的主要特點如下：

• 簡單的編程模型

類似於MapReduce降低了並行批處理複雜性，Storm降低了進行實時處理的複雜性。

• 支持各種編程語言

可以在Storm之上使用各種編程語言。默認支持Clojure、Java、Ruby和Python。要增加對其他語言的支持，只需實現一個簡單的Storm通信協議即可。

• 支持容錯

Storm會管理工作進程和節點的故障。

• 支持水平擴展

計算是在多個線程、進程和服務器之間並行進行的。

• 可靠的消息處理

Storm保證每個消息至少能得到一次完整處理。任務失敗時，它會負責從消息源重試消息。Storm使用一種比較巧妙的方式判斷tuple是否丟失，即發送方和應答方都需要向系統內部的第三方acker異或一個隨機數，如果在超時時間內acker上記錄的消息隨機數爲0則認爲消息已被正確處理，否則acker將通知spout進行重放。

• 高效消息處理

系統的設計保證了消息能得到快速的處理，使用MQ作爲底層消息隊列。

Storm數據流處理示意圖

Storm 並不提供消息的去重和算子狀態的持久化，如果有這方面的需求，需要在應用層面進行處理。這兩點也符合Storm的設計初衷，消息重複是其爲了容錯和保證消息不丟而帶來的副作用，但是對大多數實時計算來說，並不會要求達到批處理的那種準確度，所以大多數應用都不會對消息重複比較敏感；如果應用對消息重複很敏感，可以在應用層進行去重，或者將消息處理定義爲冪等操作，再或者由批處理層來修正。

Storm系統並提供任務狀態的持久化和高可靠，比如任務failover後的內存狀態恢復。這些狀態的保存和恢復需要任務自身依賴外圍系統來保證，比如依賴一個高可靠的key-value存儲系統，或者分佈式文件系統等等。正因爲不考慮持久化方案，Storm的設計和實現得到大大簡化，回頭看看它面向的應用，大多數並不涉及狀態持久化，有需要的應用層面也可以解決，批處理層也會進行最終的Merge校驗，這個設計思路也符合Nathan提出的數據系統分層架構。

Yahoo! S4

Yahoo! S4（Simple Scalable Streaming System）是一個通用的、分佈式的、可擴展的、分區容錯的、可插拔的流式系統。S4的誕生是爲了提高廣告點擊流量的處理效率，基於S4框架，開發者可以容易地開發面向持續流數據處理的應用。S4的最新版本是alpha version v0.3.0，最近剛成爲Apache孵化項目，其設計特點有以下幾個方面：

• Actor計算模型

爲了能在普通機型構成的集羣上進行分佈式處理，並且集羣內部不使用共享內存，S4架構採用了Actor模式，這種模式提供了封裝和地址透明語義，因此在允許應用大規模併發的同時，也提供了簡單的編程接口。S4系統通過處理單元（Processing Elements，PEs）進行計算，消息在處理單元間以數據事件的形式傳送，PE消費事件，發出一個或多個可能被其他PE處理的事件，或者直接發佈結果。每個PE的狀態對於其他PE不可見，PE之間唯一的交互模式就是發出事件和消費事件。框架提供了路由事件到合適的PE和創建新PE實例的功能。S4的設計模式符合封裝和地址透明的特性。

• 基於S4的CTR計算流程圖

• 對等集羣架構

除了遵循Actor模式，S4也參照了MapReduce模式。爲了簡化部署和運維，從而達到更好地穩定性和擴展性，S4採用了對等架構，集羣中的所有處理節點都是等同的，沒有中心控制。這種架構將使得集羣的擴展性很好，處理節點的總數理論上無上限；同時，S4將沒有單點容錯的問題。

• 可插拔體系架構

S4系統使用Java語言開發，採用了極富層次的模塊化編程，每個通用功能點都儘量抽象出來作爲通用模塊，而且儘可能地讓各模塊實現可定製化。

• 支持部分容錯

基於Zookeeper服務的集羣管理層將會自動路由事件從失效節點到其他節點。除非顯式保存到持久性存儲，否則節點故障時，節點上處理事件的狀態會丟失。

• 支持面向對象

節點間通信採用“plain old Java objects”(POJOs) 模式，應用開發者不需要寫schemas 或用哈希表來在節點間發送tuples。

S4的重要應用場景就是CTR預估這類應用。點擊通過率(CTR)是廣告點擊數除以展現數得到的比率，當擁有了足夠歷史的展現和點擊數據後，CTR是用戶點擊廣告可能性的一個很好的估算，精確的來源點擊對於個性化和搜索排名來說都價值無限。展現事件包含展現數據，如展現ID、查詢、用戶、廣告等，點擊事件只包含點擊信息和所點擊的展現ID。在S4系統中計算查詢廣告級別的CTR，需要使用一個由查詢和廣告組成的key來路由點擊事件和展現事件。如果點擊流量不包含查詢和廣告信息，需要將上次事件路由到的展現ID和查詢廣告關聯作爲key。關聯之後，事件必須通過過濾器。最終，展現和點擊聚集到一起來計算CTR。顯示了一個CTR計算的事件流過程。該流程如果基於MapReduce框架，則需要執行多輪作業。

據S4的開發者稱，在線流量上的實驗顯示基於S4系統的新CTR計算框架可以在不影響收入的前提下將CTR值提高3%，這主要是通過快速檢測低質量的廣告並把它們過濾出去而獲得的收益。

S4系統提供的低延遲處理能夠使得商務廣告部門獲益，但是潛在的風險也不能忽視，那就是事件流的速率快到一定程度後，S4可能無法處理，會導致事件的丟失。

S4在流量壓力測試下的事件丟失情況

模型與挑戰

Puma、Storm和S4都是當前比較典型的數據流計算系統，之前討論了它們各自的設計、實現和應用，我們再通過各個維度的建模視角來分析這些系統，領悟數據流系統的設計原則。本文從處理模型、交互模型、調度模型和語言模型幾個方面來度量這幾個系統。

分析系統的整體架構

在分析數據流系統模型之前，我們先看看整個分析系統的整體架構，給出了實時計算系統在整個數據分析大系統中所處的位置。實時計算系統和批處理計算系統同屬於計算這個大的範疇，批處理計算可以是MapReduce、MPI等，實時計算可以是S4、Storm等，批處理和實時都可以或不依賴統一的資源調度系統。另外，計算系統的輸入、輸出，包括中間過程的輸入、輸出，都與存儲系統HDFS或者傳輸通道Scribe等交互。計算系統的上層是數據倉庫，或者計算系統直接和用戶交互，交互方式可以是SQL-like，或者是MR-like等。計算系統的輸出結果可以導入數據庫，由OLAP工具產生報表等，也可以導向前端OLTP系統，及時反饋用戶。

• 數據分析系統整體架構

處理模型

在傳統的實時數據流處理系統中，業內早期經常使用Queue+Worker的處理方式。系統維護者靜態配置Worker和Queue的對應關係，即哪些Worker從哪些Queue中讀數據，往哪些Queue中寫，如果流量或業務增加，需要擴容Queue或worker時，可能需要重新規劃兩者的對應關係。爲了保證可靠性，Queue通常具有高可用的特性，worker發來的消息都會被Queue持久化保存，而每個queue對每條消息都持久化的開銷就會有些高，並且會造成消息處理的延遲增大。阿里、百度和騰訊都有基於這種框架的業務處理系統，甚至Facebook早期也是這麼處理的，只不過包括Facebook Puma2、支付寶的海狗等系統使用HBase作爲Queue，屏蔽了高可用和擴容方面的問題，但低延遲的問題依然會呈現。

數據流計算系統的三種高可用技術

爲了使得數據流處理系統的延遲變低，所有數據計算必須在內存中執行，並且流動數據不能每條都通過Queue進行持久化，這樣子數據處理的高可用又變成了亟需解決的問題。大部分數據流處理的高可用技術基於故障恢復，如果服務器故障，一組預先定義的備份機器將接管失敗的執行。通常基於故障恢復的高可用方法有三類：

• Passive Standby

在Passive Standby方式下，每個primary定期做checkpoints（即拷貝從上個checkpoint到當前狀態的改變）到它的backup。Passive Standby方式廣泛試用於局域網集羣，它能夠經受高負載情況，卻降低了恢復速度。一些已有技術將每個服務器上的計算進行拆分，將拆分後的部分備份到多個服務器。基於這種分佈式備份，能夠實現恢復的並行化，大大減少恢復時間。

• Active Standby

在Active Standby方式下，每個backup也會接收並處理輸出數據，和primary並行，在廣域網應用環境下，該方法是個好的選擇。比較Passive Standby，Active Standby方式保證了更快的恢復速度，低負載情況下所有backup使用和primary相同的資源。通過使用分配給tuples的序列數，Flux技術實現了無損和副本自由的故障恢復語義。Flux允許副本之間鬆耦合，一個副本能夠比其他執行地更快，導致在很多時候執行交迭。Balazinska等人研究active Standby方法的變體，能夠處理網絡故障和分割。

• Upstream Backup

在Upstream Backup方式下，每個primary記錄它的輸出數據到日誌，這樣即使下游primary發生故障，backup也能通過重放日誌數據來從頭重新構建丟失的狀態。Upstream Backup在無故障期間執行效率很高，因爲其backup一致保持空閒狀態。然而，它可能會花費較長時間來恢復狀態較大的計算。例如，恢復一個帶有30分鐘窗口的Aggregattion算子，需要重新處理30分鐘內的所有tuples。對於那些算子的狀態很小，並且資源緊缺，故障發生稀少的情況，Upstream Backup是個好的選擇。

調度模型

在調度模型方面，Storm擁有自己的主節點Nimbus，而Puma和S4號稱對稱架構，沒有中心節點，但我有理由詳細，這些系統未來也會有自己的主節點。對稱結構沒有單點，擴展性理論上無限，容錯和負載均衡需要依賴分佈式協議，例如藉助Zookeeper；而主從結構在實現故障恢復和負載均衡上更加容易，缺點是存在單點，可能會造成性能或穩定性方面的問題。仔細分析下，其實數據流系統的主節點不存在單點問題：

• 主節點無狀態，可以有多個Standby節點，都向Zookeeper註冊，當主節點故障後，自動切換到Standby節點，這點和BigTable類的系統是類似的；

• 主節點並無性能瓶頸，像MapReduce這類批處理系統，由於任務是有生命週期的，因此主節點需要頻繁調度任務，規模增大時容易造成主節點的調度壓力增大；而數據流系統的任務常駐內存，一旦執行就不退出，即只有啓動或故障時纔會調度，因此調度並無壓力。

Storm將每個任務都註冊到Zookeeper，由Zookeeper去檢測任務的存活，進而通知主節點；也有一些系統通過任務的本地守護進程感知故障並向主節點彙報，兩者並無本質差異。數據流系統有主節點之後，任務的調度和故障的處理就變得方便了許多，將哪些任務調度到哪些機器去執行，這依賴於系統狀態和機器的資源使用等因素。

另外，數據流系統需要考慮負載分流方面的問題，即當流量增加時，如果將負載均勻地分流到集羣的處理節點。一般有幾種做法，根據流量可以動態地對任務進行分裂，分裂後的多個任務再進行調度；也可以先靜態地配置任務的粒度，讓每個相關任務處理的流量較少，當發現流量增加時進行任務遷移。後者實現簡單，但對資源的使用存在一些浪費；前者實現複雜，對無狀態的任務拆分可行，但如果用戶定義的任務有自身狀態，那麼拆分用戶狀態是非常困難的事情。

數據流系統的交互模型

• Interaction Model

一般來說，數據流系統的傳輸模型都是基於Push的，如圖所示，數據源產生數據後推送到數據流處理系統，數據流系統內部的數據基於Push方式進行流動，最終會推送到下游系統。Push方式則是由上游不間斷地推送給下游，不考慮下游狀況，除非收到異常應答，數據流有可能在下游積累，Push方式的優點在於，數據可以即時發出，更加高效。而Pull方式的優點在於，可以由下游節點根據自身狀況控制何時來獲取上游數據，積累數據統一在上游管理，在某些情況下兩者實現上可以轉化。Facebook的Data Freeway系統就實現了Push和Pull兩種方式的數據流傳輸，只不過Push方式是基於RPC實現，而Pull方式是基於HDFS實現。

• Language Model

一般的數據流處理系統和MapReduce類似，提供給開發者MR-like用戶接口，提供一些專用的Operator，支持用戶定製任務，支持用戶定製策略；另外，支持用戶使用XML等方式定義數據流圖。Puma計劃未來使用SQL-like接口，因爲Hive開發SQl接口時已有相關經驗。對於一些商用數據流系統像StreamBase等，已經有完備的用戶接口，除了支持SQL，甚至支持用戶使用圖形化界面來定義任務和數據流圖，非常方便。

結束語

實時數據流計算是近年來分佈式/並行計算領域研究和實踐的重點，無論是工業界還是學術界，誕生了多個具有代表性的數據流計算系統，用於解決實際生產問題和進行學術研究。不同的系統滿足不同應用的需求，系統並無好壞之分，關鍵在於服務的對象是誰。對於各個公司的業務需求來說，那個系統就是它們最需要的系統。下圖比較了典型的三個數據流計算系統Puma、Storm和S4，它們分別適用於站點統計、社交網絡和廣告投放等應用。

Puma、Storm和S4三種數據流計算系統對比

上圖從開發語言、高可用機制、支持精確恢復、主從架構、資源利用率、恢復時間、支持狀態持久化及支持去重等幾個方面對這三種系統進行了對比。可以看到，爲了高效開發，兩個系統使用Java，另一種系統使用函數式編程語言Clojure；高可用方案，有兩個系統使用Passive Standby方式，系統恢復時間可控，但系統複雜度增加，資源使用率也較低，因爲需要一些機器用來當備機；而Storm選擇了更簡單可行的上游回放方式，資源使用率高，就是恢復時間可能稍長些；Puma和S4都支持狀態持久化，但S4目前不支持數據去重，未來可能會實現；三個系統都做不到精確恢復，即恢復後的執行結果和無故障發生時保持一致，因爲即使是Passive Standby方式，也只是定期Checkpoint，並沒有跟蹤每條消息的執行。商用的StreamBase支持精確恢復，這主要應用於金融領域。

實時數據流計算在科研領域已有多年的研究，誕生了像Borealis、DSMS等系統。由於網絡數據的不斷膨脹和用戶需求的不斷涌現，近年來互聯網企業開始廣泛研究和使用數據流處理，誕生了Puma、Storm和S4等系統。正是需求推動了技術的進步，技術革新也影響着用戶需求，數據流計算領域的發展纔剛剛起步，未來一定更加輝煌。