分布式系統(tǒng)
-
分布式系統(tǒng)是什么伯襟？
多臺協(xié)作的計(jì)算機(jī)
存儲大型網(wǎng)站，MapReduce，p2p 共享網(wǎng)絡(luò)等很多關(guān)鍵的基礎(chǔ)設(shè)施是分布式的
建設(shè)分布式系統(tǒng)的原因
通過并行增加容量
-
通過復(fù)制實(shí)現(xiàn)錯誤容忍(容錯)
使計(jì)算在物理上靠近外部實(shí)體
通過隔離實(shí)現(xiàn)安全
但是很多并發(fā)部分示括，復(fù)雜的交互，必須處理局部錯誤痢畜，難以實(shí)現(xiàn)性能潛力
-
很多性能問題并不能簡單通過擴(kuò)展實(shí)現(xiàn)
快速響應(yīng)單一用戶請求
所有用戶想更新相同的數(shù)據(jù)
這些通常需要更好的設(shè)計(jì)而不僅僅是更多的服務(wù)器
-
MapReduce
MapReduce 任務(wù)抽象
[圖mapreduce.png
MapReduce 過程
input is (already) split into M files
Input1 -> Map -> a,1 b,1
Input2 -> Map -> b,1
Input3 -> Map -> a,1 c,1
| | |
| | -> Reduce -> c,1
| -----> Reduce -> b,2
---------> Reduce -> a,2
MR calls Map() for each input file, produces set of k2,v2
"intermediate" data
each Map() call is a "task"
MR gathers all intermediate v2's for a given k2,
and passes each key + values to a Reduce call
final output is set of <k2,v3> pairs from Reduce()s
?
Example: word count
input is thousands of text files
Map(k, v)
split v into words
for each word w
emit(w, "1")
Reduce(k, v)
emit(len(v))
?
MapReduce scales well:
N "worker" computers get you Nx throughput.
Maps()s can run in parallel, since they don't interact.
Same for Reduce()s.
So you can get more throughput by buying more computers.</pre>
MapReduce 隱藏了很多細(xì)節(jié):
發(fā)送應(yīng)用代碼到服務(wù)器
追蹤哪個任務(wù)已經(jīng)完成
將數(shù)據(jù)從 Map 移動到 Reduce
在服務(wù)器之間進(jìn)行平衡加載調(diào)整
恢復(fù)失敗任務(wù)
MapReduce 限制了應(yīng)用能做的
沒有交互或者狀態(tài)(除了通過中間輸出)
沒有迭代垛膝，沒有多階段管道
沒有做到實(shí)時數(shù)據(jù)或者流數(shù)據(jù)處理
輸入和輸出存儲在 GFS 集群文件系統(tǒng)中鳍侣，MR 需要巨大的并行輸入和輸出吞吐量
GFS 需要把大型文件分割到多個服務(wù)器上，分成 64 MB 的文件塊
Map 并行讀取
Reduce 并行寫入
GFS 也把每個文件復(fù)制到2-3個服務(wù)器上吼拥，GFS 對 MapReduce 來說是巨大的勝利
限制性能的是什么倚聚？
CPU ？ 內(nèi)存 凿可？ 硬盤 惑折？ 網(wǎng)絡(luò)帶寬 ？
在 2004 年他們認(rèn)為是被網(wǎng)絡(luò)帶寬限制
對于排序來說枯跑，Map 從 GFS 讀取文件惨驶，Reduce 讀取 Map 的輸出可能和 輸入一樣大，Reduce 再把文件寫入 GFS
在 MR 的 all -to -all shuffle過程中敛助，一半以上的流量通過根交換機(jī)
論文中的根交換機(jī)：100-200 GB/s,一共1800臺服務(wù)器粗卜，也就是 55MB/s,55 Mb 很小，遠(yuǎn)低于磁盤或內(nèi)存速度
今天纳击，網(wǎng)絡(luò)和根交換機(jī)相對于CPU /磁盤快得多
論文中圖 1 的詳情
一個主節(jié)點(diǎn)续扔，將任務(wù)分配給 worker 節(jié)點(diǎn)并且記住任務(wù)進(jìn)度
主節(jié)點(diǎn)分給 worker節(jié)點(diǎn) Map 任務(wù)直到所有的 Map 任務(wù)完成，Map 節(jié)點(diǎn)把輸出（中間結(jié)果數(shù)據(jù)）到本地磁盤上焕数，Map 分割輸出纱昧，通過 hash分成每一個 Reduce 任務(wù)
-
等所有 Map 完成后，主節(jié)點(diǎn)分發(fā) Reduce 任務(wù)
每一個 Reduce 從 Map worker 節(jié)點(diǎn)拉取 中間輸出數(shù)據(jù)到 Reduce節(jié)點(diǎn)
每個 Reduce 任務(wù)寫入一個單獨(dú)的輸出文件到 GFS上
MR 如何 減小網(wǎng)絡(luò)帶寬使用
-
Master節(jié)點(diǎn)嘗試在GFS上面運(yùn)行它的每個Map任務(wù)存儲它的輸入
所有的計(jì)算機(jī)都運(yùn)行 GFS 和 MR worker
輸入從本地磁盤讀取而不是通過網(wǎng)絡(luò)
-
中間結(jié)果數(shù)據(jù)只在網(wǎng)絡(luò)中傳輸一次
Map 節(jié)點(diǎn)寫入本地磁盤
Reduce worker節(jié)點(diǎn)直接從Map 節(jié)點(diǎn)讀取百匆，而不是通過磁盤
中間結(jié)果數(shù)據(jù)拆分為包含很多 key 的文件
Reduce 遠(yuǎn)小于 key 的數(shù)量
大的網(wǎng)絡(luò)帶寬會更有效
MR 如何獲取良好的負(fù)載均衡
如果 N -1 個服務(wù)器必須等待 1個比較慢的服務(wù)器完成任務(wù)是比較浪費(fèi)的砌些，但是一些任務(wù)耗時肯呢個遠(yuǎn)大于其他的
解決方法: 任務(wù)數(shù)比worker節(jié)點(diǎn)數(shù)要更多
Master 節(jié)點(diǎn) 將新任務(wù)分發(fā)給完成之前任務(wù)的節(jié)點(diǎn)
因此，希望沒有一項(xiàng)任務(wù)會大到它可以主導(dǎo)完成時間
因此加匈，速度較快的服務(wù)器要比速度較慢的服務(wù)器執(zhí)行更多任務(wù)存璃，并同時完成。
容錯是什么
worker 節(jié)點(diǎn)在執(zhí)行 MR 任務(wù)時候崩潰怎么辦雕拼？
我們想要完全的向應(yīng)用開發(fā)程序員隱藏錯誤纵东，MR 需要重新運(yùn)行整個任務(wù)嗎，為何啥寇？
MR 只需要運(yùn)行 失敗的 Map 和 Reduce 任務(wù)
假設(shè) MR 運(yùn)行兩次 Map偎球，一個 Reduce 會看到第一次的 Map 輸出結(jié)果，
另一個 Reduce 會看到第二次的運(yùn)行結(jié)果
正確性要求重新執(zhí)行才能產(chǎn)生完全相同的輸出辑甜，因此 Map 和 Reduce 必須是純粹的確定性函數(shù)衰絮，他們只被允許看到他們的參數(shù)，沒有狀態(tài)磷醋，沒有文件 I/O,沒有交互猫牡，沒有額外的通信。
如果 想要允許非函數(shù)性的 Map 和 Reduce 怎么辦
worker 節(jié)點(diǎn)失敗需要整個任務(wù)重新執(zhí)行邓线，或者你需要創(chuàng)建全局的同步檢查點(diǎn)
worker 節(jié)點(diǎn)崩潰恢復(fù)詳情
-
Map worker節(jié)點(diǎn)崩潰
master 節(jié)點(diǎn)注意到 worker節(jié)點(diǎn)不再響應(yīng) ping
master 知道 哪一個 worker 節(jié)點(diǎn)上運(yùn)行的 Map 任務(wù)
那些中間結(jié)果數(shù)據(jù)現(xiàn)在已經(jīng)丟失淌友，必須重新創(chuàng)建
master 告訴其他節(jié)點(diǎn)來運(yùn)行那些失敗的任務(wù)
如果 Reduce 已經(jīng)獲取到中間結(jié)果數(shù)據(jù)的話煌恢，可以忽略重新運(yùn)行
-
Reduce 節(jié)點(diǎn)崩潰
任務(wù)完成就可以，存儲在GFS中震庭，同時有多個副本
master 在其他worker 節(jié)點(diǎn)上重啟那些 worker 節(jié)點(diǎn)沒有完成的任務(wù)
-
其他失敗問題
如果 master 給兩個 worker 節(jié)點(diǎn)相同的 Map() 任務(wù)怎么辦
可能 master 錯誤的認(rèn)為 一個 worker已經(jīng) 死掉了瑰抵，它會告訴 Reduce 節(jié)點(diǎn)只有一個 Map 任務(wù)
-
如果 master 給兩個 worker 節(jié)點(diǎn)相同的 Reduce() 任務(wù)怎么辦
- 他們都會嘗試寫入輸出文件到 GFS。GFS 原子命名可防止混淆器联，一個完成的文件將會可見
-
如果一個 worker 節(jié)點(diǎn)非常慢怎么辦 二汛？
可能是由于不可靠的硬件設(shè)備
master 啟動最近幾項(xiàng)任務(wù)的副本
woker 節(jié)點(diǎn)因?yàn)槟撤N原因，計(jì)算出不正確的輸出主籍，MR 會認(rèn)為停止故障的 CPU和軟件
master 節(jié)點(diǎn)宕機(jī)怎么辦
-
當(dāng)前狀態(tài)
影響巨大 (hadoop, spark)
可能在 Google 已經(jīng)不再使用
被 Flume / FlumeJava 所替代 (see paper by Chambers et al)
GFS 被 Colossus 和 BigTable 替代
總結(jié)
MapReduce 使得大集群計(jì)算變得流行
不是最高效的或者最穩(wěn)定的
擴(kuò)展性良好
編程簡單习贫，失敗錯誤和數(shù)據(jù)移動被隱藏掉了
這些都是在實(shí)踐中很好的權(quán)衡
