Googleは大規模データ処理を2つの関数によるmap-and-reduceの作業に変えた。

Googleのクロールデータとログデータは、単一のサーバーでは保持も処理もできない規模にまで成長しており、当然の答えはより大きく高価なサーバーか、誰も書きたがらない特注の並列プログラムであった。

DeanとGhemawatによるライブラリは2003年2月に最初に書かれ、プログラマは2つの関数を提供するだけでよかった。ランタイムが入力を分割し、送り出し、キーでソートし、失敗したものはすべて再試行した。

2004年後半までに、GoogleはGoogle NewsやZeitgeistから大規模グラフや機械学習のジョブに至るまで、最大数万台のマシン上で数百もの異なるMapReduceプログラムを実行していた。

OSDI 2004で発表され、後にCommunications of the ACMにも掲載されたこの論文は、ビッグデータ処理のテンプレートとなり、オープンソースのHadoopとして再実装され、このモデルを業界のデフォルトにした。

計算をデータの場所へ移動し、map+reduceに分割する

ジョブをmapとreduceに分割することで、普通のエンジニアがスレッドやメッセージパッシングを書くことなく並列化できる。

データをその計算と同じマシン上に保持することで、テラバイト級のデータをネットワーク越しに送ることを避けられる。

失敗したmapタスクを再試行することで、信頼性の低いPCの群れが1台の信頼できるマシンのように振る舞う。

データが1台のマシンには大きすぎる場合、より大きく高価なマシンを買うのではなく、ジョブを embarrassingly parallel な部分に分解し、スケジューラにハードウェア障害を隠させる。

MapReduceはGoogleの標準的なバッチモデルとなり、Hadoopを通じて、業界全体にビッグデータ時代を確立したエンジンとなった。Googleは後に、対話型SQLが2段階のバッチモデルに取って代わるにつれて、より高水準のシステム（FlumeJava、Dataflow）を追加し、MapReduce自体は取って代わられたが、大きなジョブを2つの関数にできるというその中核的アイデアは永続的なものとなった。