【文章內(nèi)容簡介】 任務(wù)中，輸出的字節(jié)數(shù)除以輸入的字節(jié)數(shù)3） Reduce任務(wù)的選擇度：在平均的Reduce任務(wù)中，輸出的字節(jié)數(shù)除以輸入的字節(jié)數(shù)4） Map任務(wù)的平均字節(jié)計算時間：在Map任務(wù)中計算一個字節(jié)需要的平均時間5） Reduce任務(wù)的平均字節(jié)計算時間：在Reduce任務(wù)中計算一個字節(jié)需要的平均時間6） 數(shù)據(jù)的壓縮率：分布式文件系統(tǒng)中該基準程序的數(shù)據(jù)壓縮率。（注：在我們的實驗中暫不考慮此項屬性）7） Map的方式：是選擇一部分數(shù)據(jù)還是對Chunk中所有數(shù)據(jù)進行順序讀入。8） 傳輸?shù)姆绞剑涸谶M行傳輸任務(wù)時時候有偏移，對數(shù)據(jù)的分割狀況是怎么樣的，是否做到分割上的負債均衡。9） 中間數(shù)據(jù)大?。簜鬏?shù)臅r候中間數(shù)據(jù)的字節(jié)數(shù)。10） Reduce的參數(shù)：是否需要數(shù)據(jù)做外排。11） Map任務(wù)的復(fù)雜度：比如，為O(n)12） Reduce任務(wù)的復(fù)雜度：比如，為O(n)我們選擇能夠代表典型MapReduce過程的PennySort，來實例說明基準程序在我們的實驗系統(tǒng)上各指標的值。實驗數(shù)據(jù)是50M條記錄的PennySort。表格 150M PennySort系統(tǒng)評估任務(wù)大小，Map任務(wù)75個，Reduce14個Map任務(wù)的選擇度1Reduce任務(wù)的選擇度1Map任務(wù)的平均字節(jié)計算時間 SecondsReduce任務(wù)的平均字節(jié)計算時間 Seconds數(shù)據(jù)的壓縮率暫不考慮Map的方式對Chunk所有數(shù)據(jù)順序讀入傳輸?shù)姆绞骄鶆蚍植贾虚g數(shù)據(jù)大小Reduce的參數(shù)不需要外排Map任務(wù)的復(fù)雜度O(n)Reduce任務(wù)的復(fù)雜度nO(logn)我們說明和分析表中的數(shù)值。首先，Map和Reduce的任務(wù)的選擇度都是1，因為對于PennySort來說，Map做的是把數(shù)據(jù)簡單地讀入，然后進行傳輸和分割，而對Reduce來說，進行完數(shù)據(jù)的排序后也只需要把數(shù)據(jù)簡單地輸出，所以選擇度都是1.然后，對于傳輸?shù)姆绞?，按記錄的生成原則，可以均稱地進行hash分割。中間數(shù)據(jù)比初始讀入的數(shù)據(jù)反而小是因為很多數(shù)據(jù)Map任務(wù)做完后可以在本地直接進行Reduce，利用的數(shù)據(jù)的空間數(shù)據(jù)性，所以傳輸數(shù)據(jù)變小。最后Reduce任務(wù)需要進行排序，系統(tǒng)實現(xiàn)使用快排，復(fù)雜度為nO(logn).第 4 章 系統(tǒng)監(jiān)控和程序概要分析更好地理解和監(jiān)控云計算的基礎(chǔ)設(shè)施系統(tǒng)如MapReduce是一個煩人且亟待解決的問題。現(xiàn)有的實現(xiàn)都是比較簡單地記錄系統(tǒng)的相關(guān)性能信息，而且并沒有太多關(guān)于在此類系統(tǒng)中如何監(jiān)控和評估的工作。但是在我們的開發(fā)和使用過程中，我們發(fā)現(xiàn)了系統(tǒng)的性能概要分析很重要，或者說通過更好地理解底層系統(tǒng)，能夠更好地改善和優(yōu)化現(xiàn)有的系統(tǒng)。例如如下的幾個場景中，我們將說明這一點:數(shù)據(jù)中心中的一個程序員向系統(tǒng)提交了一個用高層語言如Pig Latin描述的任務(wù)后，他/她可能想知道他的任務(wù)做到什么程度。從性能概要分析的角度來考慮任務(wù)監(jiān)控這個問題，任務(wù)在多個機器上的性能分布很重要。這樣可以知道任務(wù)中最耗時的函數(shù)，從來讓程序員可以針對此考慮改進自己的程序，或者在系統(tǒng)對任務(wù)的編譯中進行優(yōu)化。失效在數(shù)據(jù)中心里面是正常的1。MapReduce這樣的系統(tǒng)對用戶掩蓋機器的失效，如果機器發(fā)生宕機，系統(tǒng)將處理并調(diào)度計算重執(zhí)行；而對于計算任務(wù)的失效，處理方式是重新執(zhí)行，如果多次失效超過一定次數(shù)，將放棄執(zhí)行。這是因為在數(shù)據(jù)中心中， 很有可能是用戶提交的任務(wù)的程序中存在BUG，或者是數(shù)據(jù)有不滿足格式而導(dǎo)致無法讀入等等。對于需要進行長任務(wù)處理的工作來說，在現(xiàn)有系統(tǒng)的實現(xiàn)下，可能是一件極消耗用戶程序員精力的事情?？赡艿那樾问牵瑘?zhí)行了很久到快結(jié)束的時候由于BUG或者存儲的問題導(dǎo)致失敗而最終放棄。 而實時的監(jiān)控和交互可以部分地解決這個問題，讓用戶及時地知道系統(tǒng)里面發(fā)生的情況，對于系統(tǒng)無法做出判斷的事情（程序有錯），交給用戶去解決不失為一個可行的方案。分布式系統(tǒng)中的一個很重要的措施就是要保證負載均衡，這對于并行計算的框架來說，同樣意義重大。在計算的過程中記錄性能信息和進行監(jiān)控，可以通知用戶或者系統(tǒng)。通過重新的調(diào)度或者其他手段使得負載盡可能均衡?？傊?，通過監(jiān)控和程序的性能概要分析，我們可以讓系統(tǒng)和用戶之間有更多交互。同時給出的數(shù)據(jù)可以幫助用以評估系統(tǒng)，提供給不同的人如用戶或者系統(tǒng)開發(fā)人員分析。 實現(xiàn)細節(jié)我們需要記錄一個子任務(wù)的運行時性能概要信息，通過以下的數(shù)據(jù)結(jié)構(gòu)來實現(xiàn)。 struct ProfileInfo { // for map task int mapFanIn。 int mapFanOut。 int mapRecordNumber。 int localCombineFanIn。 int localCombineFanOut。 int localCombineRecordNumber。 // for reduce task int reduceFanIn。 int reduceFanOut。 int reduceRecordNumber // for transfer task int transferIO。 int transferRecordNumber。 // cost time, by seconds int taskCostTime。 }。對于Map階段，分別記錄扇入扇出的數(shù)據(jù)大小、map的記錄個數(shù)；以及做localbine的扇入扇出、記錄個數(shù)；對于Reduce階段，記錄扇入扇出的數(shù)據(jù)大小、reduce的記錄個數(shù)；還有傳輸任務(wù)的傳輸數(shù)據(jù)量；最后是各個任務(wù)的花費時間。通過在Worker端執(zhí)行任務(wù)后記錄下任務(wù)的性能概要情況，然后通過文件管道傳遞給Worker的心跳進程，然后通過心跳捎帶給Master以供分析。進行捎帶處理的心跳使用rpc實現(xiàn)，具體實現(xiàn)如下。先使用ICE的slice描述rpc的接口。 /** * report to the master the task is successfully pleted. * * @param taskID * @param profileInfo, send the profileInfo piggybackly */ idempotent void pleteTask(Address workerAddress, int taskID, ProfileInfo taskProfile)。然后經(jīng)過ICE的編譯后生成服務(wù)器端和客戶端的C++代碼，然后把任務(wù)的性能概要信息發(fā)送給Master端。第 5 章 評估實驗在這一章中，我們將對上一章中設(shè)定的系統(tǒng)性能指標進行評估。并闡述每一項實驗的環(huán)境、應(yīng)用程序和結(jié)果分析。 機群配置我們的機群配置如下。我們在后備任務(wù)策略的評估實驗中使用了一臺Master、十四臺Worker組成的MapReduce系統(tǒng)集群。所有的機器都是Dell 2850服務(wù)器，每臺機器配置為2顆Intel Xeon處理器，2GB內(nèi)存，6個7200 rpm SCSI硬盤組成一個RAID0的邏輯卷。這些機器存放在兩個機架中，各有一臺Dell 2748 1Gbps交換機，機器通過一個1Gbps的全雙工以太網(wǎng)卡與交換機相連接，兩個機架通過一個Cisco千兆路由器鏈接。 實驗結(jié)果 單任務(wù)延遲和總機器時間我們使用的工作負載的數(shù)據(jù)規(guī)模如下：1) WordCount，使用LocalCombine。2) PennySort。3) PageRank。我們實驗所得到的單任務(wù)延遲和總機器時間如下：表格 2延遲和總機器時間Type/Time secsLatencyTotal MachineWordCount1322013PennySort2704789PageRank140727其中，單任務(wù)延遲為用戶提交任務(wù)到任務(wù)完全結(jié)束所用時間。而總機器時間為提交任務(wù)的各個子任務(wù)（包括Map、Reduce、Transfer三種任務(wù)）的完成時間之和，度量的是對于整個機群來說的總機器時間。 平均結(jié)束時間我們使用上一節(jié)中的三個評估任務(wù)，同時提交給系統(tǒng)，并得到平均的結(jié)束時間。用以衡量在一段時間內(nèi)，系統(tǒng)對多個任務(wù)的吞吐量。我們以平均結(jié)束時間來進行評估。經(jīng)過實驗得到三個任務(wù)的平均結(jié)束時間為212秒，所以我們可以通過此項評估來考慮系統(tǒng)是否能夠?qū)σ慌蝿?wù)進行優(yōu)化處理。我們對我們的系統(tǒng)進行分析和實時監(jiān)控，發(fā)現(xiàn)之所以慢于平均延遲，是因為對于Word Count和PageRank的一些Map被安排到比較靠后的位置執(zhí)行，雖然機群中有空閑的機器，但是整個系統(tǒng)需要等待這些Map任務(wù)執(zhí)行完后才能執(zhí)行Reduce任務(wù)，從而增加了延遲。這也使得我們考慮后備任務(wù)的策略和更加合理的調(diào)度，使得空閑的資源能夠充分被利用，改善這些系統(tǒng)的評估目標。 加速比加速比和系統(tǒng)的可擴展性是MapReduce和類似系統(tǒng)的一個很重要的特性，正是因為非常良好的可擴展性，才使得MapReduce和其他的分布式系統(tǒng)區(qū)別開來，因為MapReduce系統(tǒng)可以很好地部署在超大規(guī)模的機群上。在本節(jié)的實驗里面，我們從兩方面來考察系統(tǒng)的可擴展性。第一個實驗測試在同一個規(guī)模的輸入數(shù)據(jù)和相同的配置下，Worker的增加對提交任務(wù)的延遲的影響。我們限制每臺機器可以同時運行的任務(wù)是3，傳輸任務(wù)的限制是2。，從圖中可以看到，運行的任務(wù)延遲隨Worker的增加而降低，說明此系統(tǒng)有良好的加速比。圖表 3系統(tǒng)加速比實驗第二個實驗測試在不同的規(guī)模和相同的配置下進行，Worker的增加和數(shù)據(jù)規(guī)模成同樣的比例。從圖中可以看到，運行的任務(wù)延遲基本保持同樣的水平，表明此系統(tǒng)有良好的可擴展性。我們的數(shù)據(jù)規(guī)模分別為：4) WordCount，、5) PennySort，、。6) PageRank，、450W條URL共6G。注意PageRank由于相互間鏈接增加的原因數(shù)據(jù)規(guī)模增加斜率大于線性增加。這三個不同大小的數(shù)據(jù)集合分別在14臺機器上運行。圖表 4系統(tǒng)可擴展性實驗結(jié)果如下： 公平性對于公平的定義，在不同的應(yīng)用場合有不同的評估方法，我們在這一節(jié)的評估中，簡單地先考慮一種場景，并評估我們系統(tǒng)的公平性。我們進行如下的實驗：先提交一個長任務(wù)，然后過一段時間提交一個短任務(wù)。評估系統(tǒng)的調(diào)度對此短任務(wù)來說是否公平。我們準備的長任務(wù)是500M條記錄的PennySort，數(shù)據(jù)規(guī)模為50G，在我們以前的實驗中，我們的系統(tǒng)大約需要2900秒才能完成此任務(wù)，它屬于長任務(wù)。同時我們準備了一個短任務(wù)，是10M條記錄的PennySort，數(shù)據(jù)規(guī)模是960M，在我們以前的實驗中大約只需要50秒就能完成。這里我們使用的任務(wù)類型是一樣的，都是做排序，我們僅僅考慮任務(wù)的完成時間對公平性的影響，在實際應(yīng)用中可能還會考慮提交任務(wù)的權(quán)重等等，這些具體的應(yīng)用不是我們考慮的范圍。這里長任務(wù)我們記為L（long）任務(wù)，短任務(wù)我們記為S（short）任務(wù)。通過實驗我們發(fā)現(xiàn)，由于S任務(wù)的很多子任務(wù)沒有得到及時調(diào)度，在S任務(wù)提交后，經(jīng)過356秒才完成了S任務(wù)，而最后L任務(wù)的延遲為2791秒，基本沒有受到短任務(wù)的影響。但是由于調(diào)度的不合理，對于S任務(wù)來說調(diào)度是不公平的，它提交了很長一段時間后部分子任務(wù)才得到處理。 故障恢復(fù)穩(wěn)定性在分析和測試評估MapReduce和類似系統(tǒng)時，一個重要的方面就是這些系統(tǒng)的容錯性，因為各種故障在這樣的系統(tǒng)中是屬于正常情況的。我們通過實驗?zāi)M各種故障的發(fā)生：如殺死Worker進程模擬宕機、硬盤寫滿或其他模擬硬盤出錯、突然中斷一些Worker之間的網(wǎng)絡(luò)通信等等。利用這些模擬的實驗來評估系統(tǒng)的穩(wěn)定性。實驗表明，一個高穩(wěn)定性的系統(tǒng)才能在這樣的環(huán)境中良好地工作。我們系統(tǒng)的穩(wěn)定性也是未來工作的一個方向。 實驗結(jié)果和性能問題分析我們通過實驗和分析系統(tǒng)，發(fā)現(xiàn)了一些系統(tǒng)的性能問題。列舉一些我們覺得目前可能成為瓶頸的如下：1） 一些機器相較別的機器的慢速，成為落后者，會極大地增加任務(wù)完成的延遲。由下圖可以看到，大部分的任務(wù)完成時間趨同，而個別任務(wù)顯著地比其他任務(wù)慢，導(dǎo)致最終的延遲降低，成為落后者。這就是落后者的問題表現(xiàn)。圖表 5落后者任