hadoop性能調(diào)優(yōu)的重要參數(shù)設(shè)置技巧是怎樣的

本篇文章為大家展示了hadoop性能調(diào)優(yōu)的重要參數(shù)設(shè)置技巧是怎樣的，內(nèi)容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細(xì)介紹希望你能有所收獲。

hadoop 性能調(diào)優(yōu) 重要參數(shù)設(shè)置技巧

分類： hadoop2012-12-16
19:53 43人閱讀 評論(0) 收藏 舉報(bào)

這里主要針對Mapreduce的性能調(diào)優(yōu)。

這一兩個(gè)月在做mapreduce的性能調(diào)優(yōu)，有些心得，還是要記下來的，以郷后人~

這里主要涉及的參數(shù)包括：

HDFS：

dfs.block.size

Mapredure：

io.sort.mb

io.sort.spill.percent

mapred.local.dir

mapred.map.tasks & mapred.tasktracker.map.tasks.maximum

mapred.reduce.tasks & mapred.tasktracker.reduce.tasks.maximum

mapred.reduce.max.attempts

mapred.reduce.parallel.copies

mapreduce.reduce.shuffle.maxfetchfailures

mapred.child.java.opts

mapred.reduce.tasks.speculative.execution

mapred.compress.map.output & mapred.map.output.compression.codec

mapred.reduce.slowstart.completed.maps

這里一共列出了十六個(gè)參數(shù)，這十六個(gè)參數(shù)基本上能滿足一般情況下，不針對特定場景應(yīng)用的性能調(diào)優(yōu)了，下面我將以Terasort為例，詳述這些參數(shù)的作用已經(jīng)如何配比調(diào)優(yōu)。

       hadoop的HDFS作為mapreduce的基礎(chǔ)分布式文件系統(tǒng)，對mapred的運(yùn)行效果也有直接的影響。首先影響到我們的性能的參數(shù)就是block.size，在網(wǎng)絡(luò)環(huán)境很好的集群中，建議將這個(gè)參數(shù)提升，大小可以到128或256或更大（默認(rèn)64M）。

        但是HDFS的影響也僅限于此，而且其配置項(xiàng)多數(shù)都是目錄配置以及容錯(cuò)，還有備份數(shù)等等，這些對于我們性能調(diào)優(yōu)意義不大?？梢耘e一個(gè)例子，那就是備份數(shù)。這個(gè)參數(shù)主要是用于設(shè)置block在集群中的備份數(shù)，這些備份將按照某種規(guī)則分配在集群的各個(gè)機(jī)器上，默認(rèn)是3備份。但是由于mapred的map需要輸入數(shù)據(jù)，一般默認(rèn)情況是一個(gè)map一個(gè)block，那么當(dāng)你在集群起job，一個(gè)job拉起來N多的map在一個(gè)機(jī)器執(zhí)行時(shí)，如果這個(gè)map的輸入數(shù)據(jù)是本地的，那么顯然map的執(zhí)行將會(huì)更快，因?yàn)椴恍枰却W(wǎng)絡(luò)傳輸。拿四個(gè)節(jié)點(diǎn)為例，如果你設(shè)置三備份，那么你不管存什么數(shù)據(jù)，任何一臺機(jī)器上可以存數(shù)的你的數(shù)據(jù)的量都是3/4,。但是如果你設(shè)置為四備份，那么任意一個(gè)節(jié)點(diǎn)上都能完整的找到你的數(shù)據(jù)，那么不管你怎么起job，你的map都將是本地化的。但是帶來的壞處就是磁盤開銷過大，一般大型的集群也承受不了5備份以上的數(shù)據(jù)量，所以，基本無意義。

         下面來談?wù)勚仡^戲，那就是mapred中的這些NB的參數(shù)。前置知識我相信大家都已經(jīng)了解了（如果你還不了解mapred的運(yùn)行機(jī)制，看這個(gè)也無意義...），首先數(shù)據(jù)要進(jìn)行map，然后merge，然后reduce進(jìn)程進(jìn)行copy，最后進(jìn)行reduce，其中的merge和copy總稱可以為shuffle。在你起一個(gè)job前，hadoop需要知道你要啟動(dòng)多少個(gè)map，多少個(gè)renduce進(jìn)程，如果你進(jìn)行默認(rèn)參數(shù)啟動(dòng)，那么默認(rèn)只有一個(gè)map線程。（reduce也許也是一個(gè)..）這個(gè)速度是很慢的。設(shè)置map啟動(dòng)個(gè)數(shù)的參數(shù)是mapred.map.tasks，reduce則是mapred.reduce.tasks。這兩個(gè)參數(shù)可以說是對整個(gè)集群的性能起主導(dǎo)型作用的參數(shù)，調(diào)試也基本上圍繞這兩個(gè)參數(shù)。那大家要問就兩個(gè)參數(shù)有什么好來回修改的呢？其實(shí)，這兩個(gè)參數(shù)的設(shè)置配比也直接影響到其他的參數(shù)的設(shè)置。首當(dāng)其沖的就是mapred.tasktracker.map.tasks.maximum
以及 mapred.tasktracker.reduce.tasks.maximum。因?yàn)檫@兩個(gè)參數(shù)設(shè)置了一臺服務(wù)器上最多能同時(shí)運(yùn)行的map和reduce數(shù)?，F(xiàn)在我們來假設(shè)一個(gè)集群有一個(gè)namenode以及8個(gè)datanode，這是一個(gè)很客觀的集群。我們假設(shè)上面的數(shù)據(jù)都是三備份，那么本地?cái)?shù)據(jù)率為3/8。假設(shè)你設(shè)置的map.tasks=128，reuce.tasks=64，那么你的對應(yīng)的兩個(gè)maximum就應(yīng)該分別為16以及8或是更高。因?yàn)檫@樣才能保證你的所有map和reduce的任務(wù)都是分別同時(shí)啟動(dòng)的，如果你的設(shè)置reduce的maximum為7，那么你將得到非常糟糕的結(jié)果，因?yàn)檫@樣8臺機(jī)器同時(shí)可以運(yùn)行的reduce數(shù)量為56了，比你設(shè)置的64差8個(gè)進(jìn)程，這八個(gè)進(jìn)程將會(huì)處于pending狀態(tài)，直到某些正在運(yùn)行的reduce完成它才能補(bǔ)上運(yùn)行，勢必大幅度的增加了運(yùn)行時(shí)間。當(dāng)然，這也不是越大越好，因?yàn)閙ap有很長的一段時(shí)間是和reduce進(jìn)程共存的，共存的時(shí)間取決于你設(shè)置的mapred.reduce.slowstart.completed.maps，如果你設(shè)置為0.6.那么reduce將在map完成60%后進(jìn)入運(yùn)行態(tài)。所以說，如果你設(shè)置的map和reduce參數(shù)都很大，勢必造成map和reduce爭搶資源，造成有些進(jìn)程饑餓，超時(shí)出錯(cuò)，最大的可能就是socket.timeout的出錯(cuò)，網(wǎng)絡(luò)過于繁忙。所以說，這些需要根據(jù)集群的性能，適當(dāng)調(diào)試添加和減少，以達(dá)到最好的效果。那么，map和reduce之間是怎樣的配比比較好呢？apache官網(wǎng)給了我們一些建議，比如設(shè)置reduce與map，他們之間有一個(gè)具體的公式。但是實(shí)際情況總是不能用公式來套用的（否則就不需要系統(tǒng)工程師了...）。一般情況下，當(dāng)你設(shè)置好map和reduce進(jìn)程數(shù)后，你可以通過hadoop的mapred的頁面入口（http://namenode:50030/jobdetai.jps）查看map和reduce進(jìn)度，如果你發(fā)現(xiàn)reduce在33%時(shí)，map正好提早一點(diǎn)點(diǎn)到100%，那么這將是最佳的配比，因?yàn)閞educe是在33%的時(shí)候完成了copy階段，也就是說，map需要再reduce到達(dá)33%之前完成所有的map任務(wù)，準(zhǔn)備好數(shù)據(jù)。千萬不能讓reduce在等待，但是可以讓map先完成。

          OK！這個(gè)重點(diǎn)的搞完之后我們在看看兩個(gè)息息相關(guān)的參數(shù)，io.sort.mb和mapred.child.java.opts。因?yàn)槊恳粋€(gè)map或是reduce進(jìn)程都是一個(gè)task，都會(huì)對應(yīng)啟動(dòng)一個(gè)JVM，所以其實(shí)java.opts也與你啟動(dòng)的map和reduce數(shù)以及別的一些jvm敏感的參數(shù)有關(guān)。既然task運(yùn)行在JVM里面，那么，我這里所要提到的sort.mb 也是分配在JVM中的，這個(gè)值是用來設(shè)置到底我一個(gè)map sort的可用buffer大小是多少，如果map在內(nèi)存中sort的結(jié)果達(dá)到一個(gè)特定的值，就會(huì)被spill進(jìn)入硬盤。具體這個(gè)值是等于mb*io.sort.spill.percent.。按照通常的設(shè)置方式，為了讓jvm發(fā)揮最佳性能，一般設(shè)置JVM的最大可用內(nèi)存量為mb設(shè)置的內(nèi)存量的兩倍。那么mb的內(nèi)存量又根據(jù)什么設(shè)置呢？它主要是與你的一個(gè)map的結(jié)果數(shù)據(jù)量有關(guān)。如果一個(gè)map的結(jié)果數(shù)據(jù)量為600M，那么如果你設(shè)置的mb*io.sort.spill.percent.=200M，那么將進(jìn)行3次spill進(jìn)入硬盤，然后map完成后再將數(shù)據(jù)從硬盤上取出進(jìn)行copy。所以，這個(gè)mb設(shè)置如果是600M的話，那么就不需要進(jìn)行這次硬盤訪問了，節(jié)省了很多時(shí)間。但是最大的問題是內(nèi)存耗費(fèi)很大。如果mb是600M，那么jvm.opts將需要設(shè)置為1G以上，那么，按照上例，你同時(shí)啟動(dòng)16個(gè)map和8個(gè)reduce
的話，那么你的內(nèi)存至少應(yīng)該有24G。所以，這里的設(shè)置也要慎重，因?yàn)楫吘鼓愕姆?wù)器還要跑很多其他的服務(wù)。

         下面就講一下別的一些有影響的參數(shù)，按照一般的設(shè)置方法就可以。首先是針對磁盤和磁盤IO的，mapred.local.dir，這個(gè)參數(shù)最好設(shè)置的跟你的磁盤數(shù)相同，你的磁盤應(yīng)該每一個(gè)磁盤都單獨(dú)設(shè)置為RAID0，然后將所有磁盤配置成多路徑在這個(gè)配置項(xiàng)下，那么HDFS在決定數(shù)據(jù)存儲時(shí)會(huì)順序循環(huán)存儲，保證所有磁盤數(shù)據(jù)量的一致性，也提升了整體磁盤的IO速度。那么針對于網(wǎng)絡(luò)，主要是有reduce和map同時(shí)運(yùn)行時(shí)需要慎重考慮。mapred.reduce.parallel.copies與mapreduce.reduce.shuffle.maxfetchfailures這些參數(shù)都是對網(wǎng)絡(luò)有一些影響的。第一個(gè)是reduce可以進(jìn)行的最大并行拷貝線程數(shù)，這些線程會(huì)同時(shí)從不同的datanode上取map結(jié)果，而第二個(gè)出錯(cuò)重試次數(shù)過多對于很多我們的應(yīng)用都是降低性能的一個(gè)問題。因?yàn)橐话阋粋€(gè)job重試了1次沒有成功那基本以后無論怎么重試都是不會(huì)成功的，重試了不成功不要緊，關(guān)鍵是這個(gè)重試還大量的消耗系統(tǒng)的資源，讓其他的線程可能也因?yàn)閟tarvation
而進(jìn)入重試狀態(tài)，惡性循環(huán)了。如果說你的網(wǎng)絡(luò)確實(shí)很成瓶頸，千兆網(wǎng)都達(dá)不到，那么建議打開mapred.compress.map.output壓縮選項(xiàng)，并配置 mapred.map.output.compression.codec壓縮編碼格式，一般都會(huì)使用snappy，因?yàn)檫@種格式對于壓縮和解壓縮都相對較快。還有就是如果你的集群是異構(gòu)的，有些機(jī)器性能好，有些差，那么建議打開mapred.reduce.tasks.speculative.execution推測性執(zhí)行，有利于優(yōu)化進(jìn)程分配，提升集群性能。

上述內(nèi)容就是hadoop性能調(diào)優(yōu)的重要參數(shù)設(shè)置技巧是怎樣的，你們學(xué)到知識或技能了嗎？如果還想學(xué)到更多技能或者豐富自己的知識儲備，歡迎關(guān)注億速云行業(yè)資訊頻道。