Spark到底解决了什么根本性的技术问题？

[dongjun111111]

Spark到底解决了什么根本性的技术问题？

1.Spark产生的具体技术环境 在spark出现之前，hadoop的迅速发展，hadoop分布式集群，把编程简化为自动提供 位置感知性调度，容错，以及负载均衡的一种模式，用户就可以在普通的PC机上运行超大集群运算，hadoop有一个非常大的问题：hadoop是基于流处理的，hadoop会从(物理存储)hdfs中加载数据，然后处理之后再返回给物理存储hdfs中，这样不断的读取与写入，占用了大量的IO，后来hadoop出现了非循环的数据流模型，也就是DAG，但是其中任然出现了两个重大的问题： 1.）任然是不断的重复写入和读取磁盘。每次操作都要完成这两步，太浪费了。 2.）交互式数据查询。比如：用户不断查询具体的一个用户的子集。 3.）比如，机器学习，图计算，数据挖掘方面不适用，现在要做大量的重复操作，并且下一次的开始，要依据前面计算的结果，这样对于hadoop来说就要重新的计算，从而浪费大量的资源。 在千亿级大数据环境下,特征挖 掘、实时处理、即席分析、离线计算等场景对计算、存储的性能要求非常高。基于传统的关系型数据库、分布式Hadoop平台实现的数据挖掘平台,无法满足所 有的计算场景的要求。 2.Spark到底解决的根本性技术问题 (和Hadoop 进行对比)

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等多种操作类型，Spark把这些操作称为Transformations。同时还提供Count, collect, reduce, lookup, save等多种actions操作。 Ø 这些多种多样的数据集操作类型，给给开发上层应用的用户提供了方便。各个处理节点之间的通信模型不再像Hadoop那样就是唯一的Data Shuffle一种模式。用户可以命名，物化，控制中间结果的存储、分区等。可以说编程模型比Hadoop更灵活。 Ø 不过由于RDD的特性，Spark不适用那种异步细粒度更新状态的应用，例如web服务的存储或者是增量的web爬虫和索引。就是对于那种增量修改的应用模型不适合。
3. 容错性 Ø 在RDD计算，通过checkpint进行容错，而checkpoint有两种方式，一个是checkpoint data，一个是logging the updates。用户可以控制采用哪种方式来实现容错，默认是logging the updates方式，通过记录跟踪所有生成RDD的转换（transformations），也就是记录每个RDD的lineage（血统）来重新计算生成丢失的分区数据。
4. 可用性 Ø Spark通过提供丰富的Scala, Java，Python API及交互式Shell来提高可用性。 （Spark特性）
5. 内存计算；
6. 提供了支持DAG图的分布式并行计算框架，减少多次计算之间中间结果的IO开销；——harli：对应pipeline。
7. 提供Cache机制来支持多次迭代计算或者数据共享，减少IO开销； ——harli：对应缓存级别。
8. RDD之间维护了血统（lineage）关系，一旦RDD fail掉，能通过父RDD自动重建，保证了容错性； —— harli：根据宽窄依赖，分别有RDD重建和分区重建。
9. 移动计算而非移动数据，RDD Partition可以就近读取分布式文件系统中的数据块到各个节点内存中进行计算；
10. 使用多线程池模型来减少task启动开销； ——harli：扩展，参考董西城老师的博客，比较MR与Spark的进程模型与线程池模型；
11. Shuffle过程中不必要的sort操作； —— harli：Spark 1.2版本后默认采用了sort机制；
12. 采用容错的、高可伸缩性的akka作为通讯框架；

参考

http://m.blog.csdn.net/article/details?id=50555860