文中提出一個(gè)類MapReduce框架MapUpdate，根據(jù)這個(gè)計(jì)算框架實(shí)現(xiàn)了Muppet系統(tǒng)，文中分別介紹了1.0和改進(jìn)版本2.0。

1. Motivation

(資料圖片)

“fast data”(文中使用，從其例子中看，實(shí)質(zhì)上與流數(shù)據(jù)基本等同)的處理需求與日俱增，如傳感器數(shù)據(jù)、股票數(shù)據(jù)和社交媒體數(shù)據(jù)等，MapReduce框架不適合做實(shí)時(shí)的數(shù)據(jù)處理。

文中在列舉了多個(gè)應(yīng)用場景，包括Foursquare-checkin(類似于街旁的基于位置的手機(jī)簽到)、監(jiān)測Twitter上的熱門話題、持續(xù)計(jì)算Twitter用戶的影響力打分(好友的回復(fù)及轉(zhuǎn)發(fā)引起分?jǐn)?shù)的更新)。

在分析完應(yīng)用場景后，分析了為何MR架構(gòu)不適合流數(shù)據(jù)。

l Reduce是在map完成后啟動(dòng)。

l 有明確的開始結(jié)束，而流處理面對(duì)是持續(xù)數(shù)據(jù)。

l 故障后的重啟較慢，丟失大量流數(shù)據(jù)。

2. MapUpdate框架

MapUpdate最大的特點(diǎn)是基于內(nèi)存的處理。將數(shù)據(jù)抽象為stream，每個(gè)stream(流有其專有ID)由多個(gè)event(tuple，如一條Twitter)組成；框架中有兩類處理單元，map和update。

Map：起到過濾、分類、整合輸入進(jìn)來的流，然后產(chǎn)生新的流。流中的event有其時(shí)間截，文中提及如map有多個(gè)輸入，將按event的時(shí)間截順序處理。(可能存在的問題：當(dāng)多個(gè)輸入中有一個(gè)到達(dá)延時(shí)后，如其之前的時(shí)間截已完成處理，這個(gè)“過時(shí)的”event是不是應(yīng)該丟棄？造成處理的不精確？storm要求沒有數(shù)據(jù)的丟失，在事務(wù)性topology中，為了不丟失數(shù)據(jù)，可能會(huì)降低其處理性能。這是兩個(gè)系統(tǒng)之間對(duì)性能和精確的取舍的不同)

Update和slate: 每個(gè)update在其節(jié)點(diǎn)的內(nèi)存中計(jì)錄屬于這個(gè)結(jié)點(diǎn)的全部key->value映射表 (因?yàn)閷?duì)流數(shù)據(jù)不可能像MR中Reduce集齊整個(gè)list之后在輸出)，將(U是一個(gè)特定update的編號(hào))寫入內(nèi)存(由于內(nèi)存空間有限，解決辦法在slate管理中提及)，這條記錄稱之為slate,唯一確定一個(gè)slate。(update之間沒有全局表，每個(gè)update使用自己的映射表，通過這樣回避并發(fā)訪問映射表的問題；MapUpdate的擴(kuò)展是通過修改哈希函數(shù)，任務(wù)劃分后分給不同的update任務(wù)，每個(gè)update任務(wù)只在一個(gè)結(jié)點(diǎn)上完成，擴(kuò)展性能不好！storm中是通過將一個(gè)結(jié)點(diǎn)的任務(wù)在集群上的多個(gè)進(jìn)程運(yùn)行達(dá)到并行處理)。

數(shù)據(jù)傳遞：處理單元之間的流的傳遞全部采用mod hashing，即相同的ID流向相同的處理單元。(storm中節(jié)點(diǎn)之間有6種傳遞方式，這種方式稱為fields grouping)。每個(gè)處理節(jié)點(diǎn)有自己的輸入隊(duì)列，前一個(gè)節(jié)點(diǎn)負(fù)責(zé)將數(shù)據(jù)發(fā)到其隊(duì)列之中，它從隊(duì)列中取數(shù)據(jù)。

3. Muppet 系統(tǒng)

Slate的管理(muppet 2.0版本)：slate在內(nèi)存中，也是外存中進(jìn)行感存儲(chǔ)。muppet使用cassandra作為slate的存儲(chǔ)系統(tǒng)，存儲(chǔ)在SSD上 (slate就是最終的處理結(jié)果了)。Update的處理過程：首先在Update節(jié)點(diǎn)內(nèi)存中查找是否存在slate，沒有則查找cassandra集群。(如此增加了內(nèi)外存的數(shù)據(jù)交換，包括內(nèi)存中slate的更新與外存中的一致性維護(hù)，只能通過增加節(jié)點(diǎn)數(shù)減少每個(gè)節(jié)點(diǎn)的處理任務(wù)來減少這種開銷)。

錯(cuò)誤處理機(jī)制：系統(tǒng)中有Master對(duì)所有結(jié)點(diǎn)的狀態(tài)進(jìn)行管理，當(dāng)一個(gè)節(jié)點(diǎn)A在傳送數(shù)據(jù)時(shí)發(fā)現(xiàn)其后面的節(jié)點(diǎn)B故障后，通知Master，然后Master通知其他向B發(fā)送數(shù)據(jù)的結(jié)點(diǎn)。而已經(jīng)到達(dá)B的數(shù)據(jù)，無論成功與否，都不再重放。

2.0系統(tǒng)中的改進(jìn)：在1.0中一個(gè)處理節(jié)點(diǎn)處理的流，可在兩個(gè)節(jié)點(diǎn)上處理。但這種場景是ID1，ID2的流節(jié)點(diǎn)A中處理，當(dāng)ID1的流特別多時(shí)，可用節(jié)點(diǎn)B處理ID2(作者說在實(shí)踐中發(fā)現(xiàn)使用兩個(gè)節(jié)點(diǎn)處理不會(huì)發(fā)生較為明顯的競爭問題)；專門使用一個(gè)節(jié)點(diǎn)將slate寫到外存中。

性能數(shù)據(jù)：100millions tweets and 1.5 million checkins per day；保存超過30 millions slates；節(jié)點(diǎn)由數(shù)十臺(tái)機(jī)器組成，延時(shí)不超過2秒。

處理某個(gè)節(jié)點(diǎn)負(fù)載過量的其他方法：對(duì)于那些實(shí)時(shí)性要求不高的應(yīng)用，可以“放慢數(shù)據(jù)流到達(dá)的腳步”(這方面特性Storm系統(tǒng)中沒有涉及)。

4. 我的評(píng)價(jià)

MapUpdate框架特點(diǎn)就是基本主存的，我認(rèn)為在數(shù)據(jù)流規(guī)模不是超大時(shí)是有效的，Muppet對(duì)數(shù)據(jù)的處理相對(duì)storm來說，靈活有余，精確不足。如果使用storm處理實(shí)時(shí)性不是特別高的應(yīng)用時(shí)，可以考慮Muppet中的一些折衷方式(storm中的精確處理機(jī)制是可選的，可以選擇失敗不重放等)。