MapReduce
- MapReduce通过简单的Map和Reduce抽象提供了一个编程模型
- 可以在一个由上百台机器组成的集群上并发处理大规模的数据集，并隐藏具体的计算细节
- 各种各样的复杂数据处理都可以分解为Map或Reduce的基本元素
- 复杂的数据处理可以被分解为由多个Job（一个Mapper + 一个Reducer）组成的有向无环图（DAG）
- 然后每个Mapper和Reducer在Hadoop集群上执行，就可以得到结果
缺陷
- 高昂的维护成本
- 时间性能达不到用户的预期
- 抽象层次低，大量的底层逻辑都需要开发者手工完成
- 类似于用汇编语言去编写一个复杂的游戏
- 只提供Map和Reduce两个操作
- 很多实际的数据处理场景并不适合用MapReduce模型来描述
- 实现复杂的操作很有技巧性，同时会让整个工程变得庞大且难以维护
- 如两个数据集的Join操作是很基本且常用的功能
- 但如果使用MapReduce模型，需要对两个数据集进行一次Map和Reduce才能得到结果
- 维护一个多任务协调的状态机成本很高，并且可扩展性很差
- 在Hadoop中，每个Job的计算结果都会存储在HDFS中，所以每一步都会进行硬盘的读取和写入，大大增加了系统延迟
- 因此，MapReduce对于迭代算法的处理性能很差，很耗资源，因为迭代的每一步都要对HDFS进行读写
- 只支持批数据处理，欠缺对流数据处理的支持
Spark的优势
- Spark最基本的数据抽象叫作弹性分布式数据集（Resilient Distributed Dataset，RDD）
- RDD代表一个可以被分区的只读数据集，RDD内部可以有很多分区，每个分区又可以有大量的数据记录
- RDD是Spark最基本的数据结构，Spark定义了很多对RDD的操作
- 对RDD的任何操作都可以像函数式编程中操作内存中的集合一样直观简便，使得实现数据处理的代码非常简短高效
- Spark提供了很多对RDD的操作，如Map、Filter、flatMap、groupByKey、Union等，极大地提升了对各种复杂场景的支持
- 开发者不用再绞尽脑汁地挖掘MapReduce模型的潜力，也不用维护复杂的MapReduce状态机
- 相对于Hadoop的MapReduce会将中间数据存放到硬盘中，Spark会把中间数据缓存在内存中，加快了处理速度
- Spark可以把迭代过程中每一步的计算结果都缓存在内存中，所以非常适用于迭代算法
- Spark第一次启动时需要把数据载入内存，之后的迭代可以直接在内存里利用中间结果进行计算，后期的迭代速度很快
- 在当今机器学习和人工智能大热的环境下，Spark无疑是更好的数据处理引擎
- 在任务级别上，Spark的并行机制是多线程模型，而MapReduce是多进程模型
- 多进程模型便于细粒度地控制每个任务占用的资源，但会消耗较多的启动时间
- Spark同一节点上的任务以多线程的方式运行在同一个JVM进程中
- 更快的启动速度，更高的CPU利用率、更好的内存共享
与Hadoop的关系
- Spark并不是一个完全替代Hadoop的全新工具
- Hadoop生态
- 数据存储层：分布式文件系统HDFS、分布式数据库HBase
- 数据处理层：进行数据处理的MapReduce、负责集群和资源管理的YARN
- 数据访问层：Hive、Pig、Mahout
- 从狭义上来看，Spark只是MapReduce的替代方案
- 大部分应用场景中，Spark还需要依赖HDFS和HBase来存储数据，依赖YARN来管理集群和资源
- Spark不一定依附于Hadoop才能生存，它可以运行在Apache Mesos、Kubernetes等云平台
Spark生态
- Spark作为通用的数据处理平台，有5个主要的扩展库
- 支持结构化数据的Spark SQL
- 处理实时数据的Spark Streaming
- 用于机器学习的MLib
- 用于图计算的GraphX
- 用于统计分析的SparkR
- 扩展库与Spark核心API高度整合，使得Spark平台可以广泛地应用在不同的数据处理场景中