Hadoop 效能調優 重要參數設定技巧

這一兩個月在做mapreduce的效能調優，有些心得，還是要記下來的，以郷後人~

這裡主要涉及的參數包括：

1. HDFS：
2. dfs.block.size
3. Mapredure：
4. io.sort.mb
5. io.sort.spill.percent
6. mapred.local.dir
7. mapred.map.tasks & mapred.tasktracker.map.tasks.maximum
8. mapred.reduce.tasks & mapred.tasktracker.reduce.tasks.maximum
9. mapred.reduce.max.attempts
10. mapred.reduce.parallel.copies
11. mapreduce.reduce.shuffle.maxfetchfailures
12. mapred.child.java.opts
13. mapred.reduce.tasks.speculative.execution
14. mapred.compress.map.output & mapred.map.output.compression.codec
15. mapred.reduce.slowstart.completed.maps

這裡一共列出了十六個參數，這十六個參數基本上能滿足一般情況下，不針對特定情境應用的效能調優了，下面我將以Terasort為例，詳述這些參數的作用已經如何配比調優。

Hadoop的HDFS作為mapreduce的基礎Distributed File System，對mapred的運行效果也有直接的影響。首先影響到我們的效能的參數就是block.size，在網路環境很好的叢集中，建議將這個參數提升，大小可以到128或256或更大（預設64M）。

但是HDFS的影響也僅限於此，而且其配置項多數都是目錄配置以及容錯，還有備份數等等，這些對於我們效能調優意義不大。可以舉一個例子，那就是備份數。這個參數主要是用於設定block在叢集中的備份數，這些備份將按照某種規則分配在叢集的各個機器上，預設是3備份。但是由於mapred的map需要輸入資料，一般預設情況是一個map一個block，那麼當你在叢集起job，一個job拉起來N多的map在一個機器執行時，如果這個map的輸入資料是本地的，那麼顯然map的執行將會更快，因為不需要等待網路傳輸。拿四個節點為例，如果你設定三備份，那麼你不管存什麼資料，任何一台機器上可以存數的你的資料的量都是3/4,。但是如果你設定為四備份，那麼任意一個節點上都能完整的找到你的資料，那麼不管你怎麼起job，你的map都將是本地化的。但是帶來的壞處就是磁碟開銷過大，一般大型的叢集也承受不了5備份以上的資料量，所以，基本無意義。

下面來談談重頭戲，那就是mapred中的這些NB的參數。前置知識我相信大家都已經瞭解了（如果你還不瞭解mapred的運行機制，看這個也無意義...），首先資料要進行map，然後merge，然後reduce進程進行copy，最後進行reduce，其中的merge和copy總稱可以為shuffle。在你起一個job前，hadoop需要知道你要啟動多少個map，多少個renduce進程，如果你進行預設參數啟動，那麼預設只有一個map線程。（reduce也許也是一個..）這個速度是很慢的。設定map啟動個數的參數是mapred.map.tasks，reduce則是mapred.reduce.tasks。這兩個參數可以說是對整個叢集的效能起主導型作用的參數，調試也基本上圍繞這兩個參數。那大家要問就兩個參數有什麼好來回修改的呢？其實，這兩個參數的設定配比也直接影響到其他的參數的設定。首當其衝的就是mapred.tasktracker.map.tasks.maximum
以及 mapred.tasktracker.reduce.tasks.maximum。因為這兩個參數設定了一台伺服器上最多能同時啟動並執行map和reduce數。現在我們來假設一個叢集有一個namenode以及8個datanode，這是一個很客觀的叢集。我們假設上面的資料都是三備份，那麼本機資料率為3/8。假設你設定的map.tasks=128，reuce.tasks=64，那麼你的對應的兩個maximum就應該分別為16以及8或是更高。因為這樣才能保證你的所有map和reduce的任務都是分別同時啟動的，如果你的設定reduce的maximum為7，那麼你將得到非常糟糕的結果，因為這樣8台機器同時可以啟動並執行reduce數量為56了，比你設定的64差8個進程，這八個進程將會處於pending狀態，直到某些正在啟動並執行reduce完成它才能補上運行，勢必大幅度的增加了已耗用時間。當然，這也不是越大越好，因為map有很長的一段時間是和reduce進程共存的，共存的時間取決於你設定的mapred.reduce.slowstart.completed.maps，如果你設定為0.6.那麼reduce將在map完成60%後進入運行態。所以說，如果你設定的map和reduce參數都很大，勢必造成map和reduce爭搶資源，造成有些進程饑餓，逾時出錯，最大的可能就是socket.timeout的出錯，網路過於繁忙。所以說，這些需要根據叢集的效能，適當調試添加和減少，以達到最好的效果。那麼，map和reduce之間是怎樣的配比比較好呢？apache官網給了我們一些建議，比如設定reduce與map，他們之間有一個具體的公式。但是實際情況總是不能用公式來套用的（否則就不需要系統工程師了...）。一般情況下，當你設定好map和reduce進程數後，你可以通過hadoop的mapred的頁面入口（http://namenode:50030/jobdetai.jps）查看map和reduce進度，如果你發現reduce在33%時，map正好提早一點點到100%，那麼這將是最佳的配比，因為reduce是在33%的時候完成了copy階段，也就是說，map需要再reduce到達33%之前完成所有的map任務，準備好資料。千萬不能讓reduce在等待，但是可以讓map先完成。

OK！這個重點的搞完之後我們在看看兩個息息相關的參數，io.sort.mb和mapred.child.java.opts。因為每一個map或是reduce進程都是一個task，都會對應啟動一個JVM，所以其實java.opts也與你啟動的map和reduce數以及別的一些jvm敏感的參數有關。既然task運行在JVM裡面，那麼，我這裡所要提到的sort.mb 也是分配在JVM中的，這個值是用來設定到底我一個map sort的可用buffer大小是多少，如果map在記憶體中sort的結果達到一個特定的值，就會被spill進入硬碟。具體這個值是等於mb*io.sort.spill.percent.。按照通常的設定方式，為了讓jvm發揮最佳效能，一般設定JVM的最大可用記憶體量為mb設定的記憶體量的兩倍。那麼mb的記憶體量又根據什麼設定呢？它主要是與你的一個map的結果資料量有關。如果一個map的結果資料量為600M，那麼如果你設定的mb*io.sort.spill.percent.=200M，那麼將進行3次spill進入硬碟，然後map完成後再將資料從硬碟上取出進行copy。所以，這個mb設定如果是600M的話，那麼就不需要進行這次硬碟訪問了，節省了很多時間。但是最大的問題是記憶體耗費很大。如果mb是600M，那麼jvm.opts將需要設定為1G以上，那麼，按照上例，你同時啟動16個map和8個reduce
的話，那麼你的記憶體至少應該有24G。所以，這裡的設定也要謹慎，因為畢竟你的伺服器還要跑很多其他的服務。

下面就講一下別的一些有影響的參數，按照一般的設定方法就可以。首先是針對磁碟和磁碟IO的，mapred.local.dir，這個參數最好設定的跟你的磁碟數相同，你的磁碟應該每一個磁碟都單獨設定為RAID0，然後將所有磁碟配置成多重路徑在這個配置項下，那麼HDFS在決定資料存放區時會順序迴圈儲存，保證所有磁碟資料量的一致性，也提升了整體磁碟的IO速度。那麼針對於網路，主要是有reduce和map同時運行時需要謹慎考慮。mapred.reduce.parallel.copies與mapreduce.reduce.shuffle.maxfetchfailures這些參數都是對網路有一些影響的。第一個是reduce可以進行的最大並行拷貝線程數，這些線程會同時從不同的datanode上取map結果，而第二個出錯重試次數過多對於很多我們的應用都是降低效能的一個問題。因為一般一個job重試了1次沒有成功那基本以後無論怎麼重試都是不會成功的，重試了不成功不要緊，關鍵是這個重試還大量的消耗系統的資源，讓其他的線程可能也因為starvation
而進入重試狀態，惡性迴圈了。如果說你的網路確實很成瓶頸，千兆網都達不到，那麼建議開啟mapred.compress.map.output壓縮選項，並配置 mapred.map.output.compression.codec壓縮編碼格式，一般都會使用snappy，因為這種格式對於壓縮和解壓縮都相對較快。還有就是如果你的叢集是異構的，有些機器效能好，有些差，那麼建議開啟mapred.reduce.tasks.speculative.execution推測性執行，有利於最佳化進程分配，提升叢集效能。

如有不詳或不對的地方，還請指正。