MAP/REDUCE的工作逻辑是这样的：将一个大任务分解成多个小任务，以提供在多个互不相关的节点上执行它的可能。而每个小任务当然必须返回一定的结果以方便后续处理，这个就是中间结果。其中用来得到中间结果的函数就是MAP函数，而用来进行后续处理的函数就是REDUCE函数。MAP函数的功能从总体上说是将输入映射到中间结果。而REDUCE函数的功能则是将中间结果映射到最终的结果。其中因为中间结果是在分布式系统上得到的，所以其在整个系统中的分布也是‘分布式’的，因此可能要求在将它送往计算的下一阶段即REDUCE阶段以前，对它进行重新排序或分组处理，以为REDUCE函数提供有意义的输入。因为由MAP过程的输出构成的自然分组并不一定适合REDUCE对数据的语义要求。

MAP与REDUCE函数则分别对应两次数据集的映射：输入->中间结果；中间结果->输出。

MAP与REDUCE的分阶段并不意味着在时间上的分阶段，只是计算过程上的分阶段。因为在MAP/REDUCE框架中，MAP与REDUCE过程是同时运行的。这意味着它完全是一种流水式作业：MAP节点可以不停地从输入端接受新任务，而REDUCE节点则可以不停地从由MAP节点输出并由系统重新整理过的中间结果进行归并运算并输出任务的最终结果。它是一种流式作业，这意味着MAP不需要停下以为REDUCE让出计算资源。

MAP/REDUCE的目的不是为了解决任务。因为任务可以在一台机器上解决。它的存在是为了同时利用多台机器的计算资源。所以说，说它是一个分布式方案还不如说它是一个并行方案。因为从并行方案的角度来理解它更容易：它的设计目的在于吞吐量。吞吐量是所有并行方案的根本目标。而在多个节点上同时运行MAP与REDUCE，这是一种完全的流水线方案。

也就是说，MR的设计着眼点不是分布式。因为分布式概念还是建立在任务概念的基础上的。分布式是向上看的，其着眼点是任务。所谓分布，是指任务的分布。但并行是向下看的，其着眼点是硬件。所谓并行，是指硬件的并行。MR的设计不是为了在分布式系统上完成某个任务，而是为了在分布式系统上实现并行计算以提供更大的系统吞吐量。 在MR系统中，M与R是同时运行的。这足以证明其是吞吐量导向而非任务导向的方案。

假设没有MR，我会怎么完成一个巨大的任务呢？答案是任何方式。我可以把它放在一台机器上让它慢慢地算，总有一天它要给我一个结果是吧。但是如果加上时间约束，那么我必须考虑如何充分利用现有资源尽快完成任务。但我同样还是可以不选择MR方案，因为我可以简单地比如将任务切分成多个小任务，然后每台机器运行其中的一部分。这样的结果并不比MR方案的速度慢多少。因为工作量几乎是一样的，硬件则完全是一样的，为什么会有区别呢？没有。

那为什么它会存在呢？

存在即合理。MAP/REDUCE存在，是因为有这样（要求先计算，然后再汇总）的任务存在。设想前面所述的小任务做到一半发现做不下去了，因为它已经Reach了它的join点。即它必须等待其它任务完成才能继续所有的后续处理。这样的话其它的小任务当然也就存在各自的JOIN点。那么当大家都到达了JOIN点以后，系统将开始汇总操作。

因此，MAP/REDUCE的主要目的是用来处理这种具备“先计算再汇总”特征的任务。但是由于它的高度并行特征，如果某些任务虽然不具备这种特征但可以被转化为这种任务，那么使用它仍然不失为一个良好的决策。只是在现实开发工作中，恐怕大多数任务都不具备这种特征，所以它其实对于大多数任务并不真正具有其适用性。它只适用于两阶段任务。对于一阶段任务，使用它则无异于杀鸡用宰牛刀，画蛇添足 了。

结论：一阶段任务应该选用更简单的并行方案。

 另外，在网上看到一篇MAP/REDUCE是一种倒退的大数据集处理模型。作者的论据的确很有说服力，但即使这是个成功的命题，它并不影响人们在适当的时候使用MAP/REDUCE来进行相关的任务处理。对任何事物的盲目信仰都是不对的。都是一种迷信。人们正是从对传统数据库管理系统的迷信中醒悟过来而投入新技术如NOSQL，MAP/REDUCE这样的技术的怀抱中的。对关系库的迷信不对，对MAP/REDUCE的迷信当然也不对。但是试想，如果关系库没有任何问题，人们为什么要选用新方案呢？从数据库的逃离难道不正说明了人们的不满吗？

我的观点是：我谁都信，又谁都不信。因为名字是愚蠢的。指称是愚蠢的。只有性质是可靠的。我是一个工具论兼实在论者。