流計(jì)算

　　內(nèi)容

　　比較早期代表系統(tǒng)有IBM的System S，它是一個(gè)完整的計(jì)算架構(gòu)，通過“stream computing”技術(shù)，可以對(duì)stream形式的數(shù)據(jù)進(jìn)行real-time的分析。“最初的系統(tǒng)擁有大約800個(gè)微處理器，但I(xiàn)BM稱，根據(jù)需求，這個(gè)數(shù)字也有可能上萬。研究者講到，其中最關(guān)鍵的部分是System S軟件，它可以將任務(wù)分開，比如分為圖像識(shí)別和文本識(shí)別，然后將處理后的結(jié)果碎片組成完整的答案。IBM實(shí)驗(yàn)室高性能流運(yùn)算項(xiàng)目的負(fù)責(zé)人Nagui Halim談到：System S是一個(gè)全新的運(yùn)算模式，它的靈活性和速度頗具優(yōu)勢。而與傳統(tǒng)系統(tǒng)相比，它的方式更加智能化，可以適當(dāng)轉(zhuǎn)變，以適用其需要解決的問題。

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

　　有人會(huì)說，MR也有自己的實(shí)時(shí)計(jì)算方案，比如說HOP。

　　但是，這類基于MapReduce進(jìn)行流式處理的方案有三個(gè)主要缺點(diǎn)。

　　綜上所述，流式處理的模式?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等公司相繼開源了流式計(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īng)用

　　流運(yùn)算在內(nèi)容方面，主要面向以下幾種應(yīng)用：對(duì)金融與科學(xué)計(jì)算當(dāng)中的數(shù)據(jù)進(jìn)行更快運(yùn)算和分析的需求；對(duì)存在于社交網(wǎng)站、博客、電子郵件、視頻、新聞、電話記錄、傳輸數(shù)據(jù)、電子感應(yīng)器之中的數(shù)字格式的信息流進(jìn)行快速處理并反饋的需求。