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查询。