大資料、大資料處理模型及MapReduce

MapReduce在大資料問題的處理上採用了與傳統HTTP://www.aliyun.com/zixun/aggregation/14345.html">資料處理方式架構上幾乎完全不同的解決方案， 它通過將需要處理的任務並行運行在集群中的多個商用電腦節點上的方式完成。 MapReduce在實現大資料處理上有著多個基礎理論思想的支撐，雖然這些基礎理論甚至實現方法都未必是MapReduce所創，但它們卻由MapReduce採用獨特的方式加以利用而重新大放光彩。

傳統資料處理模型

MapReduce資料處理模型

(1) 向外擴展(Scale out)而非向上擴展(Scale up)：大資料的處理更適合採用大量低端商務服務器(scale out)而非少量高端伺服器(scale up)。 後者正是向上擴展的系統性能提升方式，它通常採用有著SMP架構的主機，然而有著大量的CPU插槽(成百上千個)及大量的共用記憶體(可以多達數百GB)的高端伺服器非常昂貴，但其性能的增長卻非線性上升的，因此性價比很一般。 而大量的低端商務服務器價格低廉、易於更換和伸縮等特性有效避免了向上擴展的敝端。

(2)假設故障很常見(Assume failures are common)：在資料倉儲架構級別，故障是不可避免且非常普遍的。 假設一款伺服器出故障的平均概率為1000天1次，那麼10000台這種伺服器每天出錯的可能性將達到10次。 因此，大規模向外擴展的應用場景中，一個設計優良且具有容錯能力的服務必須能有效克服非常普遍的硬體故障所帶來的問題，即故障不能導致使用者應用層面的不一致性或非確定性。 MapReduce程式設計模型能通過一系列機制如任務自動重啟等健壯地應付系統或硬體故障。

(3)將處理常式移向資料(Move processing to the data)：傳統高性能計算應用中，超級電腦一般有著處理節點(processing node)和存儲節點(storage node)兩種角色， 它們通過高容量的設備完成互聯。 然而，大多數資料密集型的處理工作並不需要多麼強大的處理能力，於是把計算與存儲互相分開將使得網路成為系統性能瓶頸。 為了克服計算如此類的問題，MapReduce在其架構中將計算和存儲合併在了一起，並將資料處理工作直接放在資料存儲的位置完成，只不過這需要分散式檔案系統予以支撐。

(4)連續處理資料並避免隨機訪問(Process data sequentially and avoid random access)：大資料處理通常意味著海量的數量難以全部載入記憶體，因而必須存儲在磁片上。 然而，機械式磁片尋道操作的先天性缺陷使得亂數據訪問成為非常昂貴的操作，因此避免亂數據訪問並以連續處理為目的完成資料組織成為亟待之需。 固態磁片雖然避免了機械磁片的某此缺陷，然而其高昂的價格以及並沒有消除的隨機訪問問題仍然無法帶來性能上的飛躍發展。 MapReduce則主要設計用來在海量資料集上完成批次處理操作，即所有的計算被組織成較長的流式處理操作，以延遲換取較大的吞吐能力。

　　(5)隱藏系統級別的細節：程式開發中，專業程式師公認的難題之一就是得同步追蹤短期記憶的各種細節，簡單如變數名，複雜如演算法等;這會生較大的記憶負荷因為其需要程式師在開發過程中高度集中注意力，因此， 後來才出現了各種各樣的開發環境(IDE)以協助程式員在一定程度上解決諸如此類的問題。 開發分散式程式的過程更為複雜，程式師必須協調管理多個執行緒、進程甚至是主機之間的各種細節，而這其中，令人最為頭疼的問題是分散式程式以無法預知的次序運行，以及以無法預知的模式進行資料訪問。 這必然大大增加競爭條件、鎖死及其它臭名照著的問題出現的可能性。 傳統上，解決此類問題的辦法無外乎使用底層設備如互斥量，並在高層應用類似「生產者 -消費者」佇列的設計模式等;但基於這種方式設計的分散式程式極難理解並且很難進行調試。 MapReduce程式設計模型通過為其內部少量的幾個元件提供了一個簡單且精心定義的介面，從而將程式師與系統底層的處理細節隔離開來。 MapReduce實現了「運算什麼」與「如何在多個節點並行運算」的隔離，前者可以程式師控制，後者則完全由MapReduce程式設計框架或運行時環境控制。

(6)無縫擴展(Seamless scalability)：資料密集型的處理應用中擴展演算法(scalable algorithm)是其核心要件。 一個理想的擴展演算法應該滿足兩種特性：資料擴展一倍時其處理時長的增長幅度不會越過原處理所需時長的一倍;其次，集群規模擴大一倍時，其處理時長降低至少一倍。 進一步地，理想的擴展演算法還應該能夠處理種種規模如PB級別的資料，以及良好地運行于各種規模如數千節點的集群中，而且其無論運行時何種規模的集群、處理何種規模的資料，其程式並不需要做出修改，甚至連配置參數也不需要改動。 然而，現實是殘酷地，這種理想演算法並不存在，Fred Brook在其經典的「人月神話」中有一個斷言：為落後于預定計劃的專案增加程式師只會讓專案的完成時間進一步延後。 這是因為並不能通過簡單地將複雜任務切分為多個小任務並將其分配出去並行完成來獲得線性擴展，也即是「一個婦女可以在10個月生出孩子，但十個婦女並不能在一個月內生出孩子來」。 然而，這個斷言於今至少在某此領域已經被MapReduce打破——MapReduce最激動人心的特性之一就是其處理能力隨著節點的增加而線性增長，即集群規模增長N倍其處理相同規模資料的時長也會縮短N倍。

參考文獻：

HTTP://en.wikipedia.org/wiki/Big_data

HTTP://www.datameer.com/product/big-data.html

原文連結：HTTP://mageedu.blog.51cto.com/4265610/1105727