map中間結(jié)果不壓縮：

map中間結(jié)果壓縮：

可以看出，同樣的job，同樣的數(shù)據(jù)，在采用壓縮的情況下，map中間結(jié)果能縮小將近10倍，如果map的瓶頸在磁盤(pán)，那么job的性能提升將會(huì)非?？捎^。

當(dāng)采用map中間結(jié)果壓縮的情況下，用戶還可以選擇壓縮時(shí)采用哪種壓縮格式進(jìn)行壓縮，現(xiàn)在hadoop支持的壓縮格式有：GzipCodec，LzoCodec，BZip2Codec，LzmaCodec等壓縮格式。通常來(lái)說(shuō)，想要達(dá)到比較平衡的cpu和磁盤(pán)壓縮比，LzoCodec比較適合。但也要取決于job的具體情況。用戶若想要自行選擇中間結(jié)果的壓縮算法，可以設(shè)置配置參數(shù)：mapred.map.output.compression.codec=org.apache.hadoop.io.compress.DefaultCodec或者其他用戶自行選擇的壓縮方式。

1.2 Map side相關(guān)參數(shù)調(diào)優(yōu)

2 Reduce side tuning參數(shù)

2.1 ReduceTask運(yùn)行內(nèi)部原理

reduce的運(yùn)行是分成三個(gè)階段的。分別為copy->sort->reduce。由于job的每一個(gè)map都會(huì)根據(jù)reduce(n)數(shù)將數(shù)據(jù)分成map 輸出結(jié)果分成n個(gè)partition，所以map的中間結(jié)果中是有可能包含每一個(gè)reduce需要處理的部分?jǐn)?shù)據(jù)的。所以，為了優(yōu)化reduce的執(zhí)行時(shí)間，hadoop中是等job的第一個(gè)map結(jié)束后，所有的reduce就開(kāi)始嘗試從完成的map中下載該reduce對(duì)應(yīng)的partition部分?jǐn)?shù)據(jù)。這個(gè)過(guò)程就是通常所說(shuō)的shuffle，也就是copy過(guò)程。

Reduce task在做shuffle時(shí)，實(shí)際上就是從不同的已經(jīng)完成的map上去下載屬于自己這個(gè)reduce的部分?jǐn)?shù)據(jù)，由于map通常有許多個(gè)，所以對(duì)一個(gè)reduce來(lái)說(shuō)，下載也可以是并行的從多個(gè)map下載，這個(gè)并行度是可以調(diào)整的，調(diào)整參數(shù)為：mapred.reduce.parallel.copies（default 5）。默認(rèn)情況下，每個(gè)只會(huì)有5個(gè)并行的下載線程在從map下數(shù)據(jù)，如果一個(gè)時(shí)間段內(nèi)job完成的map有100個(gè)或者更多，那么reduce也最多只能同時(shí)下載5個(gè)map的數(shù)據(jù)，所以這個(gè)參數(shù)比較適合map很多并且完成的比較快的job的情況下調(diào)大，有利于reduce更快的獲取屬于自己部分的數(shù)據(jù)。

reduce的每一個(gè)下載線程在下載某個(gè)map數(shù)據(jù)的時(shí)候，有可能因?yàn)槟莻€(gè)map中間結(jié)果所在機(jī)器發(fā)生錯(cuò)誤，或者中間結(jié)果的文件丟失，或者網(wǎng)絡(luò)瞬斷等等情況，這樣reduce的下載就有可能失敗，所以reduce的下載線程并不會(huì)無(wú)休止的等待下去，當(dāng)一定時(shí)間后下載仍然失敗，那么下載線程就會(huì)放棄這次下載，并在隨后嘗試從另外的地方下載（因?yàn)檫@段時(shí)間map可能重跑）。所以reduce下載線程的這個(gè)最大的下載時(shí)間段是可以調(diào)整的，調(diào)整參數(shù)為：mapred.reduce.copy.backoff（default 300秒）。如果集群環(huán)境的網(wǎng)絡(luò)本身是瓶頸，那么用戶可以通過(guò)調(diào)大這個(gè)參數(shù)來(lái)避免reduce下載線程被誤判為失敗的情況。不過(guò)在網(wǎng)絡(luò)環(huán)境比較好的情況下，沒(méi)有必要調(diào)整。通常來(lái)說(shuō)專業(yè)的集群網(wǎng)絡(luò)不應(yīng)該有太大問(wèn)題，所以這個(gè)參數(shù)需要調(diào)整的情況不多。

Reduce將map結(jié)果下載到本地時(shí)，同樣也是需要進(jìn)行merge的，所以io.sort.factor的配置選項(xiàng)同樣會(huì)影響reduce進(jìn)行merge時(shí)的行為，該參數(shù)的詳細(xì)介紹上文已經(jīng)提到，當(dāng)發(fā)現(xiàn)reduce在shuffle階段iowait非常的高的時(shí)候，就有可能通過(guò)調(diào)大這個(gè)參數(shù)來(lái)加大一次merge時(shí)的并發(fā)吞吐，優(yōu)化reduce效率。

Reduce在shuffle階段對(duì)下載來(lái)的map數(shù)據(jù)，并不是立刻就寫(xiě)入磁盤(pán)的，而是會(huì)先緩存在內(nèi)存中，然后當(dāng)使用內(nèi)存達(dá)到一定量的時(shí)候才刷入磁盤(pán)。這個(gè)內(nèi)存大小的控制就不像map一樣可以通過(guò)io.sort.mb來(lái)設(shè)定了，而是通過(guò)另外一個(gè)參數(shù)來(lái)設(shè)置：
mapred.job.shuffle.input.buffer.percent（default 0.7），這個(gè)參數(shù)其實(shí)是一個(gè)百分比，意思是說(shuō)，shuffile在reduce內(nèi)存中的數(shù)據(jù)最多使用內(nèi)存量為：0.7 × maxHeap of reduce task。也就是說(shuō)，如果該reduce task的最大heap使用量（通常通過(guò)mapred.child.java.opts來(lái)設(shè)置，比如設(shè)置為-Xmx1024m）的一定比例用來(lái)緩存數(shù)據(jù)。默認(rèn)情況下，reduce會(huì)使用其heapsize的70%來(lái)在內(nèi)存中緩存數(shù)據(jù)。如果reduce的heap由于業(yè)務(wù)原因調(diào)整的比較大，相應(yīng)的緩存大小也會(huì)變大，這也是為什么reduce用來(lái)做緩存的參數(shù)是一個(gè)百分比，而不是一個(gè)固定的值了。

 2/3   首頁(yè) 上一頁(yè) 1 2 3 下一頁(yè) 尾頁(yè)