MapReduceの目新しさは何ですか？

数年前、MapReduceは分散プログラミングの革命として歓迎されました。批評家もいましたが、概して熱狂的な誇大宣伝がありました。それも特許を取得しました！[1]

名前が連想させるmapとreduce関数型プログラミングでは、私が読んだとき（ウィキペディア）

マップステップ：マスターノードは入力を受け取り、それをより小さなサブ問題に分割し、ワーカーノードに配布します。ワーカーノードがこれを順番に繰り返して、マルチレベルツリー構造になります。ワーカーノードは小さな問題を処理し、その応答をマスターノードに返します。

削減ステップ：マスターノードはすべてのサブ問題への回答を収集し、それらを何らかの方法で組み合わせて出力を形成します。これは元々解決しようとしていた問題への回答です。

または[2]

MAPの内部： [...] MAPは入力値を単語に分割します。[...] MAPは、入力の指定された各キー/値ペアを潜在的に多くの中間キー/値ペアに関連付けることを目的としています。

REDUCEの内部： [...] [REDUCE]は、命令集約（たとえば、削減）を実行します。多くの値を取得し、それらを単一の値に削減します。

私は仕方がありません。これは、Mergesortの意味での分割と征服であり、単純で単純です！それで、MapReduceに（概念的な）目新しさはどこかにありますか、それとも特定のシナリオで役立つ古いアイデアの新しい実装ですか？

1. 米国特許7,650,331：「効率的な大規模データ処理のためのシステムおよび方法」（2010）
2. GoogleのMapReduceプログラミングモデル— R.Lämmelによる再訪（2007）

考えずにはいられません。これは、分断と征服であり、単純明快です！

M / Rは分割統治ではありません。前の入力の小さなサブセットにアルゴリズムを繰り返し適用することは含まれません。パイプライン（より単純な関数の構成として指定された関数）は、パイプラインステージがmap操作とreduce操作を交互に実行するパイプラインです。さまざまな段階でさまざまな操作を実行できます。

それで、MapReduceには（概念的な）斬新さがありますか、それとも特定のシナリオで有用な古いアイデアの新しい実装ですか？

MapReduceは、計算理論の新境地を開くことはありません。問題をより単純な操作に分解する新しい方法を示していません。特定のクラスの問題に対して、特定の単純な操作が実用的であることを示しています。

MapReduceの論文の貢献はしました

1. 特定の問題に対して効率的かつフォールトトレラントに分散できる、よく理解されている2つの直交演算子のパイプラインを評価する：大きなコーパスのテキストインデックスを作成する
2. その問題についてmap-reduceのベンチマークを行い、ノード間で転送されるデータ量と、ステージのレイテンシの違いが全体のレイテンシにどのように影響するかを示します
3. 計算中のマシン障害を自動的に補償できるようにシステムをフォールトトレラントにする方法を示します。
4. 特定の有用な実装の選択と最適化を識別する

一部の批評はこれらのクラスに分類されます。

1. 「Map / reduceは計算理論の新境地を開くことはありません。」本当です。元の論文の貢献は、特定の最適化セットを備えたこれらのよく知られた演算子を使用して、実際の問題を1回限りのソリューションよりも簡単かつフォールトトレラントに解決することに成功したことです。
2. 「この分散計算は、マップに簡単に分解して操作を削減することはできません」。結構ですが、多くの人はそうです。
3. 「n個のmap / reduceステージのパイプラインには、結果が生成される前にパイプラインのreduceステップの数に比例したレイテンシが必要です。」おそらく本当です。reduceオペレーターは、完全な出力を生成する前にすべての入力を受け取る必要があります。
4. 「このユースケースでは、Map / reduceは過剰です。」多分。エンジニアが光沢のある新しいハンマーを見つけると、彼らは釘のように見えるものを探しに行く傾向があります。それは、ハンマーが特定のニッチに適したツールではないという意味ではありません。
5. 「Map / reduceは、リレーショナルDBの代替としては不十分です。」本当です。リレーショナルDBがデータセットに合わせて拡張できる場合、それは素晴らしいことです。オプションがあります。

編集（2014年3月）それ以来、MapReduceタイプの計算モデルのアルゴリズムにもっと取り組んできたと言っておくべきです。以下でお話しするDivide-Compress-Conquerテクニックは驚くほど多用途であり、非自明で興味深いと思うアルゴリズムの基礎になる可能性があります。

包括性の観点からはマイクよりはるかに劣るが、計算/アルゴリズム理論の観点からの答えを提供させてください。

$O(n^\epsilon)$$o(\log n)$

$O(1)$

• 問題のインスタンスをパーティション化します（多くの場合、ランダムに）
• 各パーティションでいくつかの計算を並列に実行し、計算結果をコンパクトに表します
• コンパクトに表現されたすべてのサブ問題ソリューションを単一のプロセッサで結合し、そこで計算を終了します

$n$$O(\sqrt{n})$$\sqrt{n}$

さて、これは実際には分割と征服の面白いひねりだと思います。ひねりは、分割段階の後、単一のプロセッサが征服できるようにサブ問題ソリューションを圧縮する必要があることです。ただし、これがこれまでに考え出した唯一の手法のようです。たとえば、疎接続などの疎グラフの問題で失敗します。これをストリーミングモデルと比較すると、FlajoletとMartinの巧妙なサンプリングアルゴリズム、MisraとGriesの決定論的なペアリングアルゴリズム、簡単なスケッチテクニックのパワーなど、新しいアイデアがたくさん生まれました。

プログラミングパラダイムとして、map reduceは非常に成功しています。私のコメントは、map reduceを興味深い計算モデルと考えています。優れた理論モデルは少し奇妙です。それらが現実に近づきすぎると扱いにくくなりますが、より重要なのは、（機械学習から用語を借りるために）定性があまりに具体的なモデルは一般化しない、つまり他のモデルでは成り立たないということです。だからこそ、新しいアルゴリズムを思い付くために私たちに挑戦するのに十分なだけ残しながら、できるだけ多くの詳細を抽象化したいのです。最後に、これらの新しいアイデアは、最終的に現実の世界に戻る方法を見つけることができるはずです。PRAMは興味深いアイデアにつながる非現実的なモデルの1つですが、これらのアイデアは現実世界の並列計算にほとんど適用できないことが判明しました。一方、ストリーミングも非現実的であり、しかし、実際の世界で実際に採用されているアルゴリズムのアイデアに影響を与えました。見るカウントミニスケッチ。スケッチ手法は、実際にはマップリデュースに基づいたシステムでも使用されています。

私はあなたに完全に同意します。概念的な観点から見ると、本当に新しいものは何もありません。Map/ Reduceは元々、Parallel Computingではデータフロープログラミングモデルとして知られていました。ただし、実用的な観点からは、Googleが提案するMap / Reduceおよびその後のオープンソース実装もクラウドコンピューティングを活性化し、非常に単純な並列分解および処理で非常に人気があります。もちろん、複雑なドメインまたは機能の分解を必要とする他のものにはあまり適していません。

あなたはコメントで頭を釘付けにしたと思います。

関数型言語でマップを並列化できるというのは正しくありません。言語は純粋でなければなりません。（Haskellは、漠然と主流の純粋に機能的な唯一の言語だと思います。Lisp、OCaml、Scalaはすべて純粋ではありません。）

エンジニアが最初にプロセッサをパイプライン化したときのタイムシェアリングの前から、純粋なコードの利点について知っていました。それでは、どうして誰も純粋な言語を使用しないのでしょうか？

それは本当に、本当に、本当に難しいです。純粋な言語でのプログラミングは、多くの場合、両手を背中の後ろで縛ったプログラミングのように感じます。

MRが行うことは、純度の制約をいくぶん緩和し、他の部分（シャッフルフェーズなど）のフレームワークを提供して、大部分の問題に対して配布可能なコードを非常に簡単に記述できるようにすることです。

$NC=P$