spark 究竟比 mapreduce 好在哪里,为什么备受推崇, 有些人宣称spark 是大数据的未来, spark 宣布了 Hadoop 的死刑, 这种话到底能不能讲, 会不会被打脸?
首先,理清一个基本概念, hadoop = hdfs + yarn + mapreduce
hdfs 现在是大数据分布式存储的标配, 如果公司没有牛x到可以自主开发一套分布式存储, 一般开源都是选择 hdfs 作为大数据分布式存储
yarn 是一个资源管理框架, 是负责把底层物理资源抽象为容器,然后管理调度这些容器, 交付给应用者。 spark on yarn 也是很常见的一种使用场景。
mapreduce 通过简单的Mapper和Reducer的抽象提供一个编程模型,就是对任务进行划分, 然后把划分后的任务分发到多个机器上去执行(map 过程), 最后对多台机器执行的结果进行汇总(reduce 过程), 全部灵感都来自于google 的这篇论文, 是这篇论文的一个开源实现
https://static.googleusercontent.com/media/research.google.com/zh-CN//archive/mapreduce-osdi04.pdf
这个论文可经典了, 建议没事读一读。
好了, spark 宣布了 Hadoop 的死刑, 大家现在再来看这句话, 是不是在胡扯,
spark 只能来和 mapreduce 进行比较, 因为都是计算引擎, 才有比较的意义。
我认为 spark 是比mapreduce 要牛x的, 因为我是一路从 mapreduce 转到 spark 的,一路踩着坑过来的,对两种计算框架的使用都有比较深刻的体会吧。
spark 相对mapreduce 的优势,个人觉得有这几点吧
1.写 mapreduce 应用都是使用 java, 总感觉抽象层次比较低, 要写很多代码才能完成业务逻辑,好多都是费代码, spark 基于RDD的抽象, 提供了一系列简洁易用, 抽象层次比较高的 api,而且表达力比较强,效率快了不止一点半点,谁用谁知道,用的都说好
2.mapreduce 一个job 只有简单的 map reduce 两步, 如果业务逻辑比较复杂, 那就得搞很多有依赖关系的job, 先跑哪个后跑哪个, 也要开发者自己来管理解决, 这个很恶心, spark 则通过DAG 的方式对多阶段应用支持的特别好,可以更自然表达出计算逻辑。如果多个map操作的RDD的分区不变,是可以放在同一个Task中进行,
3.mapreduce 中间结果都是使用 hdfs 存储,这意味着大量的磁盘io,磁盘io 读写是非常低效的,而 spark 中间结果放在内存中,内存放不下了会写入本地磁盘,而不是HDFS。 spark 调优后,一般中间结果都是 cache 到内存中的,这种机制无疑可以简单有效地解决MapReduce在迭代计算时反复读取写出磁盘的问题 , spark 刚一出道的时候擅长的就是处理复杂迭代的交互任务,可以进行无限次的迭代操作, 事实上当前机器学习的大多数算法都是迭代算法,因此spark 对于解决这一问题具有很大的应用价值。