无码乱肉视频免费大全合集,亚洲第一A在线观看网站,黄网站色视频免费无风险,免费国产黄网在线观看

MapReduce Hold不??？

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

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

背景

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

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

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

將輸入數(shù)據(jù)分隔成固定大小的片段，再由MapReduce平臺處理，缺點在于處理延遲與數(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)，試圖搭建一個既適合流式計算又適合批處理計算的通用平臺，結(jié)果可能會是一個高度復(fù)雜的系統(tǒng)，并且最終系統(tǒng)可能對兩種計算都不理想。

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

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

 

 

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

系統(tǒng)

S4

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

S4的設(shè)計特點有以下幾個方面。

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)行計算，消息在處理單元間以數(shù)據(jù)事件的形式傳送，PE消費事件，發(fā)出一個或多個可能被其他PE處理的事件，或者直接發(fā)布結(jié)果。每個PE的狀態(tài)對于其他PE不可見，PE之間唯一的交互模式就是發(fā)出事件和消費事件?？蚣芴峁┝寺酚墒录胶线m的PE和創(chuàng)建新PE實例的功能。S4的設(shè)計模式符合封裝和地址透明的特性。

Decentralized and Symmetric Architecture

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

Partial Fault-Tolerance

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

Object Oriented

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

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

 

 

 

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

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

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

StreamBase

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

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

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

 

 

 

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

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

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

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

StreamBase提出了以下4種模板策略來解決容錯問題。

Hot-Hot Server Pair Template

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

Hot-Warm Server Pair Template

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

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

Shared Disk Template

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

Fast Restart Template

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

Borealis

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

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

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

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

 

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

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

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

Correlation-based Operator Distribution

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

Resilient Operator Distribution Algorithm

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

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

Borealis通過四種容錯機(jī)制來滿足用戶需求。

Amnesia Backup

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

Passive Standby

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

Active Standby

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

Upstream Backup

通過上游備份來容錯，故障時從上游重放數(shù)據(jù)即可，恢復(fù)時間最長，不過最節(jié)省資源。

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

對比

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

 

 

 

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

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