爲什麼提交工作到mapreduce需要這麼多時間在一般？

Question

所以通常對於20個節點集羣提交作業處理3GB（200個分裂）的數據需要約30秒，實際執行約1m。 我想了解的是在作業提交過程中的瓶頸，並瞭解未來報價

每MapReduce的開銷是顯著：開始/結束MapReduce工作耗費時間

有些過程我知道： 1.數據分割 2. jar文件共享

Answer 1

有幾件事情要了解有關HDFS和M/R，有助於理解這種延遲：

1. HDFS將您的文件存儲爲分佈在多個稱爲datanode的計算機上的數據塊
2. M/R在每個數據塊或塊上運行多個名爲mapper的程序。這些映射器的（鍵，值）輸出一起編譯爲reducers的結果。 （想象總結來自多個映射器的各種結果）
3. 每個映射器和簡化器都是在這些分佈式系統上產生的完整的程序。即使讓我們說他們什麼也沒做（無OP圖減少程序），它需要一些時間來產生一個完整的程序。
4. 當要處理的數據量變得非常大時，這些產卵時間變得無足輕重，這就是Hadoop發光時的情況。

如果您要處理1000行內容的文件，那麼您最好使用普通的文件讀取和處理程序。 Hadoop基礎架構在分佈式系統上產生一個進程不會產生任何好處，但只會導致額外的開銷，包括定位包含相關數據塊的datanode，啓動其上的處理程序，跟蹤和收集結果。

現在將其擴展到100個Peta字節的數據，與處理它們所需的時間相比，這些開銷看起來完全不重要。處理器（映射器和縮減器）的並行化將在這裏顯示出優勢。

因此，在分析您的M/R的性能之前，您應該先考慮對您的羣集進行基準測試，以便更好地瞭解這些開銷。

在集羣上執行無操作map-reduce程序需要多長時間？

使用MRBench爲了這個目的：

1. MRbench環小任務的次數少作業運行
2. 檢查是否響應，並在集羣上高效運行。
3. 它在HDFS層的影響是非常有限的

運行此程序，請嘗試以下（檢查最新版本的正確方法：

hadoop jar /usr/lib/hadoop-0.20/hadoop-test.jar mrbench -numRuns 50 

令人驚訝的對我們的開發集羣之一是是22秒。

另一個問題是文件大小。

如果文件大小小於HDFS塊大小，則Map/Reduce程序會產生大量開銷。 Hadoop通常會嘗試爲每個塊產生一個映射器。這意味着如果您有30個5KB文件，那麼即使文件大小很小，Hadoop最終可能每個塊最終產生30個映射器。這是一個真正的浪費，因爲與處理小型文件相比，每個程序開銷都很大。

Answer 2

據我所知，沒有一個瓶頸導致作業運行延遲;如果有的話，它會在很久以前解決。

有很多步驟需要時間，並且有些原因會導致過程緩慢。我會嘗試列出它們並估計我可以在哪裏：

1. 運行hadoop客戶端。它運行的是Java，我認爲可以假設大約1秒的開銷。
2. 將作業放入隊列並讓當前調度程序運行作業。我不確定什麼是開銷，但是，由於進程的異步特性，應該存在一些延遲。
3. 計算拆分。
4. 運行和同步任務。在這裏我們面對TaskTrackes輪詢JobTracker而不是相反的事實。我認爲這是爲了可擴展性而完成的。這意味着當JobTracker想要執行某個任務時，它不會調用任務跟蹤器，而是等待該應用跟蹤器將其ping通以獲得工作。任務跟蹤器無法頻繁ping JobTracker，否則他們會在大型集羣中殺死它。
5. 正在運行的任務。如果沒有JVM重用，大約需要3秒，每個任務的開銷大約爲1秒。
6. 客戶端調查結果的作業跟蹤器（至少我認爲是這樣），並且它也增加了一些延遲來獲取工作完成的信息。

Answer 3

我也有類似的問題，我能說出該解決方案在下面的步驟被打破：

1. 效率當HDFS存儲與固定塊大小太多的小文件，會出現問題HDFS，最好的辦法是刪除所有不必要的文件和包含數據的小文件。再試一次。

2. 嘗試與數據節點和節點名稱：

   • 停止所有服務使用stop-all.sh。
   • 格式名稱節點
   • 重啓機器
   • 開始使用start-all.sh
   • 檢查數據，並將其命名節點的所有服務。

3. 嘗試安裝在兩種情況下起作用的hadoop（hadoop 2.5.2）的較低版本，它在hit和trial中工作。