Reducer節點需要很長時間才能收到其記錄

Question

當我檢查Hadoop GUI時，發現某些reduce任務已達到66.66％，並且他們在那裏呆了很長時間。當我查看櫃檯時，我發現沒有。的輸入記錄顯示爲零。

經過很長時間，他們得到他們的輸入記錄，開始處理它們。 一些顯示0輸入記錄甚至更長的時間，並被任務嘗試失敗報告600毫秒的狀態。

但是，一些減速器立即在其計數器中顯示輸入記錄，並立即開始處理它們。

我不知道，爲什麼在獲取某些reducer的輸入記錄方面有這麼多延遲。這隻發生在這個程序中，而不是其他程序。

在這個mapreduce作業中，我在reduce的reduce方法之前的configure方法中，從分佈式緩存中讀取了很多數據。這是原因嗎？我不確定。

Answer 1

是的我相信從分佈式緩存中讀取是你拖延的原因。但它不會有所作爲，如果你之前或之後reduce()保持configure()，作爲最終configure()方法必須首先調用，如果你看到減速的run()它看起來像如下（新API）：

public void run(Context context) throws IOException, InterruptedException { 

    setup(context); // This is the counterpart of configure() from older API 

    while (context.nextKey()) { 
     reduce(context.getCurrentKey(), context.getValues(), context); 
    } 
    cleanup(context); 
} 

正如你可以看到setup()reduce()叫前，同樣在舊的API這將是除非configure()完成實際reduce任務將無法啓動（這說明你沒有看到記錄計數顯示任何輸入）。

現在作爲百分比：66%，你看，簡化階段實際上下面的子部分：

1. 複製
2. 排序
3. 減少

所以，既然你的第一個完成了兩個步驟，第三個步驟已經開始，但正在等待configure()完成（分佈式緩存被讀取），您的減少百分比爲66％。