何時在hadoop mapreduce作業上增加/減少交互節點數是個好主意？

Question

我有一個直覺，增加/減少 交互式運行作業的節點數量可以加快地圖重型 作業，但不會幫助減少重工作，其中大部分工作通過減少完成 。

有關於這個的常見問題，但它並沒有真正很好地解釋

http://aws.amazon.com/elasticmapreduce/faqs/#cluster-18

Answer 1

這個問題是由克里斯托弗·史密斯，誰給了我允許張貼在這裏回答。

---

一如既往......「它取決於」。有一件事你幾乎總是可以計算出 ：稍後添加節點不會對你有幫助。

當您創建Hadoop作業時，它將被分解爲任務。這些 任務實際上是「工作的原子」。使用Hadoop可以在作業創建過程中調整＃ 映射器和減速器任務的數量，但一旦創建作業 ，它就是靜態的。任務分配給「插槽」。傳統上， 每個節點都配置爲具有一定數量的插槽用於地圖 任務，並有一定數量的插槽用於減少任務，但您可以調整 。一些較新版本的Hadoop並不要求您將 指定爲用於映射或減少任務的插槽。無論如何，JobTracker會定期將任務分配給插槽。因爲這是動態執行的，所以新的節點聯機可以通過提供更多的時隙來執行任務來加速處理作業 作業。

這爲理解添加新節點的實際情況設置了舞臺。 顯然有一個Amdahl的法律問題，其中有更多的插槽比 掛起的任務完成很少（如果您有推測執行 啓用，它確實有所幫助，因爲Hadoop將安排相同的任務 運行在許多不同的節點上，如果有多餘的資源，節點的任務可以由更快的節點完成 ）。所以，如果你的 沒有用很多地圖或減少任務來定義你的工作，那麼添加更多的 節點不會有太大的幫助。當然，每個任務都會帶來一些開銷，所以你也不想瘋狂。這就是爲什麼我 建議任務大小的指導方針應該是「需要執行 〜2-5分鐘」的原則。

當然，當你動態地添加節點時，他們有一個缺點：他們沒有任何本地數據。顯然，如果你在 EMR管道的開始，沒有一個節點中有數據，所以 並不重要，但是如果你有一個EMR管道由多個作業組成，那麼 包含較早的作業將其結果保存到HDFS，你會得到巨大的性能提升，因爲JobTracker將會傾向於整形和 分配任務，因此節點具有可愛的數據位置（這是整個MapReduce設計的最大性能的一個 核心技巧）。在減速器方面，數據來自其他地圖任務，因此與其他節點相比，動態添加的節點確實沒有什麼不利之處。

所以，原則上，動態添加新節點實際上不太可能幫助處理從HDFS中讀取的IO綁定地圖任務 。

除...

的Hadoop有多種在幕後作弊的優化 性能。一旦它開始傳輸地圖輸出數據到 減速器之前地圖任務完成/減速器啓動。這個 顯然是映射器 產生大量數據的工作的關鍵優化。當Hadoop開始啓動 傳輸時，您可以調整。無論如何，這意味着新加入的節點可能會處於劣勢，因爲現有節點可能已經具有這樣的巨大數據優勢。顯然，映射器 傳輸的輸出越多，缺點就越大。

這就是這一切真正的工作原理。但實際上，很多Hadoop作業都有映射器以CPU密集型方式處理大量數據，但輸出的數據相對較少（或者它們可能向減速器發送大量數據，但減速器仍然是 非常簡單，所以沒有CPU綁定）。通常作業幾乎沒有 （有時甚至是0）reducer任務，所以即使是額外的節點也可以提供幫助，如果你已經有一個可用於每個未完成的reduce任務的reduce slot，新節點不能提供幫助。由於顯而易見的原因，新節點也不成比例地幫助執行CPU綁定工作，因爲傾向於到 而不是減少任務的地圖任務，這就是人們通常看到的勝利的地方 。如果您的映射器是I/O綁定的並且從網絡中提取數據，添加新節點顯然會增加集羣的總帶寬 ，所以它在那裏有幫助，但是如果您的映射任務是讀取HDFS的I/O綁定 ，事情是有更多的初始節點，其中數據 已經遍佈HDFS。由於結構設計不完善，減速器獲得I/O 並不罕見，在這種情況下，添加更多的 節點可以提供很多幫助，因爲它會再次分配帶寬。

有一個警告有太多課程：有一個非常小的集羣， 減速到從 運行的本地節點映射器讀了很多他們的數據，並增加更多的節點轉移更多的數據來作爲 拉過慢得多的網絡。您還可能遇到這樣的情況，其中減少者大部分時間花費的時間僅僅是從發送數據的所有映射器複用數據處理 （儘管這可以很好地調整爲 ）。

如果您問這樣的問題，我強烈建議使用Amazon的KarmaSphere產品來分析您的工作 。它可以讓您更好地瞭解瓶頸的位置，以及 是改善性能的最佳策略。