MapReduce中間結果為什麼只能存到磁碟？

03-31

為什麼MapReduce不能像spark那樣中間結果存到內存？

1。mapreduce設計的時候主要還是做單次任務，輸入進來，map，reduce，然後就完了。所以reduce結果自然是在硬碟的。

2。map結果存在硬碟，那是為了不佔內存。因為mr是為了處理大量數據，內存很可能放不下，再者反正網路也沒比硬碟快（設計時假設的是千兆網），那寫硬碟頂多慢一倍。

3。spark是為多級處理設計的。假設就是數據要處理多遍，那每次處理之間放內存就比較合理了。不過基於上一條的原因，shuffle同樣是放硬碟的。（然而現在多數公司都是萬兆網了。。。）

不知道你問的是多個MapReduce之間還是Map和Reduce之間。

1.多個MapReduce之間

這種結果存到HDFS是Hadoop MapReduce本來就這樣設計的，一次只執行一個簡單任務。這樣雖然沒有spark高效，可有一個額外的好處是中間文件可以用來debug。如何你有多個map中間沒有reduce，可以自己用管道串起來。

2.Map和Reduce之間

簡單的說是因為內存不夠用才存檔。複雜的說是因為Hadoop MapReduce是sort-base的，而spark是hash-base的。

做sort需要有全局數據，內存放不下就要存檔。而hash只需關注一條數據，可以流式處理：map完一條就發一條給reduce（實際上可能速度不匹配還是需要磁碟來緩衝），reduce結點接收一條就reduce一次。

sort-base方案在map結點和reduce結點都要存檔數據，而hash-base的只需在點內存緊張時才溢出一部分到磁碟。

以上純屬個人愚見。Hadoop MapReduce雖然慢，可是耐操性好啊，不像spark三天兩頭的出問題。

如果覺得spark的API比Hadoop更好用，那是因為你沒找對工具，我把Hadoop MapReduce封裝的像spark介面一模一樣的：https://github.com/chunquedong/mrspark。

瀉藥。

Spark的shuffle中間結果也是落磁碟的，只不過（不涉及shuffle的）運算元間做了串聯，相當於做了一個流水線優化。

最近在讀DDIA，第十章 Batch Processing剛好提到了這個問題。書上的觀點是：MR將中間結果寫磁碟，一個原因是為了容錯（也就是其他答主提到的耐操），另一個則是考慮數據太大可能內存放不下（好像也有答主提到了）。

但為什麼要這樣考慮呢？這還要從Google當年設計MR的大環境說起。當年，Google的數據中心是混合使用的，線上服務和離線任務（MR）在相同的機器上，而資源是搶佔式的。為了優先保障線上服務，MR就被賦予了低優先順序（搶佔CPU和內存資源），因此MR有較大概率因搶不到資源而任務終止。在當時，每個運行一個小時的任務有5%的失敗概率，這比機器硬體出現故障的概率要高得多。

書上還提到，現在的集群管理調度工具中，搶佔式的資源分配使用並不廣泛，在機器性能可以的條件下，任務不會很容易就掛掉，所以MR只寫磁碟的設計也就make less sense了。

據我所知，現在公司里跑MR任務的集群機器會比spark集群機器差一些。差一點就差一點吧，反正MR這樣設計能容忍。

說的好像Spark就不是MapReduce似的。

可以放內存啊，不過mapreduce是為大規模集群設計的，其中數據就必須保證安全，溢寫到磁碟算一種fault tolerance了，避免重複計算。所以呢，mapreduce的設計可以支持到幾千上萬台廉價機器的並行計算。spark么，到這個級別估計夠嗆了