Spark之本地模式与集群模式
原文：https://blog.csdn.net/qq_33689414/article/details/80232605
1.spark-shell的本地模式和集群模式
1.1 local本地模式
直接启动spark-shell命令窗口
脚本启动后，会生成一个SparkContext的上下文对象sc。并且启动的是本地模式(local)。如图：
1.1.1 加载本地数据
sc.textFile("file:///home/hadoop/words.txt").flatMap(_.split(",")).map((_,1)).reduceByKey(_+_).sortBy(_._2,true).collect()
1.1.2 加载hdfs数据
-
# 因为在spark-env.sh中配置了
HADOOP_CONF_DIR目录，所以默认使用hdfs文件系统。
-
# /spark/words.txt：表示hdfs文件系统目录
-
sc.textFile(
"/spark/words.txt").flatMap(
_.
split(
",")).
map((
_,
1)).reduceByKey(
_+
_).sortBy(
_._2,
true).collect()
1.2 集群模式
1.2.1 启动集群模式的spark-shell窗口
spark-shell --master spark://server01:7077 --total-executor-cores 3 --executor-memory 1g
参数介绍：
-
--master spark://server01:7077:指定master进程的机器
-
-
--total-executor-cores 3:指定executor的核数（worker数量）
-
-
--executor-memory 1g:指定executor执行的内存大小
1.2.2 代码执行
sc.textFile("/spark/words.txt").flatMap(_.split(",")).map((_,1)).reduceByKey(_+_).sortBy(_._2).collect()
1.2.3 结果查看
通过集群模式提交的任务，在web页面上是有展示的
本地模式（local）和集群模式的区别
1.本地模式不运行在集群上，运行在当前执行的机器上
2.本地模式的任务不会在web页面显示
3.本地模式是采用线程来模拟集群的worker进程
2. scala api实现的本地模式和集群模式
2.1 local本地模式
-
object WordCountLocal {
-
def main(args:
Array[
String]): Unit = {
-
val conf =
new SparkConf().setAppName(
"wordcount").setMaster(
"local[2]")
-
val sc =
new SparkContext(conf)
-
sc.textFile(
"file:///d:/a.txt").flatMap(_.
split(
",")).map((_,
1)).reduceByKey(_ + _).sortBy(_._2).saveAsTextFile(
"file:///d:/out")
-
}
-
}
因为本地安装了spark，所以可以直接在本地运行，在本地运行。
setMaster("local[2]")中local表示本地运行,[2]表示是使用2个线程。
2.2 生成jar提交到集群
代码：
-
object WordCountMaster {
-
def main(args:
Array[
String]): Unit = {
-
val conf =
new SparkConf().setAppName(
"WordCountMaster")
-
val sparkContext =
new SparkContext(conf)
-
sparkContext.textFile(args(
0)).flatMap(_.
split(
",")).map((_,
1)).reduceByKey(_ + _).sortBy(_._2).saveAsTextFile(args(
1))
-
}
-
}
提交到集群：
-
spark-submit \
-
--master spark://server01:7077 \
-
--executor-memory 1g \
-
--total-executor-cores 2 \
-
--class com.yundoku.spark.WordCountMaster \
-
/home/hadoop/sparkscalawordcount.jar \
-
/spark/words.txt \
-
/spark/scala_wordcount_out
参数讲解：
-
--master:指定集群的master
-
--executor-memory:executor的内存大小（worker）
-
--total-executor-cores 2:executor核数为2（worker的执行个数）
-
--class com.yundoku.spark.WordCountMaster:包含main的类，程序的入口
-
-
/home/hadoop/sparkscalawordcount.jar :jar文件
-
/spark/words.txt:输入参数1
-
/spark/scala_wordcount_out：输入参数2
运行结果：
这里会生成part-000000和part-0000012个结果文件，表示有2个分区。
原因是，在spark的读取文件时默认是使用的最小分区为2
defaultMinPartitions的值初始化，如下图所示
3.Spark集群三种部署模式的区别
目前Apache Spark支持三种分布式部署方式，分别是standalone、spark on mesos和 spark on YARN，其中，第一种类似于MapReduce 1.0所采用的模式，内部实现了容错性和资源管理，后两种则是未来发展的趋势，部分容错性和资源管理交由统一的资源管理系统完成：让Spark运行在一个通用的资源管理系统之上，这样可以与其他计算框架，比如MapReduce，公用一个集群资源，最大的好处是降低运维成本和提高资源利用率（资源按需分配）。本文将介绍这三种部署方式，并比较其优缺点。
1. Standalone模式
即独立模式，自带完整的服务，可单独部署到一个集群中，无需依赖任何其他资源管理系统。从一定程度上说，该模式是其他两种的基础。借鉴Spark开发模式，我们可以得到一种开发新型计算框架的一般思路：先设计出它的standalone模式，为了快速开发，起初不需要考虑服务（比如master/slave）的容错性，之后再开发相应的wrapper，将stanlone模式下的服务原封不动的部署到资源管理系统yarn或者mesos上，由资源管理系统负责服务本身的容错。目前Spark在standalone模式下是没有任何单点故障问题的，这是借助zookeeper实现的，思想类似于Hbase master单点故障解决方案。将Spark standalone与MapReduce比较，会发现它们两个在架构上是完全一致的：
1) 都是由master/slaves服务组成的，且起初master均存在单点故障，后来均通过zookeeper解决（Apache MRv1的JobTracker仍存在单点问题，但CDH版本得到了解决）；
2) 各个节点上的资源被抽象成粗粒度的slot，有多少slot就能同时运行多少task。不同的是，MapReduce将slot分为map slot和reduce slot，它们分别只能供Map Task和Reduce Task使用，而不能共享，这是MapReduce资源利率低效的原因之一，而Spark则更优化一些，它不区分slot类型，只有一种slot，可以供各种类型的Task使用，这种方式可以提高资源利用率，但是不够灵活，不能为不同类型的Task定制slot资源。总之，这两种方式各有优缺点。
2. Spark On Mesos模式
这是很多公司采用的模式，官方推荐这种模式（当然，原因之一是血缘关系）。正是由于Spark开发之初就考虑到支持Mesos，因此，目前而言，Spark运行在Mesos上会比运行在YARN上更加灵活，更加自然。目前在Spark On Mesos环境中，用户可选择两种调度模式之一运行自己的应用程序（可参考Andrew Xia的“Mesos Scheduling Mode on Spark”）：
1) 粗粒度模式（Coarse-grained Mode）：每个应用程序的运行环境由一个Dirver和若干个Executor组成，其中，每个Executor占用若干资源，内部可运行多个Task（对应多少个“slot”）。应用程序的各个任务正式运行之前，需要将运行环境中的资源全部申请好，且运行过程中要一直占用这些资源，即使不用，最后程序运行结束后，回收这些资源。举个例子，比如你提交应用程序时，指定使用5个executor运行你的应用程序，每个executor占用5GB内存和5个CPU，每个executor内部设置了5个slot，则Mesos需要先为executor分配资源并启动它们，之后开始调度任务。另外，在程序运行过程中，mesos的master和slave并不知道executor内部各个task的运行情况，executor直接将任务状态通过内部的通信机制汇报给Driver，从一定程度上可以认为，每个应用程序利用mesos搭建了一个虚拟集群自己使用。
2) 细粒度模式（Fine-grained Mode）：鉴于粗粒度模式会造成大量资源浪费，Spark On Mesos还提供了另外一种调度模式：细粒度模式，这种模式类似于现在的云计算，思想是按需分配。与粗粒度模式一样，应用程序启动时，先会启动executor，但每个executor占用资源仅仅是自己运行所需的资源，不需要考虑将来要运行的任务，之后，mesos会为每个executor动态分配资源，每分配一些，便可以运行一个新任务，单个Task运行完之后可以马上释放对应的资源。每个Task会汇报状态给Mesos slave和Mesos Master，便于更加细粒度管理和容错，这种调度模式类似于MapReduce调度模式，每个Task完全独立，优点是便于资源控制和隔离，但缺点也很明显，短作业运行延迟大。
3. Spark On YARN模式
这是一种很有前景的部署模式。但限于YARN自身的发展，目前仅支持粗粒度模式（Coarse-grained Mode）。这是由于YARN上的Container资源是不可以动态伸缩的，一旦Container启动之后，可使用的资源不能再发生变化，不过这个已经在YARN计划中了。
spark on yarn 的支持两种模式：
1) yarn-cluster：适用于生产环境；
2) yarn-client：适用于交互、调试，希望立即看到app的输出
yarn-cluster和yarn-client的区别在于yarn appMaster，每个yarn app实例有一个appMaster进程，是为app启动的第一个container；负责从ResourceManager请求资源，获取到资源后，告诉NodeManager为其启动container。yarn-cluster和yarn-client模式内部实现还是有很大的区别。如果你需要用于生产环境，那么请选择yarn-cluster；而如果你仅仅是Debug程序，可以选择yarn-client。
总结：
这三种分布式部署方式各有利弊，通常需要根据实际情况决定采用哪种方案。进行方案选择时，往往要考虑公司的技术路线（采用Hadoop生态系统还是其他生态系统）、相关技术人才储备等。上面涉及到Spark的许多部署模式，究竟哪种模式好这个很难说，需要根据你的需求，如果你只是测试Spark Application，你可以选择local模式。而如果你数据量不是很多，Standalone 是个不错的选择。当你需要统一管理集群资源（Hadoop、Spark等），那么你可以选择Yarn或者mesos，但是这样维护成本就会变高。
· 从对比上看，mesos似乎是Spark更好的选择，也是被官方推荐的
· 但如果你同时运行hadoop和Spark,从兼容性上考虑，Yarn是更好的选择。 · 如果你不仅运行了hadoop，spark。还在资源管理上运行了docker，Mesos更加通用。
· Standalone对于小规模计算集群更适合！
原文：https://blog.csdn.net/qq_33689414/article/details/80232605