免费亚洲欧美精品电影_国内精品偷拍福利视频_美女黄网站色视免费国产_国产不卡福利片在线观看

MapReduce Hold不??？

標(biāo)簽：杭州網(wǎng)站設(shè)計(jì)  杭州網(wǎng)站建設(shè)  杭州網(wǎng)站制作

本文系統(tǒng)地介紹和分析比較了業(yè)界主流的Yahoo! S4、StreamBase和Borealis三種流式計(jì)算系統(tǒng)，希望讀者能從這些系統(tǒng)的設(shè)計(jì)中領(lǐng)悟到不同場(chǎng)景下流式計(jì)算所要解決的關(guān)鍵問(wèn)題。

背景

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

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

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

將輸入數(shù)據(jù)分隔成固定大小的片段，再由MapReduce平臺(tái)處理，缺點(diǎn)在于處理延遲與數(shù)據(jù)片段的長(zhǎng)度、初始化處理任務(wù)的開(kāi)銷(xiāo)成正比。小的分段會(huì)降低延遲，增加附加開(kāi)銷(xiāo)，并且分段之間的依賴(lài)管理更加復(fù)雜（例如一個(gè)分段可能會(huì)需要前一個(gè)分段的信息）；反之，大的分段會(huì)增加延遲。最優(yōu)的分段大小取決于具體應(yīng)用。為了支持流式處理，MapReduce需要被改造成Pipeline的模式，而不是Reduce直接輸出；考慮到效率，中間結(jié)果最好只保存在內(nèi)存中等。這些改動(dòng)使得原有的MapReduce框架的復(fù)雜度大大增加，不利于系統(tǒng)的維護(hù)和擴(kuò)展。用戶(hù)被迫使用MapReduce的接口來(lái)定義流式作業(yè)，這使得用戶(hù)程序的可伸縮性降低。

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

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

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

 

 

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

系統(tǒng)

S4

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

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

Actor Model

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

Decentralized and Symmetric Architecture

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

Partial Fault-Tolerance

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

Object Oriented

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

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

 

 

 

S4提供Client Adapter，允許第三方客戶(hù)端向S4集群發(fā)送事件和接收事件。Adapter實(shí)現(xiàn)了基于JSON的API，支持多語(yǔ)言實(shí)現(xiàn)的客戶(hù)端驅(qū)動(dòng)。

Client通過(guò)Driver組件與Adapter進(jìn)行交互，Adapter也是一個(gè)Cluster，其中有多個(gè)Adapter結(jié)點(diǎn)，Client可以通過(guò)多個(gè)Driver與多個(gè)Adapter進(jìn)行通信，這樣可以保證單個(gè)Client在分發(fā)大數(shù)據(jù)量時(shí)Adapter不會(huì)成為瓶頸，也可以確保系統(tǒng)支持多個(gè)Client應(yīng)用并發(fā)執(zhí)行的快速、高效和可靠性。

在Adapter中，真正與Client交互的是其Stub組件，該組件實(shí)現(xiàn)了管理Client與Adapter之間通過(guò)TCP/IP協(xié)議進(jìn)行通信的功能。GenericJsonClientStub這個(gè)類(lèi)支持將事件在Client與Adapter之間以JSON的形式轉(zhuǎn)換，從而支持更多種類(lèi)型的Client應(yīng)用。不同的Client可以配置不同的Stub來(lái)與Adapter進(jìn)行通信，用戶(hù)可以定義自己的Stub來(lái)實(shí)現(xiàn)自己想要的業(yè)務(wù)邏輯，這樣也使得Client的行為更加多樣性、個(gè)性化。

StreamBase

StreamBase是IBM開(kāi)發(fā)的一款商業(yè)流式計(jì)算系統(tǒng)，在金融行業(yè)和政府部門(mén)使用，其本身是商業(yè)應(yīng)用軟件，但提供了Develop Edition。相對(duì)于付費(fèi)使用的Enterprise Edition，前者的功能更少，但這并不妨礙我們從外部使用和API接口來(lái)對(duì)StreamBase本身進(jìn)行分析。

StreamBase使用Java開(kāi)發(fā)，IDE是基于Eclipse進(jìn)行二次開(kāi)發(fā)，功能非常強(qiáng)大。StreamBase也提供了相當(dāng)多的Operator、Functor以及其他組件來(lái)幫助構(gòu)建應(yīng)用程序。用戶(hù)只需要通過(guò)IDE拖拉控件，然后關(guān)聯(lián)一下，設(shè)置好傳輸?shù)腟chema并且設(shè)置一下控件計(jì)算過(guò)程，就可以編譯出一個(gè)高效處理的流式應(yīng)用程序了。同時(shí)，StreamBase還提供了類(lèi)SQL語(yǔ)言來(lái)描述計(jì)算過(guò)程。

StreamBase的組件交互情況如圖3所示。

 

 

 

StreamBase Server是節(jié)點(diǎn)上啟動(dòng)的管理進(jìn)程，它負(fù)責(zé)管理節(jié)點(diǎn)上Container的實(shí)例，每個(gè)Container通過(guò)Adapter獲得輸入，交給應(yīng)用邏輯進(jìn)行計(jì)算，然后通過(guò)Adapter進(jìn)行輸出。各個(gè)Container相互連接，形成一個(gè)計(jì)算流圖。

Adapter負(fù)責(zé)與異構(gòu)輸入或輸出交互，源或目的地可能包括CSV文件、JDBC、JMS、Simulation（StreamBase提供的流產(chǎn)生模擬器）或用戶(hù)定制。
每個(gè)StreamBase Server上面都會(huì)存在一個(gè)Sytsem Container，主要是產(chǎn)生系統(tǒng)監(jiān)控信息的流式數(shù)據(jù)。

HA Container用于容錯(cuò)恢復(fù)，可以看出它實(shí)際包含兩個(gè)部分：Heartbeat和HA Events，其中HeartBeat也是Tuple在Container之間傳輸。在HA方案下，HA Container監(jiān)控Primary Server的活動(dòng)情況，然后將這些信息轉(zhuǎn)換成為HA Events交給StreamBase Monitor來(lái)處理。

Monitor就是從System Container和HA Container中獲取數(shù)據(jù)并且進(jìn)行處理。StreamBase認(rèn)為HA 問(wèn)題應(yīng)該通過(guò)CEP方式處理，也就是說(shuō)如果哪個(gè)部件出現(xiàn)問(wèn)題，就肯定會(huì)反映在System Container和HA Container的輸出流上面，然后 Monitor通過(guò)復(fù)雜事件處理這些Tuples的話(huà)就能夠檢測(cè)到機(jī)器故障等問(wèn)題，并作出相應(yīng)處理。

StreamBase提出了以下4種模板策略來(lái)解決容錯(cuò)問(wèn)題。

Hot-Hot Server Pair Template

Primary Server和Secondary Server都在同時(shí)計(jì)算，并且將計(jì)算結(jié)果交給下游。優(yōu)點(diǎn)是Primary Server如果故障的話(huà)那么Secondary Server依然工作，幾乎沒(méi)有任何切換時(shí)間；并且下游只需要選取先到來(lái)的Tuple就可以處理了，保證處理速度最快；缺點(diǎn)是浪費(fèi)計(jì)算和網(wǎng)絡(luò)資源。

Hot-Warm Server Pair Template

Primary Server和Secondary Server都在同時(shí)計(jì)算，但只有Primary Server將計(jì)算結(jié)果交給下游。優(yōu)點(diǎn)是如果Primary Server故障，Secondary Server可以很快切換，而不需要任何恢復(fù)狀態(tài)的工作。相對(duì)于Hot-Hot方式時(shí)間稍微長(zhǎng)一些，但沒(méi)有Hot-Hot那么耗費(fèi)網(wǎng)絡(luò)資源，同時(shí)也浪費(fèi)了計(jì)算資源。

呼叫中心   吸塑發(fā)光字

Shared Disk Template

Primary Server在計(jì)算之后，將計(jì)算的一些中間關(guān)鍵狀態(tài)存儲(chǔ)到磁盤(pán)、SAN（Storage Area Network）或是可靠的存儲(chǔ)介質(zhì)。如果Srimary Server故障，Secondary Server會(huì)從介質(zhì)中讀取出關(guān)鍵狀態(tài)，然后接著繼續(xù)計(jì)算。優(yōu)點(diǎn)是沒(méi)有浪費(fèi)任何計(jì)算和網(wǎng)路資源，但恢復(fù)時(shí)間依賴(lài)狀態(tài)的量級(jí)而定，相對(duì)于前兩種，恢復(fù)時(shí)間可能會(huì)稍長(zhǎng)。

Fast Restart Template

這種方案限定了應(yīng)用場(chǎng)景，只針對(duì)無(wú)狀態(tài)的應(yīng)用。對(duì)于無(wú)狀態(tài)的情況，方案可以非常簡(jiǎn)單，只要發(fā)現(xiàn)Primary Server故障，Secondary Server立即啟動(dòng)，并接著上游的數(shù)據(jù)流繼續(xù)計(jì)算即可。

Borealis

Borealis是Brandeis University、Brown University和MIT合作開(kāi)發(fā)的一個(gè)分布式流式系統(tǒng)，由之前的流式系統(tǒng)Aurora、Medusa演化而來(lái)。目前Borealis系統(tǒng)已經(jīng)停止維護(hù)，最新的Release版本停止在2008年。

Borealis具有豐富的論文、完整的用戶(hù)/開(kāi)發(fā)者文檔，系統(tǒng)是C++實(shí)現(xiàn)的，運(yùn)行于x86-based Linux平臺(tái)。系統(tǒng)是開(kāi)源的，同時(shí)使用了較多的第三方開(kāi)源組件，包括用于查詢(xún)語(yǔ)言翻譯的ANTLR、C++的網(wǎng)絡(luò)編程框架庫(kù)NMSTL等。

Borealis系統(tǒng)的流式模型和其他流式系統(tǒng)基本一致：接受多元的數(shù)據(jù)流和輸出，為了容錯(cuò)，采用確定性計(jì)算，對(duì)于容錯(cuò)性要求高的系統(tǒng)，會(huì)對(duì)輸入流使用算子進(jìn)行定序。

Borealis的系統(tǒng)架構(gòu)如圖4所示。

 

Query Processor（QP）是計(jì)算執(zhí)行的地方，是系統(tǒng)的核心部件，其大部分功能繼承自Aurora。I/O Queues將數(shù)據(jù)流導(dǎo)入QP，路由Tuples到其他節(jié)點(diǎn)或客戶(hù)端程序。Admin模塊用來(lái)控制本地的QP，例如建立查詢(xún)、遷移數(shù)據(jù)流圖片段，該模塊也會(huì)同Local Optimizer協(xié)作優(yōu)化現(xiàn)有數(shù)據(jù)流圖。Local Optimizer職責(zé)包括本地調(diào)度策略、調(diào)整Operator行為、超載后丟棄低價(jià)值元組等。Storage Manager模塊用于存儲(chǔ)本地計(jì)算的狀態(tài)數(shù)據(jù)。Local Catalog存儲(chǔ)本地?cái)?shù)據(jù)流圖和元數(shù)據(jù)，可以被本地所有組件訪問(wèn)。Borealis Node還有彼此通信的模塊用于執(zhí)行協(xié)作任務(wù)。Neighborhood Optimizer使用本地和鄰居節(jié)點(diǎn)來(lái)優(yōu)化節(jié)點(diǎn)間的負(fù)載均衡或shed load。High Availability （HA）模塊相互監(jiān)測(cè)，發(fā)現(xiàn)對(duì)方故障時(shí)及時(shí)代替對(duì)方。Local Monitor收集本地性能相關(guān)統(tǒng)計(jì)數(shù)字報(bào)告給本地和Neighborhood Optimizer。Global Catalog為整個(gè)數(shù)據(jù)流計(jì)算提供了一個(gè)邏輯上的完整視圖。

除作為基本功能節(jié)點(diǎn)外，Borealis Server也可以被設(shè)計(jì)成一個(gè)協(xié)作節(jié)點(diǎn)來(lái)執(zhí)行全局的系統(tǒng)監(jiān)控和其他優(yōu)化任務(wù)，比如全局的負(fù)載分布和Global Load Shedding，因此Borealis實(shí)際上提供了完整的3級(jí)監(jiān)控和優(yōu)化（Local、Neighborhood、Global）。

負(fù)載均衡方面，Borealis提供了動(dòng)態(tài)和靜態(tài)兩種部署機(jī)制。

Correlation-based Operator Distribution

通過(guò)分析不同Operators和Nodes間的負(fù)載變化的關(guān)系，決定和動(dòng)態(tài)調(diào)整Operatpr的部署，使之達(dá)到負(fù)載均衡。

Resilient Operator Distribution Algorithm

該算法的目標(biāo)是提供一種靜態(tài)的Operator部署方案，該方案能夠在不需要重新調(diào)整的情況下處理最大可能的輸入速度變化范圍。

由于動(dòng)態(tài)調(diào)整需要時(shí)間和消耗，前者適用于負(fù)載變化持續(xù)時(shí)間較長(zhǎng)的系統(tǒng)；而后者則能處理較快較短的負(fù)載峰值。在實(shí)現(xiàn)上前者使用相關(guān)系數(shù)作為節(jié)點(diǎn)關(guān)聯(lián)度指標(biāo)，并通過(guò)貪婪算法將NP問(wèn)題轉(zhuǎn)化為多項(xiàng)式求解；而后者在部署前計(jì)算完畢，保證系統(tǒng)能夠容忍負(fù)載峰值。該算法在線(xiàn)性代數(shù)上建模，包括Operator Ordering、Operator Assignment兩個(gè)階段。

Borealis通過(guò)四種容錯(cuò)機(jī)制來(lái)滿(mǎn)足用戶(hù)需求。

Amnesia Backup

備機(jī)發(fā)現(xiàn)主機(jī)故障，立即從一個(gè)空的狀態(tài)開(kāi)始重做。

Passive Standby

主機(jī)處理，備機(jī)待命，主機(jī)按周期做Checkpoint，主機(jī)故障后切換到備機(jī)，重放Checkpoint和數(shù)據(jù)流，對(duì)于不確定性計(jì)算可以很好地支持，缺點(diǎn)是恢復(fù)時(shí)間較長(zhǎng)。

Active Standby

主備機(jī)同時(shí)計(jì)算，主機(jī)故障時(shí)直接切換到備機(jī)，不支持不確定性計(jì)算，浪費(fèi)計(jì)算資源，不過(guò)恢復(fù)時(shí)間幾乎沒(méi)有。

Upstream Backup

通過(guò)上游備份來(lái)容錯(cuò)，故障時(shí)從上游重放數(shù)據(jù)即可，恢復(fù)時(shí)間最長(zhǎng)，不過(guò)最節(jié)省資源。

除此之外，Borealis還提供了更高級(jí)的容錯(cuò)機(jī)制Rollback Recovery，它是一種基于副本在節(jié)點(diǎn)失效、網(wǎng)絡(luò)失效或網(wǎng)絡(luò)分區(qū)時(shí)的故障恢復(fù)機(jī)制，在盡量減少系統(tǒng)不一致的情況下，盡可能地保證系統(tǒng)的可用性。該機(jī)制允許用戶(hù)定義一個(gè)閾值來(lái)在一致性和可用性之間做一個(gè)平衡。當(dāng)系統(tǒng)數(shù)據(jù)恢復(fù)后，系統(tǒng)支持重新計(jì)算輸出正確的結(jié)果，保證最終一致性。該機(jī)制使用了Data-serializing Operator（SUnion）來(lái)確保所有的副本處理同樣順序的數(shù)據(jù)。當(dāng)失效恢復(fù)后，通過(guò)Checkpoint/Redo、Undo/Redo來(lái)實(shí)現(xiàn)恢復(fù)重放。

對(duì)比

表1就上述3個(gè)流式系統(tǒng)做個(gè)分類(lèi)比較，比較項(xiàng)基于DEBS2011會(huì)議上IFPSurvey中涉及的各種Models。Processing Model描述流元組進(jìn)行計(jì)算時(shí)的選擇策略、消費(fèi)策略及負(fù)載降級(jí)處理。Interaction Model描述輸入組件和計(jì)算系統(tǒng)、計(jì)算系統(tǒng)內(nèi)部及計(jì)算系統(tǒng)和輸出組件的交互方式。Time Model描述事件流是否按照時(shí)間約束。Rules Model描述流式計(jì)算規(guī)則是顯示還是隱式。Data Model描述流中的數(shù)據(jù)組成、格式等。Function Model描述流式計(jì)算系統(tǒng)的功能模型。Language Model描述語(yǔ)言層面的各種算子。

 

 

 

小結(jié)
本文介紹了業(yè)界主流的3個(gè)流式計(jì)算系統(tǒng)，希望從這些系統(tǒng)的設(shè)計(jì)中領(lǐng)悟到不同場(chǎng)景下流式計(jì)算所要解決的關(guān)鍵問(wèn)題。
Yahoo! S4的最新版本是Alpha version v0.3.0，動(dòng)態(tài)負(fù)載均衡和在線(xiàn)服務(wù)遷移等重要功能都尚未實(shí)現(xiàn)，不過(guò)其代表性的3個(gè)特點(diǎn)值得學(xué)習(xí)，Actor模式、非中心化的對(duì)稱(chēng)結(jié)構(gòu)及可插入式的架構(gòu)。

StreamBase是有著功能強(qiáng)大的IDE并且支持控件式的方法來(lái)搭建應(yīng)用程序，同時(shí)還提供了高級(jí)語(yǔ)言來(lái)搭建應(yīng)用程序的方法。由于是商業(yè)產(chǎn)品，其用戶(hù)接口的精彩設(shè)計(jì)值得借鑒，同時(shí)其可組合的HA方案也是亮點(diǎn)之一。
Borealis是學(xué)術(shù)界研究的重要產(chǎn)出，它對(duì)新一代的流式系統(tǒng)涉及的諸多方面，如系數(shù)據(jù)模型、負(fù)載管理、高可用性、可擴(kuò)展性都作了全面和翔實(shí)的研究，一方面系統(tǒng)變得強(qiáng)大、先進(jìn)，另一方面使得系統(tǒng)也變得臃腫、復(fù)雜。這套系統(tǒng)的許多策略都值得我們學(xué)習(xí)，可以應(yīng)用于不同的流式計(jì)算場(chǎng)景。