MapReduce：Map-only還是Reduce-only？

在我的問題我有100TB的數據進行處理。該數據集中的每個文件大約爲1MB，並且可以屬於我們定義的超過10,000個不同「組」中的3個。每組文件都需要一起處理，組中可以有幾個文件到幾百個文件。由於我們有成千上萬個這樣的組織，我們認爲這是MapReduce的一個好選擇。MapReduce：Map-only還是Reduce-only？

我看到的東西兩種可能的方法來建立這個工作（也許還有更多），Hadoop等：

僅映射的：我們存檔按組的文件，因此分裂和隨後的映射是在集團層面完成的。由於每個地圖作業都有整個組，所以它可以自己完成處理，並且我們不需要減少作業。但是我發現這個解決方案存在一些問題。首先，由於文件最多可以存在3個組，除了Hadoop的複製因素之外，按組歸檔可能會導致存儲開銷增加三倍。此外，像這樣歸檔數據會使其在其他處理文件的應用程序中有所不同。
減少，僅：據我瞭解，這種模式意味着一個簡單的「身份」映射和數據密集型減速。在此解決方案中，文件將無序存儲在磁盤上，映射程序將收到一組要處理的文件。然後，映射器將文件讀入內存（至少是它的頭文件信息）以確定它屬於哪個組，然後發出（組，文件）對以減少。減速器將負責處理這些組。但是，我擔心我們可能會失去數據局部性的好處，或者通過走這條路線而導致數據流量太大而導致網絡停滯。

這兩種方法都有效嗎？如果是這樣，哪個會更受歡迎？具體來說，我覺得我很瞭解Map-only解決方案的優點和缺點，但不是僅限於Reduce。我不確定「數據本地」如何減少工作，或者如果認爲在減少任務中執行「繁重工作」是不好的做法。

來源

2012-12-02 David A Tarris

爲了性能的原因，我會建議選擇純地圖解決方案而不是僅限於解決方案。
在我的理解中，通過混排機制傳遞數據的計算量非常大。它加載CPU（串行化），磁盤（因爲所有存儲在磁盤上的數據至少一次）和網絡 - 傳遞數據。
在我的估計中，通過非本地HDFS文件加載數據時，洗牌要花費幾倍的代價。
考慮到您的數據大小，並考慮到洗牌期間數據將增加（由於序列化開銷），我還會考慮Map only解決方案以避免磁盤空間不足。

來源

2012-12-02 22:38:17

真棒，這絕對回答了我關於將數據處理卸載到減速器的成本的問題。這聽起來像是，一般來說，你想嘗試在mappers中完成大部分工作，對嗎？確切地說， –

。我總是喜歡在mapper上執行大部分工作，並儘量減少傳遞給reducers的數據。 –

這兩種方法似乎都有效。我想最好的做法是嘗試兩種。然而，在我看來，對於在Hadoop中實現的Map Reduce作業而言，「Reduce-only」版本更爲典型，因爲框架本身將負責對文件進行分組。

但是，效率嚴格依賴於必須執行的計算。什麼是計算？更具體地說：

你可以一起處理一個組的元素的子集嗎？如果是這種情況，您可以使用組合器，大大減少網絡流量。
你能想到不同的組織爲組？

來源

2012-12-02 18:48:05 igon

我們實際上共有超過10,000組，但每個文件最多可以有3個組（即組不是數據分區，有一些重疊）。所以理論上我們可以一次處理所有> 10,000個組。在這種情況下執行的計算是波形數據的互相關，所以我們可以沿着相關矩陣的對角線進一步劃分組。 –

combinator聽起來很有趣，但我對函數式編程不夠熟悉，看看如何應用它來減少網絡流量。你能詳細說明一下嗎？謝謝你的幫助！ –

那麼，在Hadoop中，每個映射器都被分配了一個工作量，它至少等於一個文件或一個文件塊，遵循數據局部性原則。組合器是一個後映射器函數，它在給定節點上的映射器輸出的對上執行。這是一種就地減少操作，通常在減少操作減少數據大小的假設下（一般情況下）減少傳輸的數據量，因爲它是在適當的位置（在內存中）完成的。看看wourdcount組合器在這裏的例子：http://wiki.apache.org/hadoop/HadoopMapReduce – igon

MapReduce：Map-only還是Reduce-only？

回答

相關問題