1、什么是Spark
Apache Spark™是用于大规模数据处理的统一分析引擎。
从右侧最后一条新闻看，Spark也用于AI人工智能
spark是一个实现快速通用的集群计算平台。它是由加州大学伯克利分校AMP实验室 开发的通用内存并行计算框架，用来构建大型的、低延迟的数据分析应用程序。它扩展了广泛使用的MapReduce计算
模型。高效的支撑更多计算模式，包括交互式查询和流处理。spark的一个主要特点是能够在内存中进行计算，及时依赖磁盘进行复杂的运算，Spark依然比MapReduce更加高效。
2、Spark优势在哪里
MapReduce
Google的三篇论文开启了大数据处理的篇章，其中MapReduce被各大公司作为数据处理的主要方案。MapReduce的思想也是从早期的函数式编程语言中借鉴而来，推广到了分布式系统中，接触的东西多了，发现原来很多知识都是相通的。（很多初入IT行业的新人，面对不断出现的新技术往往会比较迷茫，到底该学哪一个呢，其实找到一个自己感兴趣的方向，并努力探索下去，相信慢慢就会一通百通，当然我也是个新银，个人观点，仅供参考^ ^）
传统的数据处理方式通常是将数据导入至专门的数据分析工具中，这样会面临两个问题：1、如果源数据非常大时，往往数据的移动就要花费较长时间。2、传统的数据处理工具往往是单机模型，面对海量数据时，数据处理的时间也是一个很大的问题。
MapReduce是离线批量计算的代表，采用移动计算优于移动数据的理念，计算任务通常直接在HDFS的datanode上运行，这样避免了数据的移动（当然reduce阶段还是需要节点间传输数据），并且采用并行计算的方式，大大减少了数据处理时间。
如图所示，MR模型将数据切分成大小相同的数据块，分别在对应的数据节点上启动map任务，map任务并行读取HDFS上的数据，根据reduce任务的个数将结果写入不同的临时文件中，map任务计算完毕之后，reduce任务从map节点处拉取自己负责处理的数据，并输出最终结果。
wordcount例子：
拿wordcount例子举例，map任务读取自身负责的数据，统计词频后，中间结果发送到对应的reduce节点，reduce节点负责统计最终的词频结果。
MR结合HDFS通过并行计算的方式，很大程度上解决了我们对数据存储、计算的需求，但是大家并不满足于现状，慢慢大家发现了MR依然存在一些问题。
1.API较单一，对复杂的迭代计算并不友好
下面我们来看一个解方程的例子：
如图，上过初中的人一眼都能看出X=1，但是计算机不会因式分解呀，那如何利用计算机思想来求解方程呢？
首先，我们需要将方程转换（图中红色部分），将其看成一个级数，并且保证该级数收敛。
然后，在该级数收敛区间假设一个初始值，这里我们选取了X=1.5，代入方程右端，求出新的X值。
最后，将新的X值不断的进行迭代，当第K+1次和第K次的结果的差值小于我们预先定义好的阈值时，我们可以认为此时的X值已经无限接近于真实值，计算结束。
对计算机解决数学计算感兴趣的同学可以复习一下线性代数和数值分析
这里我们可以看到，计算机求解方程需要多次迭代，如果用MR实现，每一次迭代都要启动一次MR任务，这仅仅还只是一个最简单的例子，当面对数据挖掘这类涉及到比较复杂的组合计算时，采用MR效率就显得比较低下了。
2.MR任务不能有效的利用内存
map任务在处理数据后，会根据reduce的个数，生成对应个数中间文件，这些文件保存在磁盘上，map计算完成后reduce将文件fetch过来进行汇总。也就是说如果采用MR，无论输入源数据有多少，哪怕内存放得下，中间结果还是需要落盘，而我们知道io是计算机中最耗时的操作，这也是造成MR效率较低的一个原因。
从上面的介绍可以看出MR存在两个缺点：
1.无论源数据有多少，shuffle过程的中间数据都需要落盘，效率较低，不能很好的利用内存。
2.MapReduce只提供了map和reduce函数，api不够友好，编写代码时，首先都需要将计算思想转化成MapReduce模型，非常反人类（写过MR的应该非常有感触），而且稍微复杂点的计算需要多次迭代（尤其现在都在提人工智能，深度学习，这些都是比较复杂的逻辑计算），迭代启动任务也有较大的开销。
Spark
Spark对这两点进行了优化，Spark也是一个批量计算框架，我们来看一下Spark的job逻辑图：
Spark的将数据抽象成RDD，RDD：弹性分布式数据集（Resilient Distributed Datasets），这是一种分布式的内存抽象，允许在大型集群上执行基于内存的计算，与此同时还保持了MapReduce等数据流模型的容错特性。RDD可以常驻的内存的属性，大大简化了迭代计算所需的开销，Spark任务可以立马利用上一次计算出来的RDD来进行下次迭代。
Spark不仅仅提供Map和Reduce函数，还提供了额外的api，比如join，图中我们看到数据源data1和data2在中间处进行了join，丰富的api大大简化了编码逻辑，开发更高效（更详细api的可以在Spark官网了解）。
RDD优化：
需要注意的是内存不够用时RDD也可以采用磁盘作为其第二存储介质，而且如果计算中包含shuffle过程，为了保证容灾，shuffle处的RDD也是需要落盘的。
上图中我们可以看到任务被划分为3个stage，这里简单解释一下stage的意义，如果采用MR的运行方式，每个partition都启动一个task，stage1应该启动6个task，因为RDD需要存放在内存（内存不够时放磁盘），这样来看开销还是很大的，而且上下游task的RDD传输也会占用不小的开销。
Spark为了提高效率，采取了如下优化：当下游的RDD和上游的RDD是NarrowDependency时（也就是上游partition和下游partition是1对1，或n对1的关系，不涉及shuffle逻辑，比如map，flatmap等操作），将这些RDD放在一个task里面执行，大大减少了计算时所需的内存开销，也减少了网络传输的数据量，详细可以参考。（很多计算框架都有采用这种优化，比如Flink）
总结一下Spark的优点：
1.它不止提供了map和reduce逻辑，还提供了额外的api，更好的支持了复杂的迭代计算，如：groupby、join等函数。
2.更好的利用内存：内存够用的情况下，数据直接在内存进行处理，减少数据落盘次数，提高计算效率。
这时候问题来了：那既然Spark这么好，是不是Spark可以完全取代MR了？
答：也没有那么绝对，任何东西都有它存在的理由，都有它发光发热的地方，比如当数据量非常大，Spark内存放不下的时候，数据也是需要落盘的。对海数据简单清洗，排序时，Spark的性能并不一定就比MR好，所以还需要看具体的业务。
而且前两年大家都在说Spark将会取代Hadoop，与其说是取代Hadoop，倒不如说Spark有可能取代MapReduce，因为Spark自身是没有存储功能的，数据源往往依赖HDFS存储。
MR和Spark采用批量的方式解决离线计算业务，那想象一下另一些场景：在金融业务中，我们希望能够马上检测到有问题的账单，或者我们希望实时得到系统状态的统计信息，若采用批量框架，很难及时的得到反馈结果，这时就需要实时计算。
3.为什么要学Spark
中间结果输出：基于MapReduce的计算引擎通常会将中间结果输出到磁盘上，进行存储和容错。出于任务管道承接的，考虑，当一些查询翻译到MapReduce任务时，往往会产生多个Stage，而这些串联的Stage又依赖于底层文件系统（如HDFS）来存储每一个Stage的输出结果。
Spark是MapReduce的替代方案，而且兼容HDFS、Hive，可融入Hadoop的生态系统，以弥补MapReduce的不足。
4.Spark的组成
Spark组成(BDAS)：全称伯克利数据分析栈，通过大规模集成算法、机器、人之间展现大数据应用的一个平台。也是处理大数据、云计算、通信的技术解决方案。
它的主要组件有：
SparkCore：将分布式数据抽象为弹性分布式数据集（RDD），实现了应用任务调度、RPC、序列化和压缩，并为运行在其上的上层组件提供API。
SparkSQL：Spark Sql 是Spark来操作结构化数据的程序包，可以让我使用SQL语句的方式来查询数据，Spark支持 多种数据源，包含Hive表，parquest以及JSON等内容。
SparkStreaming： 是Spark提供的实时数据进行流式计算的组件。
MLlib：提供常用机器学习算法的实现库。
GraphX：提供一个分布式图计算框架，能高效进行图计算。
BlinkDB：用于在海量数据上进行交互式SQL的近似查询引擎。
Tachyon：以内存为中心高容错的的分布式文件系统。
