Google工程师将MapReduce定义为一般的数据处理流程。一直以来不能完全理解MapReduce的真义，为什么MapReduce可以“一般”？
最近在研究Spark，抛开Spark核心的内存计算，这里只关心Spark做了什么。在Spark上的所有工作都是围绕数据集进行，包括创建新的数据集、对数据集的转换、对数据集的归约。对于实际应用中的数据处理流程，Spark的这些似乎足够了，足够形成一套一般的数据处理流程。的确，Spark以数据集为操作对象，而可以不论数据集中数据的类型——很朴素的思想！
那么MapReduce呢？MapReduce是否应当被抛弃？在基于Hadoop的实时查询问题上，Hadoop的MapReduce框架也因其效率低下而饱受诟病。对于这个问题我想说的是，这丝毫不是MapReduce自身的问题，也不应全是Hadoop的MapReduce框架的问题，而更主要的是像Hive这类应用不当使用MapReduce的问题。MapReduce无辜地说：“我只对单轮MapReduce处理流程负责，你应当慎重考虑MapReduce处理流程的数据来源和数据去向。”
现在来读读MapReduce的哲学。现实世界的数据是多样的，这些数据在进入信息系统处理之前，我们无法确定哪些数据对于我们的数据查询或分析任务有用或无用，我们只能将所有能够收集到的数据以最原始的形式存储下来。接下来就是MapReduce施展神威的时刻。MapReduce第一步，Map：将数据归类，为每个数据打上一个标明数据属于哪个主题的标签——Key或Key的一部分。经过Map过程，无用数据被过滤，异构数据被统一表示，并且数据按主题分好组。下一步如果要查询或分析特定主题的数据，可以按主题取一组或多组数据。MapReduce第二步，Reduce：将数据归约，在选定的数据上实施查询或分析动作，输出查询或分析结果。Reduce过程可以做很多事情，可以做各类事情，包括递归发起新的MapReduce处理流程。只要还没有产生最终的查询或分析结果，就尽可能不要从Reduce过程返回到用户。看看Hive做了什么，Hive将一个SQL查询命令翻译成多个串行的MapReduce处理流程，难道不能在一个MapReduce处理流程的Reduce过程中完成所有工作吗？Hive的失败在于把MapReduce当成了工具而不是指导思想——世俗化了!
MapReduce与Spark，二者并不排斥，而完全可能很好地结合。我个人的想法是：在MapReduce的Reduce过程中使用Spark完成需要对数据集进行多次迭代才能得到结果的任务，如SQL查询。
