1、基于内存
（1）mapreduce任务后期再计算的时候，每一个job的输出结果会落地到磁盘，后续有其他的job需要依赖于前面job的输出结果，这个时候就需要进行大量的磁盘io操作。性能就比较低。
（2）spark任务后期再计算的时候，job的输出结果可以保存在内存中，后续有其他的job需要依赖于前面job的输出结果，这个时候就直接从内存中获取得到，避免了磁盘io操作，性能比较高
（3）对于spark程序和mapreduce程序都会产生shuffle阶段，在shuffle阶段中它们产生的数据都会落地到磁盘。
• 2、进程与线程
  （1）mapreduce任务以进程的方式运行在yarn集群中，比如程序中有100个MapTask，一个task就需要一个进程，这些task要运行就需要开启100个进程。
  （2）spark任务以线程的方式运行在进程中，比如程序中有100个MapTask，后期一个task就对应一个线程，这里就不在是进程，这些task需要运行，这里可以极端一点：
  只需要开启1个进程，在这个进程中启动100个线程就可以了。
  （3）进程中可以启动很多个线程，而开启一个进程与开启一个线程需要的时间和调度代价是不一样。 开启一个进程需要的时间远远大于开启一个线程。

2.2 易用性

• 可以快速去编写spark程序通过 java/scala/python/R/SQL等不同语言

2.3 通用性

• spark框架不在是一个简单的框架，可以把spark理解成一个==生态系统==，它内部是包含了很多模块，基于不同的应用场景可以选择对应的模块去使用

  sparksql 通过sql去开发spark程序做一些离线分析

主要是用来解决公司有实时计算的这种场景

它封装了一些机器学习的算法库

图计算

2.4 兼容性

• spark程序就是一个计算逻辑程序，这个任务要运行就需要计算资源（内存、cpu、磁盘），哪里可以给当前这个任务提供计算资源，就可以把spark程序提交到哪里去运行 ==standAlone == 它是spark自带的独立运行模式，整个任务的资源分配由spark集群的老大Master负责

可以把spark程序提交到yarn中运行，整个任务的资源分配由yarn中的老大ResourceManager负责

它也是apache开源的一个类似于yarn的资源调度平台

3.Spark集群架构

• ==Driver == 它会执行客户端写好的main方法，它会构建一个名叫SparkContext对象 该对象是所有spark程序的执行入口

就是一个spark的应用程序，它是包含了客户端的代码和任务运行的资源信息
• 一个application对应一个driver

它是给程序提供计算资源的外部服务 standAlone 它是spark自带的集群模式，整个任务的资源分配由spark集群的老大Master负责

可以把spark程序提交到yarn中运行，整个任务的资源分配由yarn中的老大ResourceManager负责

它也是apache开源的一个类似于yarn的资源调度平台。

它是整个spark集群的主节点，负责任务资源的分配

它是整个spark集群的从节点，负责任务计算的节点

它是一个进程，它会在worker节点启动该进程（计算资源）

spark任务是以task线程的方式运行在worker节点对应的executor进程中

4. spark集群安装部署

• 事先搭建好zookeeper集群
• 1、下载安装包 https://archive.apache.org/dist/spark/spark-2.3.3/spark-2.3.3-bin-hadoop2.7.tgz
• spark-2.3.3-bin-hadoop2.7.tgz（spark2.0后cdh对应的版本目前还没有）

/kkb/install

tar -zxvf spark-2.3.3-bin-hadoop2.7.tgz -C /kkb/install

mv spark-2.3.3-bin-hadoop2.7 spark

进入到spark的安装目录下对应的conf文件夹 vim spark-env.sh ( mv spark-env.sh.template spark-env.sh)

#配置java的环境变量
export JAVA_HOME=/kkb/install/jdk1.8.0_141
#配置zk相关信息，此处为一行
export SPARK_DAEMON_JAVA_OPTS="-Dspark.deploy.recoveryMode=ZOOKEEPER  -Dspark.deploy.zookeeper.url=node01:2181,node02:2181,node03:2181  -Dspark.deploy.zookeeper.dir=/spark"

• vim slaves ( mv slaves.template slaves)

  #指定spark集群的worker节点
  node02
  node03

scp -r /kkb/install/spark node02:/kkb/install
scp -r /kkb/install/spark node03:/kkb/install

vim /etc/profile

export SPARK_HOME=/kkb/install/spark
export PATH=$PATH:$SPARK_HOME/bin:$SPARK_HOME/sbin

scp /etc/profile node02:/etc
scp /etc/profile node03:/etc

在所有节点执行 source /etc/profile

5. spark集群的启动和停止

5.1 启动

• 1、先启动zk
• 2、启动spark集群 可以在任意一台服务器来执行（条件：需要任意2台机器之间实现ssh免密登录） $SPARK_HOME/sbin/start-all.sh
• 在哪里启动这个脚本，就在当前该机器启动一个Master进程
• 整个集群的worker进程的启动由slaves文件

$SPARK_HOME/sbin/start-master.sh

(1) 如何恢复到上一次活着master挂掉之前的状态?
在高可用模式下，整个spark集群就有很多个master，其中只有一个master被zk选举成活着的master，其他的多个master都处于standby，同时把整个spark集群的元数据信息通过zk中节点进行保存。
后期如果活着的master挂掉。首先zk会感知到活着的master挂掉，下面开始在多个处于standby中的master进行选举，再次产生一个活着的master，这个活着的master会读取保存在zk节点中的spark集群元数据信息，恢复到上一次master的状态。整个过程在恢复的时候经历过了很多个不同的阶段，每个阶段都需要一定时间，最终恢复到上个活着的master的转态，整个恢复过程一般需要1-2分钟。
(2) 在master的恢复阶段对任务的影响?
a）对已经运行的任务是没有任何影响
由于该任务正在运行，说明它已经拿到了计算资源，这个时候就不需要master。
b) 对即将要提交的任务是有影响
由于该任务需要有计算资源，这个时候会找活着的master去申请计算资源，由于没有一个活着的master,该任务是获取不到计算资源，也就是任务无法运行。

5.2 停止

• 在处于active Master主节点执行 $SPARK_HOME/sbin/stop-all.sh

$SPARK_HOME/sbin/stop-master.sh

6. spark集群的web管理界面

• 当启动好spark集群之后，可以访问这样一个地址 http://master主机名:8080（hadoop的namenode是8020）
• 可以通过这个web界面观察到很多信息 整个spark集群的详细信息
• 整个spark集群总的资源信息
• 整个spark集群已经使用的资源信息
• 整个spark集群还剩的资源信息
• 整个spark集群正在运行的任务信息
• 整个spark集群已经完成的任务信息