hadoop作業調優參數整理及原理

文章目錄

• 1.1 MapTask運行內部原理
• 1.2 Map side相關參數調優
• 2.1 ReduceTask運行內部原理
• 2.2 Reduce side相關參數調優

1 Map side tuning參數1.1 MapTask運行內部原理

當map task開始運算，併產生中間資料時，其產生的中間結果並非直接就簡單的寫入磁碟。這中間的過程比較複雜，並且利用到了記憶體buffer來進行已經產生的 部分結果的緩衝，並在記憶體buffer中進行一些預排序來最佳化整個map的效能。如所示，每一個map都會對應存在一個記憶體 buffer（MapOutputBuffer，即的buffer in memory），map會將已經產生的部分結果先寫入到該buffer中，這個buffer預設是100MB大小，但是這個大小是可以根據job提交時的 參數設定來調整的，該參數即為：io.sort.mb。當map的產生資料非常大時，並且把io.sort.mb調
大，那麼map在整個計算過程中spill的次數就勢必會降低，map task對磁碟的操作就會變少，如果map tasks的瓶頸在磁碟上，這樣調整就會大大提高map的計算效能。map做sort和spill的記憶體結構如下如所示：

map在運行過程中，不停的向該buffer中寫入已有的計算結果，但是該buffer並不一定能將全部的map輸出緩衝下來，當map輸出超出一 定閾值（比如100M），那麼map就必須將該buffer中的資料寫入到磁碟中去，這個過程在mapreduce中叫做spill。map並不是要等到 將該buffer全部寫滿時才進行spill，因為如果全部寫滿了再去寫spill，勢必會造成map的計算部分等待buffer釋放空間的情況。所 以，map其實是當buffer被寫滿到一定程度（比如80%）時，就開始進行spill。這個閾值也是由一個job的配置參數來控制，即io.sort.spill.percent，預設為0.80或80%。這個參數同樣也是影響spill頻繁程度，進而影響map
task運行周期對磁碟的讀寫頻率的。但非特殊情況下，通常不需要人為的調整。調整io.sort.mb對使用者來說更加方便。

當map task的計算部分全部完成後，如果map有輸出，就會產生一個或者多個spill檔案，這些檔案就是map的輸出結果。map在正常退出之前，需要將這 些spill合并（merge）成一個，所以map在結束之前還有一個merge的過程。merge的過程中，有一個參數可以調整這個過程的行為，該參數 為：io.sort.factor。該參數預設為10。它表示當merge spill檔案時，最多能有多少並行的stream向merge檔案中寫入。比如如果map產生的資料非常的大，產生的spill檔案大於10，而
io.sort.factor使用的是預設的10，那麼當map計算完成做merge時，就沒有辦法一次將所有的spill檔案merge成一個，而是會 分多次，每次最多10個stream。這也就是說，當map的中間結果非常大，調大io.sort.factor，有利於減少merge次數，進而減少 map對磁碟的讀寫頻率，有可能達到最佳化作業的目的。

當job指定了combiner的時候，我們都知道map介紹後會在map端根據combiner定義的函數將map結果進行合并。運行combiner函數的時機有可能會是merge完成之前，或者之後，這個時機可以由一個參數控制，即min.num.spill.for.combine（default 3），當job中設定了combiner，並且spill數最少有3個的時候，那麼combiner函數就會在merge產生結果檔案之前運行。通過這樣 的方式，就可以在spill非常多需要merge，並且很多資料需要做conbine的時候，減少寫入到磁碟檔案的資料數量，同樣是為了減少對磁碟的讀寫
頻率，有可能達到最佳化作業的目的。

減少中間結果讀寫進出磁碟的方法不止這些，還有就是壓縮。也就是說map的中間，無論是spill的時候，還是最後merge產生的結果檔案，都是 可以壓縮的。壓縮的好處在於，通過壓縮減少寫入讀出磁碟的資料量。對中間結果非常大，磁碟速度成為map執行瓶頸的job，尤其有用。控制map中間結果 是否使用壓縮的參數為：mapred.compress.map.output(true/false)。將這個參數 設定為true時，那麼map在寫中間結果時，就會將資料壓縮後再寫入磁碟，讀結果時也會採用先解壓後讀取資料。這樣做的後果就是：寫入磁碟的中間結果數
據量會變少，但是cpu會消耗一些用來壓縮和解壓。所以這種方式通常適合job中間結果非常大，瓶頸不在cpu，而是在磁碟的讀寫的情況。說的直白一些就 是用cpu換IO。根據觀察，通常大部分的作業cpu都不是瓶頸，除非運算邏輯異常複雜。所以對中間結果採用壓縮通常來說是有收益的。以下是一個 wordcount中間結果採用壓縮和不採用壓縮產生的map中間結果本地磁碟讀寫的資料量對比：

map中間結果不壓縮：

map中間結果壓縮：

可以看出，同樣的job，同樣的資料，在採用壓縮的情況下，map中間結果能縮小將近10倍，如果map的瓶頸在磁碟，那麼job的效能提升將會非常可觀。

當採用map中間結果壓縮的情況下，使用者還可以選擇壓縮時採用哪種壓縮格式進行壓縮，現在hadoop支援的壓縮格式 有：GzipCodec，LzoCodec，BZip2Codec，LzmaCodec等壓縮格式。通常來說，想要達到比較平衡的cpu和磁碟壓縮 比，LzoCodec比較適合。但也要取決於job的具體情況。使用者若想要自行選擇中間結果的壓縮演算法，可以設定配置參數：mapred.map.output.compression.codec=org.apache.hadoop.io.compress.DefaultCodec或者其他使用者自行選擇的壓縮方式。

1.2 Map side相關參數調優

選項	類型	預設值	描述
io.sort.mb	int	100	緩衝map中間結果的buffer大小(in MB)
io.sort.record.percent	float	0.05	io.sort.mb中用來儲存map output記錄邊界的百分比，其他緩衝用來儲存資料
io.sort.spill.percent	float	0.80	map開始做spill操作的閾值
io.sort.factor	int	10	做merge操作時同時操作的stream數上限。
min.num.spill.for.combine	int	3	combiner函數啟動並執行最小spill數
mapred.compress.map.output	boolean	false	map中間結果是否採用壓縮
mapred.map.output.compression.codec	class name	org.apache.hadoop.io. compress.DefaultCodec	map中間結果的壓縮格式

2 Reduce side tuning參數2.1 ReduceTask運行內部原理

reduce的運行是分成三個階段的。分別為copy->sort->reduce。由於job的每一個map都會根據 reduce(n)數將資料分成map 輸出結果分成n個partition，所以map的中間結果中是有可能包含每一個reduce需要處理的部分資料的。所以，為了最佳化reduce的執行時 間，hadoop中是等job的第一個map結束後，所有的reduce就開始嘗試從完成的map中下載該reduce對應的partition部分數 據。這個過程就是通常所說的shuffle，也就是copy過程。

Reduce task在做shuffle時，實際上就是從不同的已經完成的map上去下載屬於自己這個reduce的部分資料，由於map通常有許多個，所以對一個reduce來說，下載也可以是並行的從多個map下載，這個並行度是可以調整的，調整參數為：mapred.reduce.parallel.copies（default 5）。預設情況下，每個只會有5個並行的下載線程在從map下資料，如果一個時間段內job完成的map有100個或者更多，那麼reduce也最多隻能 同時下載5個map的資料，所以這個參數比較適合map很多並且完成的比較快的job的情況下調大，有利於reduce更快的擷取屬於自己部分的資料。

reduce的每一個下載線程在下載某個map資料的時候，有可能因為那個map中間結果所在機器發生錯誤，或者中間結果的檔案丟失，或者網路瞬斷 等等情況，這樣reduce的下載就有可能失敗，所以reduce的下載線程並不會無休止的等待下去，當一定時間後下載仍然失敗，那麼下載線程就會放棄這 次下載，並在隨後嘗試從另外的地方下載（因為這段時間map可能重跑）。所以reduce下載線程的這個最大的下載時間段是可以調整的，調整參數為：mapred.reduce.copy.backoff（default
300秒）。如果叢集環境的網路本身是瓶頸，那麼使用者可以通過調大這個參數來避免reduce下載線程被誤判為失敗的情況。不過在網路環境比較好的情況下，沒有必要調整。通常來說專業的叢集網路不應該有太大問題，所以這個參數需要調整的情況不多。

Reduce將map結果下載到本地時，同樣也是需要進行merge的，所以io.sort.factor的配置選項同樣會影響reduce進行 merge時的行為，該參數的詳細介紹上文已經提到，當發現reduce在shuffle階段iowait非常的高的時候，就有可能通過調大這個參數來加 大一次merge時的並發吞吐，最佳化reduce效率。

Reduce在shuffle階段對下載來的map資料，並不是立刻就寫入磁碟的，而是會先緩衝在記憶體中，然後當使用記憶體達到一定量的時候才刷入磁碟。這個記憶體大小的控制就不像map一樣可以通過io.sort.mb來設定了，而是通過另外一個參數來設定：mapred.job.shuffle.input.buffer.percent（default 0.7），這個參數其實是一個百分比，意思是說，shuffile在reduce記憶體中的資料最多使用記憶體量為：0.7 × maxHeap of
reduce task。也就是說，如果該reduce task的最大heap使用量（通常通過mapred.child.java.opts來設定，比如設定為-Xmx1024m）的一定比例用來快取資料。 預設情況下，reduce會使用其heapsize的70%來在記憶體中快取資料。如果reduce的heap由於業務原因調整的比較大，相應的緩衝大小也 會變大，這也是為什麼reduce用來做緩衝的參數是一個百分比，而不是一個固定的值了。

假設mapred.job.shuffle.input.buffer.percent為0.7，reduce task的max heapsize為1G，那麼用來做下載資料緩衝的記憶體就為大概700MB左右，這700M的記憶體，跟map端一樣，也不是要等到全部寫滿才會往磁碟刷 的，而是當這700M中被使用到了一定的限度（通常是一個百分比），就會開始往磁碟刷。這個限度閾值也是可以通過job參數來設定的，設定參數為：mapred.job.shuffle.merge.percent（default
0.66）。如果下載速度很快，很容易就把記憶體緩衝撐大，那麼調整一下這個參數有可能會對reduce的效能有所協助。

當reduce將所有的map上對應自己partition的資料下載完成後，就會開始真正的reduce計算階段（中間有個sort階段通常時間 非常短，幾秒鐘就完成了，因為整個下載階段就已經是邊下載邊sort，然後邊merge的）。當reduce task真正進入reduce函數的計算階段的時候，有一個參數也是可以調整reduce的計算行為。也就是：mapred.job.reduce.input.buffer.percent（default 0.0）。由於reduce計算時肯定也是需要消耗記憶體的，而在讀取reduce需要的資料時，同樣是需要記憶體作為buffer，這個參數是控制，需要多
少的記憶體百分比來作為reduce讀已經sort好的資料的buffer百分比。預設情況下為0，也就是說，預設情況下，reduce是全部從磁碟開始讀 處理資料。如果這個參數大於0，那麼就會有一定量的資料被緩衝在記憶體並輸送給reduce，當reduce計算邏輯消耗記憶體很小時，可以分一部分記憶體用來 快取資料，反正reduce的記憶體閑著也是閑著。

2.2 Reduce side相關參數調優

選項	類型	預設值	描述
mapred.reduce.parallel.copies	int	5	每個reduce並行下載map結果的最大線程數
mapred.reduce.copy.backoff	int	300	reduce下載線程最大等待時間（in sec）
io.sort.factor	int	10	同上
mapred.job.shuffle.input.buffer.percent	float	0.7	用來緩衝shuffle資料的reduce task heap百分比
mapred.job.shuffle.merge.percent	float	0.66	緩衝的記憶體中多少百分比後開始做merge操作
mapred.job.reduce.input.buffer.percent	float	0.0	sort完成後reduce計算階段用來快取資料的百分比