http://www.programmer.com.cn/8606/
本文系統地介紹和分析比較了業界主流的Yahoo! S4、StreamBase和Borealis三種流式計算系統，希望讀者能從這些系統的設計中領悟到不同場景下流式計算所要解決的關鍵問題。
背景
非實時計算幾乎都基於MapReduce計算框架，但MapReduce並不是萬能的。對於搜索應用環境中的某些現實問題，MapReduce並不能很好地解決問題。
商用搜索引擎，像Google、Bing和Yahoo!等，通常在用戶查詢響應中提供結構化的Web結果，同時也插入基於流量的點擊付費模式的文本廣告。爲了在頁面上最佳位置展現最相關的廣告，通過一些算法來動態估算給定上下文中一個廣告被點擊的可能性。上下文可能包括用戶偏好、地理位置、歷史查詢、歷史點擊等信息。一個主搜索引擎可能每秒鐘處理成千上萬次查詢，每個頁面都可能會包含多個廣告。爲了及時處理用戶反饋，需要一個低延遲、可擴展、高可靠的處理引擎。然而，對於這些實時性要求很高的應用，儘管MapReduce作了實時性改進，但仍很難穩定地滿足應用需求。因爲Hadoop爲批處理作了高度優化，MapReduce系統典型地通過調度批量任務來操作靜態數據；而流式計算的典型範式之一是不確定數據速率的事件流流入系統，系統處理能力必須與事件流量匹配，或者通過近似算法等方法優雅降級，通常稱爲負載分流（load-shedding）。當然，除了負載分流，流式計算的容錯處理等機制也和批處理計算不盡相同。
最近Facebook在Sigmod 11上發表了利用HBase/Hadoop進行實時數據處理的論文，通過一些實時性改造，讓批處理計算平臺也具備實時計算的能力。這類基於MapReduce進行流式處理的方案有三個主要缺點。
- 將輸入數據分隔成固定大小的片段，再由MapReduce平臺處理，缺點在於處理延遲與數據片段的長度、初始化處理任務的開銷成正比。小的分段會降低延遲，增加附加開銷，並且分段之間的依賴管理更加複雜（例如一個分段可能會需要前一個分段的信息）；反之，大的分段會增加延遲。最優的分段大小取決於具體應用。
- 爲了支持流式處理，MapReduce需要被改造成Pipeline的模式，而不是Reduce直接輸出；考慮到效率，中間結果最好只保存在內存中等。這些改動使得原有的MapReduce框架的複雜度大大增加，不利於系統的維護和擴展。
- 用戶被迫使用MapReduce的接口來定義流式作業，這使得用戶程序的可伸縮性降低。
綜上所述，流式處理的模式決定了要和批處理使用非常不同的架構，試圖搭建一個既適合流式計算又適合批處理計算的通用平臺，結果可能會是一個高度複雜的系統，並且最終系統可能對兩種計算都不理想。
目前流式計算是業界研究的一個熱點，最近Twitter、LinkedIn等公司相繼開源了流式計算系統Storm、Kafka等，加上Yahoo!之前開源的S4，流式計算研究在互聯網領域持續升溫。不過流式計算並非最近幾年纔開始研究，傳統行業像金融領域等很早就已經在使用流式計算系統，比較知名的有StreamBase、Borealis等。
本文簡單介紹幾種業界使用的流式計算系統，希望流式系統的設計者或開發者們能從中獲得啓示。
圖1 數據分析系統整體組成示意圖
圖1從整個分析系統的架構角度，給出了實時計算子系統所處的位置。實時計算系統和批處理計算系統同屬於計算這個大的範疇，批處理計算可以是MapReduce、MPI、SCOPE等，實時計算可以是S4、Storm等，批處理和實時都可以或不依賴統一的資源調度系統。另外，計算系統的輸入、輸出，包括中間過程的輸入、輸出，都與存儲系統交互，可以是塊存儲系統HDFS，也可以是K-V存儲系統Hypertable等。計算層的上層是數據倉庫，或者直接和用戶交互，交互方式可以是SQL-like或者MR-like等。
系統
S4
S4是一個通用的、分佈式的、可擴展的、分區容錯的、可插拔的流式系統。基於S4框架，開發者可以輕鬆開發面向持續流數據處理的應用。
S4的設計特點有以下幾個方面。
- Actor Model
爲了能在普通機型構成的集羣上進行分佈式處理，並且集羣內部不使用共享內存，S4架構採用了Actor模式，這種模式提供了封裝和地址透明語義，因此在允許應用大規模併發的同時，也提供了簡單的編程接口。S4系統通過處理單元（Processing Elements，PEs）進行計算，消息在處理單元間以數據事件的形式傳送，PE消費事件，發出一個或多個可能被其他PE處理的事件，或者直接發佈結果。每個PE的狀態對於其他PE不可見，PE之間唯一的交互模式就是發出事件和消費事件。框架提供了路由事件到合適的PE和創建新PE實例的功能。S4的設計模式符合封裝和地址透明的特性。
- Decentralized and Symmetric Architecture
除了遵循Actor模式，S4也參照了MapReduce模式。爲了簡化部署和運維，從而達到更好地穩定性和擴展性，S4採用了對等架構，集羣中的所有處理節點都是等同的，沒有中心控制。這種架構將使得集羣的擴展性很好，處理節點的總數理論上無上限；同時，S4將沒有單點容錯的問題。
Pluggable Architecture
S4系統使用Java開發，採用了極富層次的模塊化編程，每個通用功能點都儘量抽象出來作爲通用模塊，而且儘可能讓各模塊實現可定製化。
- Partial Fault-Tolerance
基於Zookeeper服務的集羣管理層將會自動路由事件從失效節點到其他節點。除非顯式保存到持久性存儲，否則節點故障時，節點上處理事件的狀態會丟失。
- Object Oriented
節點間通信採用“Plain Old Java Objects”（POJOs）模式，應用開發者不需要寫Schemas 或用哈希表來在節點間發送Tuples。
S4的功能組件分3大類，Clients、Adapters和PNode Cluster，圖2顯示了S4系統框架。
圖2 Yahoo! S4流式系統框架結構圖
S4提供Client Adapter，允許第三方客戶端向S4集羣發送事件和接收事件。Adapter實現了基於JSON的API，支持多語言實現的客戶端驅動。
Client通過Driver組件與Adapter進行交互，Adapter也是一個Cluster，其中有多個Adapter結點，Client可以通過多個Driver與多個Adapter進行通信，這樣可以保證單個Client在分發大數據量時Adapter不會成爲瓶頸，也可以確保系統支持多個Client應用併發執行的快速、高效和可靠性。
在Adapter中，真正與Client交互的是其Stub組件，該組件實現了管理Client與Adapter之間通過TCP/IP協議進行通信的功能。GenericJsonClientStub這個類支持將事件在Client與Adapter之間以JSON的形式轉換，從而支持更多種類型的Client應用。不同的Client可以配置不同的Stub來與Adapter進行通信，用戶可以定義自己的Stub來實現自己想要的業務邏輯，這樣也使得Client的行爲更加多樣性、個性化。
StreamBase
StreamBase是IBM開發的一款商業流式計算系統，在金融行業和政府部門使用，其本身是商業應用軟件，但提供了Develop Edition。相對於付費使用的Enterprise Edition，前者的功能更少，但這並不妨礙我們從外部使用和API接口來對StreamBase本身進行分析。
StreamBase使用Java開發，IDE是基於Eclipse進行二次開發，功能非常強大。StreamBase也提供了相當多的Operator、Functor以及其他組件來幫助構建應用程序。用戶只需要通過IDE拖拉控件，然後關聯一下，設置好傳輸的Schema並且設置一下控件計算過程，就可以編譯出一個高效處理的流式應用程序了。同時，StreamBase還提供了類SQL語言來描述計算過程。
StreamBase的組件交互情況如圖3所示。
圖3 StreamBase組件交互圖
StreamBase Server是節點上啓動的管理進程，它負責管理節點上Container的實例，每個Container通過Adapter獲得輸入，交給應用邏輯進行計算，然後通過Adapter進行輸出。各個Container相互連接，形成一個計算流圖。
Adapter負責與異構輸入或輸出交互，源或目的地可能包括CSV文件、JDBC、JMS、Simulation（StreamBase提供的流產生模擬器）或用戶定製。
每個StreamBase Server上面都會存在一個Sytsem Container，主要是產生系統監控信息的流式數據。
HA Container用於容錯恢復，可以看出它實際包含兩個部分：Heartbeat和HA Events，其中HeartBeat也是Tuple在Container之間傳輸。在HA方案下，HA Container監控Primary Server的活動情況，然後將這些信息轉換成爲HA Events交給StreamBase Monitor來處理。
Monitor就是從System Container和HA Container中獲取數據並且進行處理。StreamBase認爲HA 問題應該通過CEP方式處理，也就是說如果哪個部件出現問題，就肯定會反映在System Container和HA Container的輸出流上面，然後 Monitor通過複雜事件處理這些Tuples的話就能夠檢測到機器故障等問題，並作出相應處理。
StreamBase提出了以下4種模板策略來解決容錯問題。
- Hot-Hot Server Pair Template
Primary Server和Secondary Server都在同時計算，並且將計算結果交給下游。優點是Primary Server如果故障的話那麼Secondary Server依然工作，幾乎沒有任何切換時間；並且下游只需要選取先到來的Tuple就可以處理了，保證處理速度最快；缺點是浪費計算和網絡資源。
- Hot-Warm Server Pair Template
Primary Server和Secondary Server都在同時計算，但只有Primary Server將計算結果交給下游。優點是如果Primary Server故障，Secondary Server可以很快切換，而不需要任何恢復狀態的工作。相對於Hot-Hot方式時間稍微長一些，但沒有Hot-Hot那麼耗費網絡資源，同時也浪費了計算資源。
- Shared Disk Template
Primary Server在計算之後，將計算的一些中間關鍵狀態存儲到磁盤、SAN（Storage Area Network）或是可靠的存儲介質。如果Srimary Server故障，Secondary Server會從介質中讀取出關鍵狀態，然後接着繼續計算。優點是沒有浪費任何計算和網路資源，但恢復時間依賴狀態的量級而定，相對於前兩種，恢復時間可能會稍長。
- Fast Restart Template
這種方案限定了應用場景，只針對無狀態的應用。對於無狀態的情況，方案可以非常簡單，只要發現Primary Server故障，Secondary Server立即啓動，並接着上游的數據流繼續計算即可。
Borealis
Borealis是Brandeis University、Brown University和MIT合作開發的一個分佈式流式系統，由之前的流式系統Aurora、Medusa演化而來。目前Borealis系統已經停止維護，最新的Release版本停止在2008年。
Borealis具有豐富的論文、完整的用戶/開發者文檔，系統是C++實現的，運行於x86-based Linux平臺。系統是開源的，同時使用了較多的第三方開源組件，包括用於查詢語言翻譯的ANTLR、C++的網絡編程框架庫NMSTL等。
Borealis系統的流式模型和其他流式系統基本一致：接受多元的數據流和輸出，爲了容錯，採用確定性計算，對於容錯性要求高的系統，會對輸入流使用算子進行定序。
Borealis的系統架構如圖4所示。
- Query Processor（QP）是計算執行的地方，是系統的核心部件，其大部分功能繼承自Aurora。
- I/O Queues將數據流導入QP，路由Tuples到其他節點或客戶端程序。
- Admin模塊用來控制本地的QP，例如建立查詢、遷移數據流圖片段，該模塊也會同Local Optimizer協作優化現有數據流圖。
- Local Optimizer職責包括本地調度策略、調整Operator行爲、超載後丟棄低價值元組等。
- Storage Manager模塊用於存儲本地計算的狀態數據。
- Local Catalog存儲本地數據流圖和元數據，可以被本地所有組件訪問。
- Borealis Node還有彼此通信的模塊用於執行協作任務。
- Neighborhood Optimizer使用本地和鄰居節點來優化節點間的負載均衡或shed load。
- High Availability （HA）模塊相互監測，發現對方故障時及時代替對方。
- Local Monitor收集本地性能相關統計數字報告給本地和Neighborhood Optimizer。
- Global Catalog爲整個數據流計算提供了一個邏輯上的完整視圖。
除作爲基本功能節點外，Borealis Server也可以被設計成一個協作節點來執行全局的系統監控和其他優化任務，比如全局的負載分佈和Global Load Shedding，因此Borealis實際上提供了完整的3級監控和優化（Local、Neighborhood、Global）。
負載均衡方面，Borealis提供了動態和靜態兩種部署機制。
- Correlation-based Operator Distribution
通過分析不同Operators和Nodes間的負載變化的關係，決定和動態調整Operatpr的部署，使之達到負載均衡。
- Resilient Operator Distribution Algorithm
該算法的目標是提供一種靜態的Operator部署方案，該方案能夠在不需要重新調整的情況下處理最大可能的輸入速度變化範圍。
由於動態調整需要時間和消耗，前者適用於負載變化持續時間較長的系統；而後者則能處理較快較短的負載峯值。在實現上前者使用相關係數作爲節點關聯度指標，並通過貪婪算法將NP問題轉化爲多項式求解；而後者在部署前計算完畢，保證系統能夠容忍負載峯值。該算法在線性代數上建模，包括Operator Ordering、Operator Assignment兩個階段。
Borealis通過四種容錯機制來滿足用戶需求。
- Amnesia Backup
備機發現主機故障，立即從一個空的狀態開始重做。
- Passive Standby
主機處理，備機待命，主機按週期做Checkpoint，主機故障後切換到備機，重放Checkpoint和數據流，對於不確定性計算可以很好地支持，缺點是恢復時間較長。
- Active Standby
主備機同時計算，主機故障時直接切換到備機，不支持不確定性計算，浪費計算資源，不過恢復時間幾乎沒有。
- Upstream Backup
通過上游備份來容錯，故障時從上游重放數據即可，恢復時間最長，不過最節省資源。
除此之外，Borealis還提供了更高級的容錯機制Rollback Recovery，它是一種基於副本在節點失效、網絡失效或網絡分區時的故障恢復機制，在儘量減少系統不一致的情況下，儘可能地保證系統的可用性。該機制允許用戶定義一個閾值來在一致性和可用性之間做一個平衡。當系統數據恢復後，系統支持重新計算輸出正確的結果，保證最終一致性。該機制使用了Data-serializing Operator（SUnion）來確保所有的副本處理同樣順序的數據。當失效恢復後，通過Checkpoint/Redo、Undo/Redo來實現恢復重放。
對比
表1就上述3個流式系統做個分類比較，比較項基於DEBS2011會議上IFPSurvey中涉及的各種Models。Processing Model描述流元組進行計算時的選擇策略、消費策略及負載降級處理。Interaction Model描述輸入組件和計算系統、計算系統內部及計算系統和輸出組件的交互方式。Time Model描述事件流是否按照時間約束。Rules Model描述流式計算規則是顯示還是隱式。Data Model描述流中的數據組成、格式等。Function Model描述流式計算系統的功能模型。Language Model描述語言層面的各種算子。
表1 3種流式系統的模型對比
小結
本文介紹了業界主流的3個流式計算系統，希望從這些系統的設計中領悟到不同場景下流式計算所要解決的關鍵問題。
Yahoo! S4的最新版本是Alpha version v0.3.0，動態負載均衡和在線服務遷移等重要功能都尚未實現，不過其代表性的3個特點值得學習，Actor模式、非中心化的對稱結構及可插入式的架構。
StreamBase是有着功能強大的IDE並且支持控件式的方法來搭建應用程序，同時還提供了高級語言來搭建應用程序的方法。由於是商業產品，其用戶接口的精彩設計值得借鑑，同時其可組合的HA方案也是亮點之一。
Borealis是學術界研究的重要產出，它對新一代的流式系統涉及的諸多方面，如係數據模型、負載管理、高可用性、可擴展性都作了全面和翔實的研究，一方面系統變得強大、先進，另一方面使得系統也變得臃腫、複雜。這套系統的許多策略都值得我們學習，可以應用於不同的流式計算場景。
作者楊棟，百度分佈式高級研發工程師，從事Hypertable、Hadoop及流式計算的研究和開發。
