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