解決方案
Google 的爬取資料與日誌資料成長到超過任何單一伺服器所能容納或處理的規模,而自然的解法是採用更大、更昂貴的伺服器,或是撰寫一套沒有人想寫的客製化平行程式。
Dean 與 Ghemawat 的函式庫最初於 2003 年 2 月寫成,讓程式設計師只需提供兩個函式;執行環境會拆分輸入、將其分送出去、依鍵排序,並重試任何失敗的工作。
到了 2004 年底,Google 已在多達數萬台機器上執行數百個不同的 MapReduce 程式,處理從 Google News 與 Zeitgeist 到大型圖形與機器學習等各種工作。
該論文發表於 OSDI 2004,後來也刊登於 Communications of the ACM,成為大資料處理的範本,並被重新實作為開源的 Hadoop,使這個模型成為業界預設做法。
達成了什麼
把運算移到資料所在之處,並將其拆分為 map+reduce
為何奏效
把工作拆分為 map 與 reduce,讓一般工程師無須撰寫執行緒或訊息傳遞,就能進行平行化。
讓資料與其運算留在同一台機器上,可避免透過網路傳送數 TB 的資料。
重試失敗的 map 工作,讓一群不可靠的個人電腦表現得像一台可靠的機器。
可套用之處
當資料大到單一機器無法容納時,把工作分解成可高度平行處理的片段,並讓排程器隱藏硬體故障,而不是購買更大、更昂貴的機器。
後續發展
MapReduce 成為 Google 的標準批次模型,並透過 Hadoop 成為在業界奠定大資料時代的引擎。Google 後來加入了更高階的系統(FlumeJava、Dataflow),因為互動式 SQL 取代了兩步驟的批次模型,而 MapReduce 本身也被取代,但其核心概念——大型工作可以化為兩個函式——成為永久不變的原則。
追溯依據
參考來源
- MapReduce: Simplified Data Processing on Large Clusters (OSDI 2004) USENIX · usenix.org
- Sorting the World: Google Invents New Way to Manage Data Wired · wired.com ·