背景

非實(shí)時計(jì)算幾乎都基于MapReduce計(jì)算框架，但MapReduce并不是萬能的。對于搜索應(yīng)用環(huán)境中的某些現(xiàn)實(shí)問題，MapReduce并不能很好地解決問題。

商用搜索引擎，像Google、Bing和Yahoo!等，通常在用戶查詢響應(yīng)中提供結(jié)構(gòu)化的Web結(jié)果，同時也插入基于流量的點(diǎn)擊付費(fèi)模式的文本廣告。為了在頁面上最佳位置展現(xiàn)最相關(guān)的廣告，通過一些算法來動態(tài)估算給定上下文中一個廣告被點(diǎn)擊的可能性。上下文可能包括用戶偏好、地理位置、歷史查詢、歷史點(diǎn)擊等信息。一個主搜索引擎可能每秒鐘處理成千上萬次查詢，每個頁面都可能會包含多個廣告。為了及時處理用戶反饋，需要一個低延遲、可擴(kuò)展、高可靠的處理引擎。然而，對于這些實(shí)時性要求很高的應(yīng)用，盡管MapReduce作了實(shí)時性改進(jìn)，但仍很難穩(wěn)定地滿足應(yīng)用需求。因?yàn)镠adoop為批處理作了高度優(yōu)化，MapReduce系統(tǒng)典型地通過調(diào)度批量任務(wù)來操作靜態(tài)數(shù)據(jù)；而流式計(jì)算的典型范式之一是不確定數(shù)據(jù)速率的事件流流入系統(tǒng)，系統(tǒng)處理能力必須與事件流量匹配，或者通過近似算法等方法優(yōu)雅降級，通常稱為負(fù)載分流（load-shedding）。當(dāng)然，除了負(fù)載分流，流式計(jì)算的容錯處理等機(jī)制也和批處理計(jì)算不盡相同。

最近Facebook在Sigmod 11上發(fā)表了利用HBase/Hadoop進(jìn)行實(shí)時數(shù)據(jù)處理的論文，通過一些實(shí)時性改造，讓批處理計(jì)算平臺也具備實(shí)時計(jì)算的能力。這類基于MapReduce進(jìn)行流式處理的方案有三個主要缺點(diǎn)。

• 將輸入數(shù)據(jù)分隔成固定大小的片段，再由MapReduce平臺處理，缺點(diǎn)在于處理延遲與數(shù)據(jù)片段的長度、初始化處理任務(wù)的開銷成正比。小的分段會降低延遲，增加附加開銷，并且分段之間的依賴管理更加復(fù)雜（例如一個分段可能會需要前一個分段的信息）；反之，大的分段會增加延遲。最優(yōu)的分段大小取決于具體應(yīng)用。

• 為了支持流式處理，MapReduce需要被改造成Pipeline的模式，而不是Reduce直接輸出；考慮到效率，中間結(jié)果最好只保存在內(nèi)存中等。這些改動使得原有的MapReduce框架的復(fù)雜度大大增加，不利于系統(tǒng)的維護(hù)和擴(kuò)展。

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

綜上所述，流式處理的模式?jīng)Q定了要和批處理使用非常不同的架構(gòu)，試圖搭建一個既適合流式計(jì)算又適合批處理計(jì)算的通用平臺，結(jié)果可能會是一個高度復(fù)雜的系統(tǒng)，并且最終系統(tǒng)可能對兩種計(jì)算都不理想。

目前流式計(jì)算是業(yè)界研究的一個熱點(diǎn)，最近Twitter、LinkedIn等公司相繼開源了流式計(jì)算系統(tǒng)Storm、Kafka等，加上Yahoo!之前開源的S4，流式計(jì)算研究在互聯(lián)網(wǎng)領(lǐng)域持續(xù)升溫。不過流式計(jì)算并非最近幾年才開始研究，傳統(tǒng)行業(yè)像金融領(lǐng)域等很早就已經(jīng)在使用流式計(jì)算系統(tǒng)，比較知名的有StreamBase、Borealis等。

本文簡單介紹幾種業(yè)界使用的流式計(jì)算系統(tǒng)，希望流式系統(tǒng)的設(shè)計(jì)者或開發(fā)者們能從中獲得啟示。

圖1 數(shù)據(jù)分析系統(tǒng)整體組成示意圖

圖1從整個分析系統(tǒng)的架構(gòu)角度，給出了實(shí)時計(jì)算子系統(tǒng)所處的位置。實(shí)時計(jì)算系統(tǒng)和批處理計(jì)算系統(tǒng)同屬于計(jì)算這個大的范疇，批處理計(jì)算可以是MapReduce、MPI、SCOPE等，實(shí)時計(jì)算可以是S4、Storm等，批處理和實(shí)時都可以或不依賴統(tǒng)一的資源調(diào)度系統(tǒng)。另外，計(jì)算系統(tǒng)的輸入、輸出，包括中間過程的輸入、輸出，都與存儲系統(tǒng)交互，可以是塊存儲系統(tǒng)HDFS，也可以是K-V存儲系統(tǒng)Hypertable等。計(jì)算層的上層是數(shù)據(jù)倉庫，或者直接和用戶交互，交互方式可以是SQL-like或者M(jìn)R-like等。

系統(tǒng)

S4

S4是一個通用的、分布式的、可擴(kuò)展的、分區(qū)容錯的、可插拔的流式系統(tǒng)?；赟4框架，開發(fā)者可以輕松開發(fā)面向持續(xù)流數(shù)據(jù)處理的應(yīng)用。

S4的設(shè)計(jì)特點(diǎn)有以下幾個方面。

• Actor Model

為了能在普通機(jī)型構(gòu)成的集群上進(jìn)行分布式處理，并且集群內(nèi)部不使用共享內(nèi)存，S4架構(gòu)采用了Actor模式，這種模式提供了封裝和地址透明語義，因此在允許應(yīng)用大規(guī)模并發(fā)的同時，也提供了簡單的編程接口。S4系統(tǒng)通過處理單元（Processing Elements，PEs）進(jìn)行計(jì)算，消息在處理單元間以數(shù)據(jù)事件的形式傳送，PE消費(fèi)事件，發(fā)出一個或多個可能被其他PE處理的事件，或者直接發(fā)布結(jié)果。每個PE的狀態(tài)對于其他PE不可見，PE之間唯一的交互模式就是發(fā)出事件和消費(fèi)事件?？蚣芴峁┝寺酚墒录胶线m的PE和創(chuàng)建新PE實(shí)例的功能。S4的設(shè)計(jì)模式符合封裝和地址透明的特性。

• Decentralized and Symmetric Architecture

除了遵循Actor模式，S4也參照了MapReduce模式。為了簡化部署和運(yùn)維，從而達(dá)到更好地穩(wěn)定性和擴(kuò)展性，S4采用了對等架構(gòu)，集群中的所有處理節(jié)點(diǎn)都是等同的，沒有中心控制。這種架構(gòu)將使得集群的擴(kuò)展性很好，處理節(jié)點(diǎn)的總數(shù)理論上無上限；同時，S4將沒有單點(diǎn)容錯的問題。
Pluggable Architecture
S4系統(tǒng)使用Java開發(fā)，采用了極富層次的模塊化編程，每個通用功能點(diǎn)都盡量抽象出來作為通用模塊，而且盡可能讓各模塊實(shí)現(xiàn)可定制化。

• Partial Fault-Tolerance

基于Zookeeper服務(wù)的集群管理層將會自動路由事件從失效節(jié)點(diǎn)到其他節(jié)點(diǎn)。除非顯式保存到持久性存儲，否則節(jié)點(diǎn)故障時，節(jié)點(diǎn)上處理事件的狀態(tài)會丟失。

• Object Oriented

節(jié)點(diǎn)間通信采用“Plain Old Java Objects”（POJOs）模式，應(yīng)用開發(fā)者不需要寫Schemas 或用哈希表來在節(jié)點(diǎn)間發(fā)送Tuples。

S4的功能組件分3大類，Clients、Adapters和PNode Cluster，圖2顯示了S4系統(tǒng)框架。