典型分佈式系統分析:MapReduce

  在 《分佈式學習最佳實踐:從分佈式系統的特徵開始(附思惟導圖)》一文中,提到學習分佈式系統的一個好方法是思考分佈式系統要解決的問題,有哪些衡量標準,爲了解決這些問題;提出了哪些理論、協議、算法,這些解決辦法各自的優缺點、適用場景;而後再思考,不一樣的系統是如何解決同一個問題的,好比說數據分片,好比說元數據的高可用,到了工程實踐這個層面是怎麼解決的。php

  上面是從問題出發,尋找答案。而另外一個方法,是從一個具體的系統出發,分析這個分佈式系統是如何解決須要解決全部問題,如何根據實際狀況對分佈式特性進行權衡。好比說對於CAP,是如何在C(一致性)與A(一致性)之間折中的。所以,本系列文章的主題就是了解這些分佈式系統是如何知足高性能、可擴展、高可用的通常性要求,各自的衡量標準,使用了哪些算法,有哪些設計巧妙、值得借鑑之處。

  劉傑的《分佈式系統原理介紹》一文中,也是介紹了分佈式系統的諸多概念和協議,而後說道:html

  「即使如此,筆者以爲後續能夠再做一篇《典型分佈式系統分析》,從各個系統的角度橫向分析這些系統的特色。」程序員

  可是我在網上搜索並無發現相關的文章,本文冒昧地使用了這個題目,而我本身深知,在分佈式領域我知之甚少,所以只算得拋磚引玉,但願大牛多指正。若是業界前輩可以有時間來寫寫這個系列,那就更好了。算法

  在這個系列中,通常都是根據論文對系統進行簡介,而後嘗試回答一下問題: 編程

●   系統在性能、可擴展性、可用性、一致性之間的衡量,特別是CAP
●   系統的水平擴展是如何實現的,是如何分片的
●   系統的元數據服務器的性能、可用性
●   系統的副本控制協議,是中心化仍是去中心化
●   對於中心化副本控制協議,中心是如何選舉的
●   系統還用到了哪些協議、理論、算法服務器

 

本文地址:http://www.cnblogs.com/xybaby/p/8878054.html網絡

MapReduce簡介

  在google的論文《MapReduce: Simplified Data Processing on Large Clusters》中,MapReduce既指一種編程模型,又指google爲這種編程模型開發的一套運行時框架。負載均衡

  MapReduce is a programming model and an associated implementation for processing and generating large data sets.框架

  在《初識分佈式計算:從MapReduce到Yarn&Fuxi》一文中,已經對MapReduce進行了詳細介紹,並且論文自己也很是容易讀懂。因此在本文中,只重述一些重要的點 -- 決定了MapReduce這個系統的特徵的點。分佈式

  這裏強調兩個概念:Job  and Task。在MapReduce中,整個計算任務稱之爲Job,而被劃分的子任務稱之爲task。Job是對用戶而言的,而task是運行框架內部術語。

MapReduce運算模型

  MapReduce編程模型來自函數式編程,包含兩個最基本的算子:map,reduce

map: (k1, v1) -> [(k2, v2)]

reduce: [(k2, [v2] )] --> [(k3, v3)]

  將一個運算任務分解成大量獨立正交的子任務,每一個子任務經過map算子計算,獲得中間結果,而後用reduce算子進行聚合,獲得最終結果。這兩個算子看起來簡單,但不少問題都能用這個模型來解決。

  這兩個算子有一個很重要的特徵:肯定性的純過程調用(pure function),函數既不會修改輸入,也不存在中間狀態,也沒有共享的內存。所以,輸入一致的狀況下,輸出也是一致的,這大大方便了容錯性設計。

MapReduce運行框架

  運行框架的做用在於提升用戶(在這裏也是程序員)的生產力,用戶只需經過map function、reduce function描述本身的計算問題,而不用關心計算在哪一個機器上進行、相互之間如何通訊、機器故障如何處理等複雜的問題,由於這些問題自己與計算任務不相關。

  運行框架調度流程圖以下:

  

  系統中有兩類主要的進程節點:master(單點),worker(多個)。其中,worker根據不一樣的計算任務,又分爲map worker(對應上圖中的Map phase)、reduce worker(對應上圖中的Reduce phase)。

  master是系統的中心節點,負責計算任務到worker節點的分配,同時監控worker節點的狀態。若是某個worker計算太慢,或者宕機,master會將該worker進程負責的計算任務轉移到其餘進程。

  map worker從GFS(google file system)中讀取輸入數據,而後將中間結果寫到本地文件;reduce worker從master處得知中間結果的問題,經過rpc讀取中間文件,計算以後將最終結果寫入到可靠存儲GFS。生產環境中,一個MapReduce過程的輸出一般是另外一個MapReduce計算的輸入,相似Unix 的 pipeline,只不過unix pipeline經過stdin、stdout鏈接兩個程序,而MapReduce使用GFS鏈接兩個計算過程。

MapReduce系統分析

  MapReduce是一個分佈式計算系統,計算的數據來自於文件,並且文件系統是可靠的(GFS保證了文件的可用性、可靠性)。

 Scalability

  因爲計算任務的正交性,很容易經過增長map worker、reduce worker來處理計算任務的增加。Input file 到 Map phase這個階段,使用了基於範圍(range based)的分片方法,master做爲元數據服務器會記錄split到worker的映射關係。當用戶指定R份最終輸出(也就是reduce worker的輸出)時,如何對中間結果(intermediate files)進行劃分呢?系統默認提供了hash分片方法(e.g. hash(key) mod R), 也容許用戶自行提供partition function來進行劃分。

  在Mapreduce中,子任務(task)的數量要遠小於worker的數量,這樣的好處在於更好的負載均衡、更快的故障恢復。
We subdivide the map phase into M pieces and the reduce phase into R pieces, as described above.
Ideally,M and R should be much larger than the number of worker machines.
Having each worker perform many different tasks improves dynamic load balancing, and also speeds up recovery when a worker fails: the many map tasksit has completed can be spread out across all the other worker machines. 

  系統的scalability主要受到master的約束,master是系統中的單點,須要維護每一個計算子任務(task)的狀態,與全部的worker保持心跳,記錄map worker計算的中間結果的文件位置。

 Availability

  系統對worker的容錯性較好,但對master的容錯性較差。

  master經過心跳來保證肯定worker是否存活,若是心跳超時,那麼master標記這個worker failed,而後將該worker所負責的全部task設置爲idle(等待計算)狀態。在《關於心跳、故障監測、lease機制》一文種中,提到了心跳檢測只能保證完整性(completeness),沒法保證準確性(accuracy),接下來後分析到,在MapReduce,不許確也是沒有關係的。

  對於map worker,計算結果是寫到本地文件,本地文件的位置須要通知到master,即便同一個task被多個map worker執行,單點的master只會採納一份中間結果。並且上面提到了map function是pure function,因此計算結果也是同樣的。

  對於reduce worker,reduce task的計算結果會先寫到臨時文件(temporary file),task完成以後再重命名寫入gfs,那麼若是一個reduce task再多個reduce worker上計算,那麼會不會有問題呢,答案是不會的

  We rely on the atomic renameoperation provided by the underlying file system to guarantee that the final file system state contains just the data produced by one execution of the reduce task.

  而因爲master是單點,即便有周期性的checkpoint也可能形成狀態的不一致,所以MapReduce會將master的crash告知用戶,用戶可自行決定是否重試整個計算。

Performance

  MapReduce做爲離線計算平臺,更多關注的是系統的吞吐率,那麼有哪些提升性能的點呢

第一:data locality

  在論文中提到,網絡傳輸代價是昂貴的,因此若是worker能從本地文件系統讀取數據的話就能儘量的少網絡傳輸。這也歸功於GFS系統,GFS以chuck(對應的就是Input file split)的粒度將每一份文件在不一樣的機器上保存三份。那麼master在掌握了chunk的位置時,就能夠將map worker調度到相應的機器,避免網絡傳輸。

第二:backup task

  master在發現某個worker上的task進展異常緩慢的時候,會將這個task調度到其餘worker,以縮短這個任務(Job)的完成時間。在上面avaliability已經提到,即便有兩個worker執行同一份task,也不會有問題的。

總結

  MapReduce提供了一個簡單但強大的編程範式與運行環境,是一個離線分佈式計算系統。MapReduce的最大優勢在於易於使用、伸縮性很好。相比分佈式存儲,分佈式計算的狀態更少(worker上沒有須要維護的上下文環境),所以不會出現嚴重的一致性、可用性問題。直接增長更多的節點就能解決擴展性問題,因爲計算的肯定性,經過簡單重試就能解決不少可用性問題。

references

分佈式系統原理介紹

MapReduce: Simplified Data Processing on Large Clusters

The Google File System

6.824 Schedule: Spring 2016 LEC 1

相關文章
相關標籤/搜索