MapReduce不仅是分而治之的应用程序吗？

将问题划分为较小的问题，直到可以独立解决各个问题，然后将它们组合起来以回答原始问题，这就是所谓的分而治之算法设计技术。[请参阅：CLR算法简介]

最近，这种解决计算问题（特别是在非常大的数据集领域）的方法被称为MapReduce，而不是分而治之。

我的问题如下：MapReduce仅仅是依赖于分而治之方法的专有框架吗？还是在某些方面有使其独特的独特之处？

如果您要问有关MapReduce架构的问题，那么它实际上只是一个分而治之的技术。但是，任何有用的MapReduce架构都将拥有大量其他基础架构，以有效地“划分”，“征服”并最终“减少”问题集。对于大型MapReduce部署（1000个计算节点），这些步骤用于划分工作，计算内容，然后最终收集所有结果，这并非易事。诸如负载平衡，死节点检测，保存临时状态（用于长期运行的问题）之类的事情本身就是难题。

MapReduce的是用于实现分而治之算法的框架在一个非常可扩展的方式，通过在计算机中的一个任意大的簇自动分发单元-的工作的节点和通过重新分布单元的工作自动处理单个节点的故障到另一个节点。

这不是一个非常复杂的概念，而是一个非常有用的基础架构。

MapReduce以一种相当基本的方式与大多数分而治之的系统不同，但是它是如此简单，以至于很多人几乎都错过了它。它的真正天才在于标记中间结果。

在典型的（以前的）分治系统中，您可以按顺序划分工作，并行执行工作包，然后再次串行合并工作的结果。

在MapReduce中，您可以按顺序划分工作量，并行执行工作包，并标记结果以指示哪些结果与其他结果一起使用。然后，对于具有相同标签的所有结果，合并是串行的，但是对于具有不同标签的结果，可以并行执行合并。

在大多数以前的系统中，合并步骤成为除最琐碎的任务之外的所有任务的瓶颈。使用MapReduce，如果任务的性质要求所有合并都必须串行完成，则仍然可以。但是，如果任务允许某种程度的结果并行合并，则MapReduce提供了一种简单的方法来利用这种可能性。大多数其他系统执行以下两项操作之一：要么只是因为某些任务可能需要串行执行所有合并，要么静态定义特定任务的并行合并。MapReduce在合并步骤中为您提供了足够的数据，以自动尽可能地并行调度，同时仍确保（假设您在映射步骤中没有犯错）保持一致性。

还要注意，在MapReduce中，所有步骤都是递归的，因此我可能会有一个初始映射步骤，该步骤将一个大任务分解为可以并行执行的5个较小的任务-但每个步骤（在然后将其映射到其他一些较小的并行任务，依此类推。

这导致映射和缩减方面的树状结构将大型任务快速分解为足够多的片段，以利用许多机器。

MapReduce 不仅是分而治之的技术，尽管在许多示例中看​​起来也是如此。

在映射步骤中，您可以并且经常想要建立一对多关系。因此，您不仅可以简单地分为案例。

在map和reduce之间（取决于实现）有一个排序步骤或一个哈希步骤。此操作的效率对于整体资源需求极为重要。应用程序程序员看不到它的详细信息，但这是框架的核心。

reduce操作是合并的一种。可以将其视为征服者，但实际上往往是“发送数据供以后使用”或“将数据保存在数据存储中”。（请注意，如果您有大量数据集，则确实希望分发所有内容，包括输入和最终结果。因此，分布式键/值存储既可以用作获取输入又可以存储输出的地方。）