博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
理解MapReduce哲学
阅读量:6423 次
发布时间:2019-06-23

本文共 1106 字,大约阅读时间需要 3 分钟。

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

转载地址:http://iugra.baihongyu.com/

你可能感兴趣的文章
【转】关于大型网站技术演进的思考(十八)--网站静态化处理—反向代理(10)...
查看>>
绝大部分项目都是跟金融创新、互联网、移动互联网、社区经济、分享经济、互联网金融有关...
查看>>
Java中的4种代码块
查看>>
java语法:字符串数组的赋值
查看>>
Ocelot(七)- 入门
查看>>
生成水杯热气
查看>>
程序员工作心法
查看>>
三个常用的PHP图表类库
查看>>
春暖花开
查看>>
我们今年二十一二岁
查看>>
python中异常处理--raise的使用
查看>>
JavaScript中call,apply,bind方法的总结
查看>>
高中数学与初中数学的接轨点
查看>>
python 安装第三方模块
查看>>
Whitelabel Error Page 专题
查看>>
Spring Data Redis—Pub/Sub(附Web项目源码)
查看>>
RSD和wlwmanifest是什么
查看>>
Linkedin工程师是如何优化他们的Java代码的(转)
查看>>
winfrom 如何保存datagridview中的某一行数据
查看>>
面向领域驱动的应用开发框架Apworks 2.0发布
查看>>