瞭解在Hadoop中減少合併

Question

我在Hadoop中減少文件合併過程的理解方面存在問題，如「Hadoop：權威指南」（Tom White）中所述。引用它：

當所有的地圖輸出已被複制，Reduce任務移動到 排序階段（這應該適當地稱爲合併階段，作爲 排序是在地圖上側進行），它合併地圖 輸出，保持它們的排序順序。這是在一輪中完成的。對於 示例，如果有50個映射輸出並且合併因子爲10（默認爲 ，由io.sort.factor屬性控制，就像在 映射的合併中那樣），則會有五輪。每輪將合併10 文件爲一個，所以最後會有五個中間文件。 最後一輪將這五個文件合併到一個 單個排序文件中，合併通過直接將reduce函數送入最後一個階段：reduce階段來保存到磁盤的行程。這種最終合併可以來自內存和磁盤片段的混合。

本示例顯示，每輪合併的文件數量實際上比 更細微。目標是合併最少 文件以獲得最後一輪的合併因子。因此，如果有40個文件，則合併將不合並四個 回合中的每個文件中的10個文件以獲得4個文件。相反，第一輪只合並4個 文件，隨後的三輪合併完整的10個文件。 4個合併文件和6個（尚未合併的）文件在最後一輪中共創建了10個文件。該過程如圖 6-7所示。請注意，這不會改變輪次的數量;它只是一個 優化，以最大限度地減少寫入磁盤的數據量， ，因爲最後一輪總是直接合併到reduce中。

在第二個例子中（有40個文件），我們真的得到了最後一輪的合併因子。在第5輪中，10個文件沒有寫入磁盤，他們直接減少。但在第一個例子中，實際上只有6輪，而不是5個。在前五輪中每10個文件被合併並寫在磁盤上，然後在第6輪中有5個文件（不是10！），直接減少。爲什麼？如果要堅持「目標是合併最小數量的文件以達到最後一輪的合併因子」，那麼對於這50個文件，我們必須在第一輪中合併5個文件，然後在隨後的4輪中合併10個文件，並且那麼我們會在最後的第6輪中合併10個因子。考慮到我們不能在每一輪中合併超過10個文件（這兩個例子都是由io.sort.factor指定的）。

我在第一個例子中錯誤地理解了50個文件的合併？

Answer 1

這就是我所理解的。如果你仔細閱讀，要記住的重要事項是：

請注意，這不會改變回合數;它只是一個優化，以最大限度地減少寫入磁盤的數據量，因爲最後一輪總是直接合併到reduce中。

有或沒​​有優化，合併輪數保持相同（在第一殼體5和4在第二情況）。

• 第一種情況：50個文件被合併到最終5，然後將它們直接送入「減少」階段（共輪爲5 + 1 = 6）
• 第二種情況：34名的文件被合併到最終4其餘6個直接從內存中讀取並進入「縮減」階段（總輪次爲4 + 1 = 5）

在這兩種情況下，合併輪次數由配置mapreduce.task.io.sort.factor其中設置爲10.

所以合併的輪數ds不會改變（不管優化是否完成）。但是，每輪合併的文件數量可能會發生變化（因爲Hadoop框架可能會引入一些優化來減少合併次數，從而導致數量溢出到磁盤）。

所以，在第一種情況下，未優化，的50個文件的內容（合併到最終5個文件）被灑到磁盤，並且這些文件在「減少」相從磁盤讀取。

在第二種情況下，通過優化，將34個文件的內容（合併到最後4個文件）溢出到磁盤上，並從磁盤讀取這些文件，剩下6個未合併的文件直接從中讀取內存緩衝區，在「減少」階段。

優化的想法是儘量減少合併和溢出。