【正文】 aster修改數(shù)據(jù)結(jié)構(gòu)以記錄原始的子任務(wù)和新的后備子任務(wù)。初始化后備子任務(wù)的數(shù)據(jù)結(jié)構(gòu)，在和指定的Worker發(fā)送消息時將此新命令發(fā)出。在命令發(fā)出之后，Master還需要處理此子任務(wù)的結(jié)束。如果原始子任務(wù)和后備子任務(wù)其中一個完成，Master即認(rèn)為此子任務(wù)結(jié)束，并發(fā)停止執(zhí)行的命令給還未結(jié)束的Worker，以免浪費資源。然后是Worker端的處理。在這里的實現(xiàn)中，Worker對后備任務(wù)這一策略是透明的，如果Master發(fā)命令給Worker要求做一個任務(wù)，原始任務(wù)和后備任務(wù)在Worker看來是一樣的。 數(shù)據(jù)結(jié)構(gòu)細(xì)節(jié)同樣地，我們從Master和Worker兩方面來描述數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)細(xì)節(jié)。對于Master，在保證不規(guī)模修改實現(xiàn)接口的情況下，進(jìn)行了如下的實現(xiàn)。1） TaskInfo結(jié)構(gòu)：TaskInfo是記錄子任務(wù)信息的數(shù)據(jù)結(jié)構(gòu)，在之前的實現(xiàn)上添加了兩個域，用以標(biāo)明和區(qū)分后備子任務(wù)。/// if it is backup task: MAP/REDUCE onlybool isBackup。/// for backup task: original task id int32_t originalTaskId。一個是標(biāo)明此任務(wù)是否為后備任務(wù)，一個是記錄原始任務(wù)的ID。2） 在TaskManager中添加兩個輔助的數(shù)據(jù)結(jié)構(gòu)，用來在添加后備任務(wù)以及判定完成情況時處理。/// task status map: record status of map/reduce tasks with each job, task is pleted when either backup task or orginal task pletedstd::mapint32_t, std::mapint32_t, bool m_jobid2tasksIsCompleted。/// backup task map: one task only have a single backup task at one timestd::mapint32_t, bool m_taskid2backing。第一個map是記錄各個job中的task是否完成，如果有后備子任務(wù)，只要原始任務(wù)和后備子任務(wù)中其中一個完成就算此任務(wù)完成。第二個map是記錄各個任務(wù)是否有后備任務(wù)，在這里使用map是因為后備任務(wù)的查看和處理過程中需要經(jīng)?？丛既蝿?wù)的狀態(tài)，所以使用map避免Master端大規(guī)模的掃描任務(wù)隊列，成為性能瓶頸。此外，這里的一對一映射保證了一個原始子任務(wù)最多只有一個后備子任務(wù)，這是為了防止造成多個后備任務(wù)出現(xiàn)而造成開銷太大，或者是后備子任務(wù)再次成為落后者引起級聯(lián)反饋的效果后浪費系統(tǒng)的資源。 后備任務(wù)策略評估實驗 機群配置和任務(wù)準(zhǔn)備我們的機群配置如下。我們在后備任務(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千兆路由器鏈接。我們實驗使用的是PennySort程序來進(jìn)行評估。生成了50M的Record。 任務(wù)耗時趨同性分析。我們的假設(shè)是，對于同一個任務(wù)的同種類型的任務(wù)基本上會在相同的時間內(nèi)完成。我們對與選定的基準(zhǔn)程序集合的任務(wù)集合的耗時情況進(jìn)行分析如下表，可以看到它們耗時的標(biāo)準(zhǔn)差和均值的比例并不高，說明這些任務(wù)基本上是在相同的時間內(nèi)完成的。表格 4任務(wù)耗時趨同性分析CostTime(seconds)/TypePageRankPennySortWordCountAvg. Map Stdev. Map Stdev/Avg. Map%%%　　　　 Stdev. Reduce Stdev/Avg. Reduce%%%　　　　Avg. Transfer Stdev. Transfer Stdev/Avg. Transfer%%%從上表中我們可以看出，同一個任務(wù)的同種類型任務(wù)會趨向一致完成。表現(xiàn)在表中的數(shù)據(jù)有兩點：1） 任務(wù)平均耗時較長，但是標(biāo)準(zhǔn)差都很小，標(biāo)準(zhǔn)差和平均值的比值在10%以內(nèi)，表明這種類型的任務(wù)都趨向均值的時間結(jié)束，浮動的范圍很??；2） 任務(wù)的耗時標(biāo)準(zhǔn)差和平均值的比值在10%之上，但是耗時的絕對值比較小，也可以認(rèn)為趨向一致完成這些任務(wù)。經(jīng)上述分析，我們驗證了在設(shè)計之初做出的假設(shè)，實驗說明我們的設(shè)計假設(shè)在我們的應(yīng)用環(huán)境中是合適的。 后備任務(wù)策略評估對于后備任務(wù)策略的評估，我們首先模擬出落后者的Worker，然后評估后備任務(wù)的效果。落后者的原因我們在前面的章節(jié)分析過，模擬要達(dá)到的目標(biāo)是讓落后者的Worker執(zhí)行原任務(wù)的時候會顯著變慢。我們從三方面來考慮模擬，一個是讓模擬的那臺機器額外地執(zhí)行一個計算密集型的程序；一個事讓其額外地執(zhí)行一個I/O密集型的程序；最后一種是模擬Worker運行中可能出現(xiàn)的異常而導(dǎo)致變慢，從而達(dá)到該機器在執(zhí)行MapReduce系統(tǒng)分配的任務(wù)時變慢。我們在下面列出模擬的程序和實現(xiàn)說明如下：i. 計算密集型includecstdlibusing namespace std。int main(){ int count = 0。 while(1){ count ++。 if(count % 1000000000 == 0){ sleep(10)。 } } return 0。}此程序利用死循環(huán)模擬計算密集型的任務(wù)，用來模擬機器因為同時并發(fā)執(zhí)行此種任務(wù)而導(dǎo)致落后的情況，其中的常數(shù)設(shè)置可以根據(jù)機器的性能和實際情況在實驗中調(diào)整。ii. I/O密集型includecstdlibincludefstreamusing namespace std。int main(){ while(1){ const int BUFSIZE = 64 * 1024 *1024。 char* buffer = new char[BUFSIZE]。 ofstream fout(, ios::out)。 (buffer, BUFSIZE * sizeof(char) )。 ()。 sleep(10)。 } return 0。}此程序利用寫文件來模擬I/O密集型的任務(wù)，用來模擬機器因為同時并發(fā)執(zhí)行此種任務(wù)而導(dǎo)致落后的情況，其中的常數(shù)設(shè)置可以根據(jù)機器的性能和實際情況在實驗中調(diào)整。iii. 異常模擬此外，我們根據(jù)可能發(fā)生的情況，還模擬了異?？赡軐?dǎo)致落后的情況。我們在一臺硬盤即將被寫滿的機器上做了這個實驗。當(dāng)Master把任務(wù)分配在這臺機器上時，由于硬盤無法寫入而導(dǎo)致異常，并可能導(dǎo)致機器成為落后者。然后我們針對PennySort這個任務(wù)，進(jìn)行后備任務(wù)的評估。實驗分別在普通情況、模擬I、模擬II、模擬III（說明見上）上進(jìn)行，考察的系統(tǒng)性能指標(biāo)是單任務(wù)的延遲。下圖是評估結(jié)果。從圖中可以看出，后備任務(wù)對落后者的改善很大。如果有落后者出現(xiàn)，基于模擬實驗可知，后備任務(wù)能夠有效地改善任務(wù)的延遲。同時，我們還可以分析得到，PennySort基本上也是一個I/O型瓶頸的任務(wù)，I/O密集型的落后者能夠較長時間拖任務(wù)的后腿；而計算型的卻不然，改善也不大。圖表 8后備任務(wù)策略評估此外，我們注意到，異常也可能造成任務(wù)的延遲大幅增加。而在大規(guī)模數(shù)據(jù)中心內(nèi)，各種異常的出現(xiàn)是很正常的現(xiàn)象，這也說明了后備任務(wù)可以在大規(guī)模數(shù)據(jù)中心內(nèi)起到重要作用。第 7 章 系統(tǒng)優(yōu)化方向根據(jù)我們對系統(tǒng)的分析和評估，以及我們在Tplatform平臺的日常使用中的經(jīng)驗，除了已經(jīng)實現(xiàn)的后備任務(wù)策略，我們針對分析得出的其他系統(tǒng)優(yōu)化方向，進(jìn)行分析和探討。 網(wǎng)絡(luò)傳輸問題在MapReduce的模型和體系結(jié)構(gòu)的實現(xiàn)中，需要進(jìn)行網(wǎng)絡(luò)的傳輸任務(wù)，也就是在reduce階段需要把map生成的數(shù)據(jù)傳到reduce對應(yīng)的機器上。在這個階段很多應(yīng)用程序可能生成大量的中間數(shù)據(jù)，而經(jīng)過我們的之前的分析，網(wǎng)絡(luò)會成為MapReduce系統(tǒng)的性能瓶頸。所以，如果優(yōu)化網(wǎng)絡(luò)的傳輸，減少不必要的中間數(shù)據(jù)，也是一個直接和實際的系統(tǒng)優(yōu)化問題。在網(wǎng)絡(luò)傳輸?shù)膯栴}上，可以有不同的研究方向：1） 如何優(yōu)化機群的網(wǎng)絡(luò)傳輸，考慮在此環(huán)境下機器的路由和網(wǎng)絡(luò)層的優(yōu)化問題。已經(jīng)有一些研究工作在這個方向上進(jìn)行，如DCell Chuanxiong Guo etc., DCell: A Scalable and FaultTolerant Network Structure for Data Centers, proceedings of SIGCOMM, 2008.、Fat Tree AlFares, Loukissas, Vahdat, A Scalable, Commodity Data Center Network Architecture, proceedings of SIGCOMM, 2008.。2） 如何通過優(yōu)化負(fù)載和任務(wù)等不同粒度上的調(diào)度，來優(yōu)化系統(tǒng)的網(wǎng)絡(luò)傳輸。3） 如何有效地利用應(yīng)用程序的數(shù)據(jù)特征，使得系統(tǒng)可以充分利用數(shù)據(jù)的時間和空間局部性，從而減少產(chǎn)生的中間數(shù)據(jù)，最后達(dá)到優(yōu)化網(wǎng)絡(luò)傳輸問題的目的。此外，還有其他方向和角度來考慮這個問題。從我們的日常使用經(jīng)驗來看，網(wǎng)絡(luò)通常是比硬盤I/O更容易成為瓶頸。 增加用戶和系統(tǒng)的交互在MapReduce的體系框架下，系統(tǒng)對用戶掩蓋了很多系統(tǒng)細(xì)節(jié)，同時簡單的計算模型也使得大量的并行細(xì)節(jié)對用戶來說并不透明。Google對于MapReduce的此設(shè)計目的在于掩蓋細(xì)節(jié)，使得用戶只是簡單的實現(xiàn)Map函數(shù)和Reduce函數(shù)，就可以進(jìn)行大規(guī)模的數(shù)據(jù)處理。但是我們發(fā)現(xiàn)，在實際使用中過于簡單的模型和不透明也會帶來性能問題。用戶對系統(tǒng)的不了解可能造成重復(fù)計算或者浪費用戶的時間，用戶白白等待無效的計算等等情況。所以此方向我們需要研究的是，哪些系統(tǒng)實現(xiàn)細(xì)節(jié)是有必要對用戶掩蓋的，哪些系統(tǒng)實現(xiàn)細(xì)節(jié)如果用戶知道能夠使得一個專家級的用戶更好地控制系統(tǒng)和對應(yīng)用程序進(jìn)行優(yōu)化。同時，我們還需要研究的是，在應(yīng)用程序?qū)用嫔蟻砜?，哪些信息如果讓系統(tǒng)知道，能夠更好更高效地執(zhí)行應(yīng)用程序；此外，為了更好地讓系統(tǒng)了解應(yīng)用程序，系統(tǒng)應(yīng)該提供什么樣的接口或者配置讓用戶方便地和系統(tǒng)進(jìn)行交互?？傊?，我們認(rèn)為，系統(tǒng)和用戶不應(yīng)該是孤立的，系統(tǒng)對用戶也不是完全透明的，同時系統(tǒng)對用戶的應(yīng)用程序也不是一無所知的。系統(tǒng)應(yīng)該多了解用戶的行為和應(yīng)用程序的特點，同時用戶也需要更了解系統(tǒng)。用戶和系統(tǒng)之間的交互應(yīng)該增加。 從數(shù)據(jù)庫領(lǐng)域看系統(tǒng)性能的其他提升空間關(guān)于MapReduce和分布式數(shù)據(jù)庫到底有什么不同，是目前人們爭論的一個焦點 Andrew Pavlo. Erik Paulson. Alexander Rasin etc., A Comparison of Approaches to LargeScale Data Analysis, proceedings of SIGMOD, 2009.。數(shù)據(jù)庫通過很多年的發(fā)展對數(shù)據(jù)的存儲和計算，以及用戶使用的語言等等都做了大量的研究并發(fā)展了很多成熟的技術(shù)。但是在MapReduce這樣類似的“云計算”環(huán)境下，數(shù)據(jù)庫的技術(shù)是否在MapReduce系統(tǒng)的研究中可以參考和借鑒，哪些可以參考和借鑒，什么樣的任務(wù)是分布式數(shù)據(jù)庫難以勝任的，什么樣的任務(wù)是MapReduce難以勝任的，他們兩種體系的計算引擎的本質(zhì)區(qū)別到底是什么？這些都是亟待解決的問題，也是人們關(guān)心和爭論的焦點。我們針對其中的一些問題，可以進(jìn)行研究。比如索引的使用，在分布式數(shù)據(jù)庫中是很正常和成熟的技術(shù)。MapReduce的系統(tǒng)中是不支持索引的，對于一些任務(wù)來說，如果使用MapReduce的框架來進(jìn)行處理，將是比較低效的21。但是如何在MapReduce這樣的體系下使用索引還是一個需要研究的問題。 系統(tǒng)易用性我們通過日常的使用發(fā)現(xiàn)，MapReduce程序的編寫還是過于底層，通常一些簡單的任務(wù)如日志分析等等需要花費比較長的時間來編寫。對記錄層級的數(shù)據(jù)進(jìn)行直接處理和使用文件系統(tǒng)作為底層存儲也會對易用性造成一些問題，現(xiàn)在有一些高層語言來處理這些問題，如Pig Latin3等，但是系統(tǒng)的易用性和語言的問題仍然是一個需要不斷研究的問題。