環球精選！一文讀懂Mapduce框架Map：類MapReduce框架實現1.0和改進版本

文中提出一個類MapReduce框架MapUpdate，根據這個計算框架實現了Muppet系統，文中分別介紹了1.0和改進版本2.0。

1. Motivation

(資料圖片)

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

文中在列舉了多個應用場景，包括Foursquare-checkin(類似于街旁的基于位置的手機簽到)、監測Twitter上的熱門話題、持續計算Twitter用戶的影響力打分(好友的回復及轉發引起分數的更新)。

在分析完應用場景后，分析了為何MR架構不適合流數據。

l Reduce是在map完成后啟動。

l 有明確的開始結束，而流處理面對是持續數據。

l 故障后的重啟較慢，丟失大量流數據。

2. MapUpdate框架

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

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

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

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

3. Muppet 系統

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

錯誤處理機制：系統中有Master對所有結點的狀態進行管理，當一個節點A在傳送數據時發現其后面的節點B故障后，通知Master，然后Master通知其他向B發送數據的結點。而已經到達B的數據，無論成功與否，都不再重放。

2.0系統中的改進：在1.0中一個處理節點處理的流，可在兩個節點上處理。但這種場景是ID1，ID2的流節點A中處理，當ID1的流特別多時，可用節點B處理ID2(作者說在實踐中發現使用兩個節點處理不會發生較為明顯的競爭問題)；專門使用一個節點將slate寫到外存中。

性能數據：100millions tweets and 1.5 million checkins per day；保存超過30 millions slates；節點由數十臺機器組成，延時不超過2秒。

處理某個節點負載過量的其他方法：對于那些實時性要求不高的應用，可以“放慢數據流到達的腳步”(這方面特性Storm系統中沒有涉及)。

4. 我的評價

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