第二篇，Google MapReduce架構(gòu)啟示（上）。

很多時候，定義清楚問題比解決問題更難。

?

什么是MapReduce？

它不是一個產(chǎn)品，而是一種解決問題的思路，它有多個工程實現(xiàn)，Google在論文中也給出了它自己的工程架構(gòu)實現(xiàn)。

?

MapReduce這個編程模型解決什么問題？

能夠用分治法解決的問題，例如：

• 網(wǎng)頁抓取

• 日志處理

• 索引倒排

• 查詢請求匯總

• …

畫外音：能夠發(fā)現(xiàn)，現(xiàn)實中有許多基于分治的應用需求。

?

為什么是Google，發(fā)明了這個模型？

Google網(wǎng)頁抓取，分析，倒排的多個應用場景，當時的技術(shù)體系，解決不了Google大數(shù)據(jù)量高并發(fā)量的需求，Google被迫進行技術(shù)創(chuàng)新，思考出了這個模型。

畫外音：誰痛誰想辦法。

?

為什么MapReduce對“能夠用分治法解決的問題”特別有效？

分治法，是將一個大規(guī)模的問題，分解成多個小規(guī)模的問題(分)，多個小規(guī)模問題解決，再統(tǒng)籌小問題的解(合)，就能夠解決大規(guī)模的問題。

畫外音：分治法詳見《分治法與減治法》。

?

Google MapReduce為什么能夠成功？

Google為了方便用戶使用系統(tǒng)，提供給了用戶很少的接口，去解決復雜的問題。
(1)?Map函數(shù)接口：處理一個基于key/value(后簡稱kv)的成對(pair)數(shù)據(jù)集合，同時也輸出基于kv的數(shù)據(jù)集合；
(2)?Reduce函數(shù)接口：用來合并Map輸出的kv數(shù)據(jù)集合；

畫外音：MapReduce系統(tǒng)架構(gòu)，能在大規(guī)模普通PC集群上實現(xiàn)并行處理，和GFS等典型的互聯(lián)網(wǎng)架構(gòu)類似。

用戶僅僅關注少量接口，不用關心并行、容錯、數(shù)據(jù)分布、負載均衡等細節(jié)，又能夠解決很多實際的問題，還有這等好事！

?

能不能舉一個例子，說明下MapReduce的Map函數(shù)與Reduce函數(shù)是如何解決實際問題的？

?

舉例：假設要統(tǒng)計大量文檔中單詞出現(xiàn)的個數(shù)。

?

Map

輸入KV：pair(文檔名稱，文檔內(nèi)容)

輸出KV：pair(單詞，1)

畫外音：一個單詞出現(xiàn)一次，就輸出一個1。

?

Reduce

輸入KV：pair(單詞，1)

輸入KV：pair(單詞，總計數(shù))

?

以下是一段偽代碼，
Map(list<pair($doc_name, $doc_content)>){

? ? foreach(pair in list)

? ? ? ? foreach($word in $doc_content)

? ? ? ? ? ? echo pair($word, 1); // 輸出list<k,v>

}

畫外音：如果有多個Map進程，輸入可以是一個pair，不是一個list。

?

Reduce(list<pair($word, $count)>){// 大量(單詞,1)

? ? map<string,int> result;

? ? foreach(pair in list)

? ? ? ? result[$word] += $count;

?

? ? foreach($keyin result)

? ? ? ? echo pair($key, result[$key]); // 輸出list<k,v>

}

畫外音：即使有多個Reduce進程，輸入也是list<pair>，因為它的輸入是Map的輸出。

?

最早在單機的體系下計算，輸入數(shù)據(jù)量巨大的時候，處理很慢。如何能夠在短時間內(nèi)完成處理，很容易想到的思路是，將這些計算分布在成百上千的主機上，但此時，會遇到各種復雜的問題，例如：

• 并行計算

• 數(shù)據(jù)分發(fā)

• 錯誤處理

• 集群通訊

• …

這些綜合到一起，就成為了一個困難的問題，這也是Google MapReduce工程架構(gòu)要解決的問題，也就是下一章將要分享的問題，敬請期待。

總結(jié)

以上是生活随笔為你收集整理的Google MapReduce到底解决什么问题？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。