Spark与Hadoop计算模型的比较分析

Spark与Hadoop计算模型的比较分析
Spark是一个通用的并行计算框架,由UCBerkeley的AMP实验室开发。
1.Spark的中间数据放到内存中,对于迭代运算效率比较高。
Spark更适合于迭代运算比较多的ML和DM运算。因为在Spark里面,有RDD的概念。
2.Spark比Hadoop更通用。
      Spark提供的数据集操作类型有很多种,不像Hadoop只提供了Map和Reduce两种操作。比如map, filter, flatMap,sample, groupByKey, reduceByKey, union, join, cogroup, mapValues, sort,partionBy等多种操作类型,他们把这些操作称为Transformations。同时还提供Count, collect, reduce, looku p, save等多种actions。
     这些多种多样的数据集操作类型,给上层应用者提供了方便。各个处理节点之间的通信模型不再像Hadoop那样就是唯一的Data Shuffle一种模式。用户可以命名,物化,控制中间结果的分区等。可以说编程模型比Hadoop更灵活。
    不过论文中也提到,Spark不适用那种异步细粒度更新状态的应用,例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型,当然不适合把大量数据拿到内存中了。增量改动完了,也就不用了,不需要迭代了。
3.容错性。
从Spark的论文《Resilient Distributed Datasets: AFault-Tolerant Abstraction for In-Memory Cluster Computing》中没看出容错性做的有多好。倒是提到了分布式数据集计算,做checkpoint的两种方式,一个是checkpoint data,一个是logging the updates。貌似Spark采用了后者。但是文中后来又提到,虽然后者看似节省存储空间。但是由于数据处理模型是类似DAG的操作过程,由于图中的某个节点出错,由于lineage chains的依赖复杂性,可能会引起全部计算节点的重新计算,这样成本也不低。他们后来说,是存数据,还是存更新日志,做checkpoint还是由用户说了算吧。相当于什么都没说,又把这个皮球踢给了用户。所以我看就是由用户根据业务类型,衡量是存储数据IO和磁盘空间的代价和重新计算的代价,选择代价较小的一种策略。
4.关于Spark和Hadoop的融合
不知道Apache基金会的人怎么想的,我看Spark还是应该融入到Hadoop生态系统中。从Hadoop 0.23把MapReduce做成了库,看出Hadoop的目标是要支持包括MapReduce在内的更多的并行计算模型,比如MPI,Spark等。毕竟现在Hadoop的单节点CPU利用率并不高,那么假如这种迭代密集型运算是和现有平台的互补。同时,这对资源调度系统就提出了更高的要求。有关资源调度方面,UC Berkeley貌似也在做一个Mesos的东西,还用了Linux container,统一调度Hadoop和其他应用模型。
 
 

0 个评论

要回复文章请先登录注册