Hadoop：是否可以在map函數的內存結構中進行聚合？

Question

我目前正在閱讀一篇論文，並且我已經到了一個地步，作家們說，他們在每個地圖任務的內存中都有一些數組，當地圖任務結束時，他們會輸出該數組。

這是我指的是紙：http://research.google.com/pubs/pub36296.html

這個有點看起來有點非MapReduce的事情，但我想實現這個項目，我已經來到了一個點是這樣的解決方案我已經嘗試了很多方法來使用通用映射減少哲學，它處理每一行並輸出一個鍵 - 值對，但這樣我就可以爲每一行輸入數千個上下文寫入，並且需要很長時間才能寫入他們。所以我的地圖任務是一個瓶頸。這些上下文寫入花費了很多。

如果我這樣做，我會設法大幅減少鍵值對的數量。所以我需要找到一種方法來在每個地圖任務的內存結構中使用。 我可以在設置功能中將這些結構定義爲靜態，但我可以找到一種方法來告知地圖任務何時結束，以便我可以輸出該結構。我知道這聽起來有點奇怪，但它是有效工作的唯一方法。

這是他們在紙

在啓動時說的話，每一個映射器將裝入被 考慮每個有序屬性分割點的。對於每個節點n∈N 和屬性X，映射器維護鍵值對的表Tn，X.

處理所有輸入數據後，映射器OUT-形式的n 放鍵，X和值v，TN，X [V]

這裏是肖恩的回答後，一些編輯：

我在工作中使用組合器。問題在於，我的map函數中的這些context.write（Text，Text）命令非常耗時。我的輸入是csv文件或arff文件。每一行都有一個例子。我的示例可能具有多達數千個屬性。我輸出每個屬性，鍵值對的形式爲<（n，X，u），Y>，其中是節點的名稱（我正在構建決策樹），X是屬性的名稱， u是屬性的值，Y是文本格式的一些統計數據。正如你所看到的，如果我有100,000個屬性，我將不得不爲每個例子都有100,000個context.write（文本，文本）命令。在沒有這些命令的情況下運行我的地圖任務，它像風一樣運行。如果我添加context.write命令，則需要永久。即使是200,000個屬性訓練集。這看起來好像我在寫文件而不是在內存中。所以我真的需要減少這些寫入。將它們聚集在內存中（在map函數中而不在組合器中）是必要的。

Answer 1

添加一個不同的答案，因爲我現在看到了問題的重點。

要知道地圖任務何時結束，那麼您可以覆蓋close()。我不知道這是你想要的。如果您有50個映射器，則每個輸入的1/50都不知道或不能保證。對於你的用例來說，這可以嗎 - 你只需要每個工作人員在內存中聚合統計數據以查看和輸出內容。

然後你的程序很好，但可能不會讓你的內存數據結構static - 沒有人說兩個Mapper s不會在一個JVM類加載器中運行。

此模式的更常見版本在Reducer中播放，您需要收集一些已知鍵的子集信息，然後才能生成一條記錄。您可以使用分區程序和鍵排序的事實，以知道您正在看到一個工作程序中的所有子集，並且可以知道何時完成是因爲出現了新的不同子集。然後在處理子集時收集內存中的數據非常容易，輸出結果並在新子集進入時將結果輸出。

由於瓶頸發生在Reducer之前，因此我不確定這是否適用。

Answer 2

不知道更多關於你輸出內容的細節，我不能確定這是否會有所幫助，但是，這聽起來像是一個組合器設計的幫助。它就像一個小型的減速器（實際上，一個組合器的實現只是Reducer的另一個實現）附加到Mapper的輸出。其目的是收集內存中的映射輸出記錄，並嘗試在寫入磁盤之前將它們聚合，然後由Reducer收集。

經典的例子是計數值。您可以從您的地圖輸出「key，1」，然後在減速器中將1加起來，但是，如果在「key，1000」就足夠時出現1000次關鍵字，則這需要從映射器輸出1000次「key，1」 。一個組合器這樣做。當然，它只適用於所討論的操作是聯想/交換的，並且可以重複運行而沒有副作用 - 加法就是一個很好的例子。

另一個答案：在Mahout中，我們實現了許多既奇怪又複雜，如果以簡單的方式完成又很慢的東西。像Mapper這樣的在內存中收集數據的技巧是次要的，有時是必需的罪過，所以沒有什麼問題。這確實意味着您確實需要了解Hadoop所保證的語義，進行測試，並且仔細考慮內存不足。