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不是分而治之。它不涉及对先前输入的较小子集重复应用算法。它是管道（指定为简单函数组成的函数），其中管道阶段交替映射和减少操作。不同的阶段可以执行不同的操作。

那么，MapReduce中是否存在（概念上的）新颖性，还是只是在某些情况下有用的旧思想的新实现？

MapReduce并没有在计算理论上开辟新天地-它没有显示出将问题分解为更简单操作的新方法。它确实表明特定的简单操作对于特定类型的问题是可行的。

该MapReduce的纸的贡献

1. 评估两个很好理解的正交运算符的流水线，这些运算符可以针对特定问题高效且容错地分布：创建大型语料库的文本索引
2. 对这个问题进行基准测试，减少映射，以显示节点之间传输了多少数据以及阶段中的延迟差异如何影响总体延迟
3. 展示了如何使系统具有容错能力，从而可以自动补偿计算过程中的机器故障
4. 确定特定的有用实施选择和优化

一些批评属于以下类别：

1. “ Map / reduce不会在计算理论上开辟新的天地。” 真正。原始论文的贡献在于，这些经过充分理解的运算符具有一组特定的优化功能，已被成功用于比一次性解决方案更容易，更容错地解决实际问题。
2. “这种分布式计算不容易分解为map＆reduce操作”。足够公平，但是很多都可以。
3. “ n个映射/归约阶段的流水线需要的延迟时间与流水线的缩减步骤数成正比，然后才能产生任何结果。” 可能是真的。reduce运算符确实必须先接收所有输入，然后才能产生完整的输出。
4. “在这个用例中，映射/缩减是过大的。” 也许。当工程师找到闪亮的新锤子时，他们倾向于去寻找任何看起来像钉子的东西。这并不意味着锤子对于某些利基市场来说并不是一种精良的工具。
5. “ Map / reduce不能很好地替代关系数据库。” 真正。如果关系数据库可以扩展到您的数据集，那么对您来说很棒-您可以选择。

编辑（2014年3月）我应该说，自那以后，我在MapReduce类型的计算模型的算法研究上投入了更多精力，我感到自己过于消极了。我在下面谈论的分压合并征服技术令人惊讶地用途广泛，并且可以作为我认为平凡而有趣的算法的基础。

让我提供一个在综合性方面要逊于迈克的答案，但是从计算/算法理论的角度来看。

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

$O(1)$

• 对问题实例进行分区（通常是随机的）
• 在每个分区上并行执行一些计算，并紧凑地表示计算结果
• 将所有紧凑表示的子问题解决方案组合在一个处理器上，并在那里完成计算

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

现在，我认为这实际上是分而治之的一个有趣转折，即转折阶段之后，您需要压缩子问题解决方案，以便单个处理器可以征服。但是，这似乎是到目前为止我们提出的唯一技术。对于稀疏图的问题，例如稀疏连通性，它会失败。将其与流模型进行对比，该模型带来了许多新的想法，例如Flajolet和Martin的独创采样算法，Misra和Gries的确定性配对算法，简单的草图绘制技术的强大功能等。

作为编程范例，map reduce非常成功。我的评论认为map reduce是一种有趣的计算模型。好的理论模型有点奇怪。如果它们过于严格地遵循现实，那么它们将是笨拙的，但是更重要的是，（从机器学习中借用一个术语）针对过于具体的模型证明的定理不会泛化，即在其他模型中不成立。这就是为什么我们要尽可能多地提取细节，同时又要挑战我们提出新颖的算法。最后，这些新想法应该最终能够找到回到现实世界的方式。PRAM是一种不切实际的模型，导致产生有趣的想法，但是事实证明，这些想法很少适用于现实世界的并行计算。另一方面，流媒体也不现实，但它启发了实际应用的算法思想。看到数分钟草图。实际上，草图绘制技术也用于基于map reduce的系统中。

我完全同意你的看法。从概念上讲，没有什么真正的新东西：Map / Reduce最初在并行计算中被称为数据流编程模型。但是，从实际的角度来看，由Google提出的Map / Reduce及其后续的开源实现也推动了Cloud Computing的发展，现在非常流行于非常简单的并行分解和处理。当然，它不适用于需要复杂域或功能分解的任何其他事物。

我认为您的评论已经使您大为震惊。

在任何功能性语言中，映射都不能并行化-语言必须是纯净的。（我相信Haskell是唯一模糊的主流纯功能语言。Lisp，OCaml和Scala都不是纯语言。）

自从甚至在分时共享之前，即工程师首次通过流水线处理处理器以来，我们就已经知道纯代码的好处。那么，为什么没有人使用一种纯粹的语言呢？

真的，真的，真的很难。用纯语言编程通常感觉像是双手背在后面。

MR所做的是在某种程度上放松了纯度约束，并为其他部分（例如混洗阶段）提供了框架，从而使得针对大部分问题编写可分发的代码变得相当容易。

$NC=P$