当前位置:   article > 正文

spark中spark-submit提交样例及参数说明

spark-submit

(yarn集群模式)
加载jar包注意:(每个jar包之间不能有空格,并且使用逗号分隔)
#在客户端提交输出日志到终端

/tmp/spark/sbin/spark-submit.sh 
--master yarn 
--deploy-mode cluster 
--driver-cores 1 
--executor-cores 1
--driver-memory 1g 
--executor-memory 1g 
--num-executors 2 
--name spark_test 
--conf spark.default.parallelism=300
--spark.yarn.jar=hdfs://nameservice1/tools/spark/spark-assembly-1.6.0-cdh5.9.3-hadoop2.6.0-cdh5.9.3.jar 
--jars dependency1.jar,dependency2.jar 
--class com.ph.bdsys.spk.main.SparkMain 
hdfs://nameserbices/tools/spark/execute.jar param1 param2
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14

#客户端后台提交输出日志到nohup.out

nohup spark-submit.sh
--master yarn 
--deploy-mode cluster
--jars /home/gzp/spark_kudu/jars/accessors-smart-1.2.jar,/home/gzp/spark_kudu/jars/zstd-jni-1.3.2-2.jar 
--class com.spark_kudu_parquet.spark_kudu 
--name spark_test
--driver-memory 2g
 --driver-cores 2 
 --executor-memory 2g 
 --executor-cores 2 
 --num-executors 24
 --conf spark.default.parallelism=200 
 spark_kudu_parquet-1.0-SNAPSHOT.jar > /home/gzp/spark_kudu/out.log &
 
(local本地单机模式)
nohup spark-submit 
--master local 
--deploy-mode client 
--jars /home/gzp/spark_kudu/jars/accessors-smart-1.2.jar,1.4.jar 
--class com.spark_kudu_parquet.spark_kudu 
--name spark_kudu 
--driver-memory 2g 
--driver-cores 2 
--executor-memory 2g 
--executor-cores 2 
--num-executors 24 
--conf spark.default.parallelism=300 
spark_kudu_parquet-1.0-SNAPSHOT.jar > /home/gzp/spark_kudu/out.log &
	参数解析:
		1.3台主机,每台主机有2个cpu和62G内存,每个cpu有8个核,那么每台机器一共有16核,3台机器一共有48个核
		2.num-executors 24 和 executor-cores 2:每个executors用2个核,那么24个executors一共用48个核
		3.num-executors 24 和 executor-memory 2g:每个executors用2g,那么24个executors一共用48g
		4.每个主机的executors数量 = 30 / 8 约等于 3.75
		5.spark.default.parallelism:指定并行的task数量为300
            参数说明:该参数用于设置每个stage的默认task数量。这个参数极为重要,如果不设置可能会直接影响你的Spark作业性能。
			参数调优建议:Spark作业的默认task数量为500~1000个较为合适。很多同学常犯的一个错误就是不去设置这个参数,
						  那么此时就会导致Spark自己根据底层HDFS的block数量来设置task的数量,默认是一个HDFS block对应一个task。
						  通常来说,Spark默认设置的数量是偏少的(比如就几十个task),如果task数量偏少的话,就会导致你前面设置好的Executor的参数都前功尽弃。
						  试想一下,无论你的Executor进程有多少个,内存和CPU有多大,但是task只有1个或者10个,那么90%的Executor进程可能根本就没有task执行,
						  也就是白白浪费了资源!因此Spark官网建议的设置原则是,设置该参数为num-executors * executor-cores的2~3倍较为合适,
						  比如Executor的总CPU core数量为300个,那么设置1000个task是可以的,此时可以充分地利用Spark集群的资源。
				
 
ps aux|grep spark_kudu_parquet-1.0-SNAPSHOT.jar			
查看yarn当前运行任务列表,可使用如下命令查看:yarn application -list
如需杀死当前某个作业,使用kill application-id的命令如下:yarn application -kill spark程序id
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
nohup spark-submit 
--master yarn  
--deploy-mode cluster 
--jars /home/xx/lib/mysql-connector-java-5.1.32-bin.jar  
--class xxx.xx.xx 
--name XX 
--driver-memory 2g 
--driver-cores 2 
--executor-memory 2g 
--executor-cores 2  
--num-executors 30  
--conf spark.default.parallelism=300  
xx-0.0.1-SNAPSHOT.jar  > xx.log  &
	参数解析:
		1.8台主机,每台主机有2个cpu和62G内存,每个cpu有8个核,那么每台机器一共有16核,8台机器一共有128核
		2.num-executors 30 和 executor-cores 2:每个executors用2个核,那么30个executors一共用60个核
		3.num-executors 30 和 executor-memory 2g:每个executors用2g,那么30个executors一共用60g
		4.每个主机的executors数量 = 30 / 8 约等于 3.75
		5.spark.default.parallelism:指定并行的task数量为300
			参数说明:该参数用于设置每个stage的默认task数量。这个参数极为重要,如果不设置可能会直接影响你的Spark作业性能。
			参数调优建议:Spark作业的默认task数量为500~1000个较为合适。很多同学常犯的一个错误就是不去设置这个参数,
						  那么此时就会导致Spark自己根据底层HDFS的block数量来设置task的数量,默认是一个HDFS block对应一个task。
						  通常来说,Spark默认设置的数量是偏少的(比如就几十个task),如果task数量偏少的话,就会导致你前面设置好的Executor的参数都前功尽弃。
						  试想一下,无论你的Executor进程有多少个,内存和CPU有多大,但是task只有1个或者10个,那么90%的Executor进程可能根本就没有task执行,
						  也就是白白浪费了资源!因此Spark官网建议的设置原则是,设置该参数为num-executors * executor-cores的2~3倍较为合适,
						  比如Executor的总CPU core数量为300个,那么设置1000个task是可以的,此时可以充分地利用Spark集群的资源。
				  
num-executors
	参数说明:该参数用于设置Spark作业总共要用多少个Executor进程来执行。
			  Driver在向YARN集群管理器申请资源时,YARN集群管理器会尽可能按照你的设置来在集群的各个工作节点上,启动相应数量的Executor进程。
			  这个参数非常之重要,如果不设置的话,默认只会给你启动少量的Executor进程,此时你的Spark作业的运行速度是非常慢的。
	参数调优建议:每个Spark作业的运行一般设置50~100个左右的Executor进程比较合适,设置太少或太多的Executor进程都不好。
				  设置的太少,无法充分利用集群资源;设置的太多的话,大部分队列可能无法给予充分的资源。
				  
executor-cores
	参数说明:该参数用于设置每个Executor进程的CPU core数量。这个参数决定了每个Executor进程并行执行task线程的能力。
			  因为每个CPU core同一时间只能执行一个task线程,因此每个Executor进程的CPU core数量越多,越能够快速地执行完分配给自己的所有task线程。
	参数调优建议:Executor的CPU core数量设置为2~4个较为合适。
				  同样得根据不同部门的资源队列来定,可以看看自己的资源队列的最大CPU core限制是多少,再依据设置的Executor数量,来决定每个Executor进程可以分配到几个CPU core。
				  同样建议,如果是跟他人共享这个队列,那么num-executors * executor-cores不要超过队列总CPU core的1/3~1/2左右比较合适,也是避免影响其他同学的作业运行。
				  
executor-memory
	参数说明:该参数用于设置每个Executor进程的内存。Executor内存的大小,很多时候直接决定了Spark作业的性能,而且跟常见的JVM OOM异常,也有直接的关联。
	参数调优建议:每个Executor进程的内存设置4G~8G较为合适。但是这只是一个参考值,具体的设置还是得根据不同部门的资源队列来定。
				  可以看看自己团队的资源队列的最大内存限制是多少,num-executors乘以executor-memory,就代表了你的Spark作业申请到的总内存量(也就是所有Executor进程的内存总和),
				  这个量是不能超过队列的最大内存量的。此外,如果你是跟团队里其他人共享这个资源队列,那么申请的总内存量最好不要超过资源队列最大总内存的1/3~1/2,
				  避免你自己的Spark作业占用了队列所有的资源,导致别的同学的作业无法运行。
				  
				  
--driver-memory
	Driver内存,默认1G
 
--driver-cores
	Driver的核数,默认是1。在yarn集群模式下使用
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54

====================================================================================================

在我们提交spark程序时,应该如何为Spark集群配置 num-executors、executor-memory、execuor-cores 呢?
Hadoop / Yarn / OS Deamons
当我们使用像Yarn这样的集群管理器运行spark应用程序时,会有几个守护进程在后台运行,如NameNode,Secondary NameNode,DataNode,JobTracker和TaskTracker等。
因此,在指定num-executors时,我们需要确保为这些守护进程留下足够的核心(至少每个节点约1 CPU核)以便顺利运行。
Yarn ApplicationMaster(AM)
ApplicationMaster负责协调来自ResourceManager的资源,并与NodeManagers一起执行container并监控其资源消耗。
如果我们在YARN上运行Spark,那么我们需要预估运行AM所需要的资源(至少1024MB和1 CPU核)。
HDFS吞吐量
HDFS客户端遇到大量并发线程会出现一些bug。一般来说,每个executors最多可以实现5个任务的完全写入吞吐量,因此最好将每个executors的核心数保持在该数量之下。
MemoryOverhead
JVM还需要一些off heap的内存,请参考下图中描绘的Spark和YARN中内存属性的层次结构,

简单来说,有以下两个公式:
每个executor从YARN请求的内存 = spark.executor-memory + spark.yarn.executor.memoryOverhead
spark.yarn.executor.memoryOverhead = Max(384MB, 7% of spark.executor-memory)
例如当我设置 --executor-memory=20 时,我们实际请求了 20GB + memoryOverhead = 20 + 7% of 20GB = ~23GB。
运行具有executors较大内存的通常会导致过多的GC延迟。
运行具有executors较小内存的(例如,1G & 1 CPU core)则会浪费 单个JVM中运行多个任务所带来的优点。

不同配置的优劣分析
1.现在,让我们考虑一个具有以下配置的10节点集群,并分析执行程序的不同可能性,核心内存分布:
10 Nodes
每个Node:16 cores、64GB RAM
2.第一种方法:使用较小的executors,每个核心一个executors
--num-executors = 在这种方法中,我们将为每个核心分配一个executor
= 集群的总核心数
= 每个节点的核心数 * 集群的总节点数
= 16 x 10 = 160

	`--executor-cores`  = 1 (`每个executor分配的核心数目`)

	`--executor-memory` = `每个executor分配的内存数`
						= `每个节点内存总数 / 每个节点上分配的executor数`
						= 64GB/16 = 4GB
	分析:
		由于每个executor只分配了一个核,我们将无法利用在同一个JVM中运行多个任务的优点。 
		此外,共享/缓存变量(如广播变量和累加器)将在节点的每个核心中复制16次。 
		最严重的就是,我们没有为Hadoop / Yarn守护程序进程留下足够的内存开销,我们还忘记了将ApplicationManagers运行所需要的开销加入计算。
		
3.第二种方法:使用较大的executors,每个节点一个executors
	`--num-executors` = `在这种方法中,我们将为每个节点分配一个executor`
					  = `集群的总节点数`
					  = 10
						
	`--executor-cores` = `每个节点一个executor意味着该节点的所有核心都分配给一个执executor`
					   = `每个节点的总核心数`
					   = 16
						 
	`--executor-memory` = `每个executor分配的内存数`
						= `每个节点内存总数数/每个节点上分配的executor数`
						= 64GB/1 = 64GB

	分析:
		每个executor都有16个核心,由于HDFS客户端遇到大量并发线程会出现一些bug,即HDFS吞吐量会受到影响。
		同时过大的内存分配也会导致过多的GC延迟。ApplicationManager和守护进程没有计算在内,HDFS的吞吐量会受到影响,并且会导致垃圾结果过多,不好!

4.第三种方法:使用优化的executors
	1.基于上面提到的建议,让我们为每个执行器分配5个核心, 即 --executor-cores = 5(用于良好的HDFS吞吐量)
	2.为每个节点留出1个核心用于Hadoop / Yarn守护进程, 即每个节点可用的核心数为 16 -1 = 15。 因此,群集中核心的可用总数剩余 15 x 10 = 150
	3.可用executors的数量 =(群集中核心的可用总数/每个executors分配的核心数)= 150/5 = 30
	  然后为ApplicationManager预留1个executors的资源,所以即 --num-executors = 29
	  每个节点的executors数目 30/10 = 3
	4.群集中每个节点的可使用的总内存数 64GB - 1GB = 63GB
	  每个executor的内存= 64GB / 3 = 21GB
	  预留的 off heap overhead = 21GB * 7% 约等于 1.47G
	  所以,实际的--executor-memory = 21 - 1.47G 约等于 19GB
	5.所以,推荐的配置是:29个executors,每个executors 18GB内存,每个executors 5个核心!
		--num-executors = 29
		--executor-cores = 5
		--executor-memory = 18
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41

====================================================================================================
属性名称 默认值 含义
spark.cores.max (infinite) 当运行在一个独立部署集群上或者是一个粗粒度共享模式的Mesos集群上的时候,最多可以请求多少个CPU核心。默认是所有的都能用。
spark.executor.memory 512m 每个处理器可以使用的内存大小,跟JVM的内存表示的字符串格式是一样的(比如: ‘512m’,‘2g’)

executor 数量 = spark.cores.max / spark.executor.cores
executor 进程的数量 等于 spark程序设置的最大核心数 除以 每个 executor进程分配的 核心数

比如机器有12cpu和36g内存,那么将会启动12/4=3个executor,每个executor使用4cpu和12g内存,总共占用worker资源12cpu和36g内存
默认情况下,Spark集群下的worker,只会启动一个Executor。
1、设置每个executor使用的cpu数为4
spark.executor.cores 4
2、设置cpu的最大使用数量
spark.cores.max 12
3、设置每个executor的内存大小为12gg
spark.executor.memory 12g

Spark1.6的源码部分为:
protected final String EXECUTOR_MEMORY = “–executor-memory”;
protected final String TOTAL_EXECUTOR_CORES = “–total-executor-cores”;
protected final String EXECUTOR_CORES = “–executor-cores”;

也可以在提交任务的时候添加:
SparkSubmit
–class com.dyq.spark.MyClass
–master:spark://master:7077
–total-executor-cores 12
–executor-cores 24
–executor-memory 12g

Executor是spark任务(task)的执行单元,Executor运行在worker上,但是不等同于worker,实际上Executor是一组计算资源(cpu核心、memory)的集合。
一个worker上的memory、cpu由多个executor共同使用。

spark.executor.cores 顾名思义这个参数是用来指定executor的cpu内核个数,分配更多的内核意味着executor并发能力越强,能够同时执行更多的task
spark.cores.max 为一个application分配的最大cpu核心数,如果没有设置这个值默认为spark.deploy.defaultCores
spark.executor.memory 配置executor内存大小

executor个数 = spark.max.cores / spark.executor.cores
集群的executor个数由spark.max.cores、spark.executor.cores共同决定,注意在standalone、mesos coarse-grained模式 下cores不要大于对应节点的内核数
要保证每个worker上启动的executor均衡。如果不均衡的话会造成数据倾斜,拉慢任务的整体速度。
在运行过程中一个task对应一个partition,配置不均衡,会导致每个节点处理的任务量不一样,因此会产生短板效应。
如果运行过程中发现GC时间变红(管理界面可以看到),应该适当调大spark.executor.memory

====================================================================================================

1.RDD在计算的时候,RDD中的每个分区都会起一个task,所以rdd中的分区数目决定了总的的task数目。
2.申请的计算节点Executor数目和每个计算节点核数,决定了你同一时刻可以并行执行的task数目。
3.比如的RDD中有100个分区,那么计算的时候就会生成100个task,你的资源配置为10个计算节点Executor数目,每个计算节点Executor有两2个核,
同一时刻可以并行的task数目为20,计算这个RDD就需要5轮。
4.如果计算资源不变,你有101个task的话,就需要6个轮次,在最后一轮中,只有一个task在执行,其余核都在空转。
5.如果资源不变,你的RDD只有2个分区,那么同一时刻只有2个task运行,其余18个核空转,造成资源浪费。这就是在spark调优中,增大RDD分区数目,增大任务并行度的做法。

指定spark executor 数量的公式
executor数量 = spark.cores.max/spark.executor.cores
spark.cores.max 是指你的spark程序需要的总核数
spark.executor.cores 是指每个executor需要的核数

指定并行的task数量
spark.default.parallelism
参数说明:该参数用于设置每个stage的默认task数量。这个参数极为重要,如果不设置可能会直接影响你的Spark作业性能。
参数调优建议:Spark作业的默认task数量为500~1000个较为合适。很多同学常犯的一个错误就是不去设置这个参数,
那么此时就会导致Spark自己根据底层HDFS的block数量来设置task的数量,默认是一个HDFS block对应一个task。
通常来说,Spark默认设置的数量是偏少的(比如就几十个task),如果task数量偏少的话,就会导致你前面设置好的Executor的参数都前功尽弃。
试想一下,无论你的Executor进程有多少个,内存和CPU有多大,但是task只有1个或者10个,那么90%的Executor进程可能根本就没有task执行,
也就是白白浪费了资源!因此Spark官网建议的设置原则是,设置该参数为num-executors * executor-cores的2~3倍较为合适,
比如Executor的总CPU core数量为300个,那么设置1000个task是可以的,此时可以充分地利用Spark集群的资源。

在关于spark任务并行度的设置中,有两个参数我们会经常遇到,spark.sql.shuffle.partitions 和 spark.default.parallelism, 那么这两个参数到底有什么区别的?
首先,让我们来看下它们的定义

spark.sql.shuffle.partitions(对sparks SQL专用的设置)
默认值:200
含义:当shuffle数据时,配置joins联接或aggregations聚合时要使用的分区数

spark.default.parallelism(只有在处理RDD时才会起作用,对Spark SQL的无效)
默认值:
1.对于分布式无序移动操作(如reducebykey和join),父RDD中的最大分区数。
2.对于没有父RDD的并行化操作,它取决于集群管理器:
1.本地模式:本地计算机上的核心数
2.细粒模式:8
3.其他:所有执行器节点上的核心总数或2个,以较大者为准。
含义:在RDD中,由join、reducebykey、parallelize等转换(如果不是由用户设置)返回的默认分区数

命令示例
spark-submit
–class com.cjh.test.WordCount
–conf spark.default.parallelism=12
–conf spark.executor.memory=800m
–conf spark.executor.cores=2
–conf spark.cores.max=6 my.jar

spark-submit 	
	--conf spark.sql.shuffle.partitions=20 
	--conf spark.default.parallelism=20
  • 1
  • 2
  • 3

====================================================================================================

spark.storage.memoryFraction

参数说明:该参数用于设置RDD持久化数据在Executor内存中能占的比例,默认是0.6。也就是说,默认Executor 60%的内存,可以用来保存持久化的RDD数据。
		  根据你选择的不同的持久化策略,如果内存不够时,可能数据就不会持久化,或者数据会写入磁盘。

参数调优建议:如果Spark作业中,有较多的RDD持久化操作,该参数的值可以适当提高一些,保证持久化的数据能够容纳在内存中。
		      避免内存不够缓存所有的数据,导致数据只能写入磁盘中,降低了性能。但是如果Spark作业中的shuffle类操作比较多,而持久化操作比较少,
			  那么这个参数的值适当降低一些比较合适。此外,如果发现作业由于频繁的gc导致运行缓慢(通过spark web ui可以观察到作业的gc耗时),
			  意味着task执行用户代码的内存不够用,那么同样建议调低这个参数的值。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

spark.shuffle.memoryFraction

参数说明:该参数用于设置shuffle过程中一个task拉取到上个stage的task的输出后,进行聚合操作时能够使用的Executor内存的比例,默认是0.2。
	      也就是说,Executor默认只有20%的内存用来进行该操作。shuffle操作在进行聚合时,如果发现使用的内存超出了这个20%的限制,
		  那么多余的数据就会溢写到磁盘文件中去,此时就会极大地降低性能。

参数调优建议:如果Spark作业中的RDD持久化操作较少,shuffle操作较多时,建议降低持久化操作的内存占比,提高shuffle操作的内存占比比例,
			  避免shuffle过程中数据过多时内存不够用,必须溢写到磁盘上,降低了性能。此外,如果发现作业由于频繁的gc导致运行缓慢,
			  意味着task执行用户代码的内存不够用,那么同样建议调低这个参数的值。
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

Spark最主要资源管理方式按排名为Hadoop Yarn, Apache Standalone 和Mesos。
在单机使用时,Spark还可以采用最基本的local模式。
目前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对于小规模计算集群更适合!

编写好的Spark程序一般通过Spark-submit指令的方式提交给Spark集群进行具体的任务计算,
Spark-submit指令可以指定一些向集群申请资源的参数(也可直接在Spark程序代码中指定,参数生效的优先级最高),
在Linux环境下,可通过spark-submit –help 了解spark-submit指令的各种参数说明。

案例(Python任务提交):
spark-submit –master spark://192.168.1.10:7077 –name router_app –total-executor-cores 8 –executor-memory 4g router_inout.py

常用的重要参数详解:

  1. –master MASTER_URL: 指定要连接的集群模式(集群资源管理器)
    standalone模式: spark://host:port, 如:spark://192.168.1.10:7077
    Spark On Mesos模式 : mesos://host:port
    Spark On YARN模式: yarn://host:port
    本地模式:local

  2. – deploy-mode DEPLOY_MODE : 指定任务的提交方式(client 和cluster)
    client: 本地客户端模式(默认方式),一般会在集群主节点安装客户端
    cluster: 集群工作节点模式
    任务最终都会提交给主节点处理,所以在指定任务提交方式时,考虑本地客户端和集群工作节点对主节点的网络开销问题即可。

3)–name appName :设置任务的名称,方便在webUI查看

4)–py-files PY_FILES :加载Python外部依赖文件

5)–driver-memory MEM:设置driver的运行内存(占用客户端内存,用于通信及调度开销,默认为1G)

6)–executor-memory MEM:设置每一个executor的运行内存(占用工作节点内存,主要用于执行任务的内存开销),executor代表work节点上的一个进程。

7)–total-executor-cores NUM:设置任务占用的总CPU核数(即任务的并发量),由主节点指定各个工作节点CPU的使用数。
注意:该参数选项只在Spark standalone and Mesos 模式下有效

8)–executor-cores NUM:设置执行任务的每一个executor的CPU核数(yarn模式有效,默认为1)或者工作节点的总CPU核数(standalone模式有效)

9)–num-executors NUM:设置任务的executor进程数(yarn模式下有效)

10)–conf PROP=VALUE:设置Spark的属性参数
–conf spark.default.parallelism=1000 设置RDD分区大小,系统默认为200
–conf spark.storage.memoryFraction=0.5 设置内存分配大小(存储),系统默认为0.6
–conf spark.shuffle.memoryFraction=0.3 设置shuffle上限内存空间,系统默认为0.2

编写好的Spark程序一般通过Spark-submit指令的方式提交给Spark集群进行具体的任务计算,
Spark-submit指令可以指定一些向集群申请资源的参数(也可直接在Spark程序代码中指定,参数生效的优先级最高),
在Linux环境下,可通过spark-submit –help 了解spark-submit指令的各种参数说明。

spark-submit -help 命令 查看所有参数帮助

Usage: spark-submit [options] <app jar | python file | R file> [app arguments]
Usage: spark-submit --kill [submission ID] --master [spark://…]
Usage: spark-submit --status [submission ID] --master [spark://…]
Usage: spark-submit run-example [options] example-class [example args]

Options:
–master MASTER_URL spark://host:port, mesos://host:port, yarn,
k8s://https://host:port, or local (Default: local[*]).

–deploy-mode DEPLOY_MODE 是否在本地启动驱动程序 (“client”) 或 在集群中的一台工作机上 (“cluster”)
(默认值: client)

–class CLASS_NAME 你的应用程序的主要类(对于Java/Scala应用程序)。

–name NAME 应用程序的名称

–jars JARS 驱动程序上要包含的jar的逗号分隔列表和执行器类路径

–packages 要包含的jar maven坐标的逗号分隔列表在驱动程序和执行器类路径上。
将搜索本地 Maven repo,然后是Maven Central和任何附加远程存储库由–repositories 提供。
坐标应为groupid:artifactid:version的格式

–exclude-packages groupid:artifactid的逗号分隔列表,在解析包中提供的依赖项以避免依赖关系冲突

–repositories 以逗号分隔的其他远程存储库列表搜索给定的maven坐标–packages

–py-files PY_FILES 要放置的.zip、.egg或.py文件的逗号分隔列表
在pythonpath for python应用程序上。

–files FILES 要放置在工作中的文件的逗号分隔列表每个执行者的目录。
这些文件的文件路径可以通过sparkfiles.get(文件名)访问in执行器

–conf PROP=VALUE 任意Spark配置属性

–properties-file FILE 要从中加载额外属性的文件的路径。
如果没有指定后,将查找conf/spark-defaults.conf。

–driver-memory MEM 驱动程序内存(例如1000M、2G)(默认值:1024M)

–driver-java-options 额外的Java选项传递给驱动程序。

–driver-library-path 要传递给驱动程序的额外库路径项

–driver-class-path 要传递给驱动程序的额外类路径条目。注意添加的jar 自动包含在 --jar 类路径

–executor-memory MEM 每个执行器的内存(例如1000M、2G)(默认值:1G)

–proxy-user NAME 提交应用程序时要模拟的用户。
此参数不适用于–principal/–keytab。

–help, -h 显示此帮助消息并退出

–verbose, -v 打印其他调试输出。

–version, 打印当前spark的版本

Cluster deploy mode only:
–driver-cores NUM 驱动程序仅在群集模式下使用的核心数(默认值: 1)

Spark standalone or Mesos with cluster deploy mode only:
–supervise 如果给定,则在出现故障时重新启动驱动程序
–kill SUBMISSION_ID 如果给定,则杀死指定的驱动程序。
–status SUBMISSION_ID 如果给定,则请求指定的驱动程序的状态。

Spark standalone and Mesos only:
–total-executor-cores NUM 所有执行器的核心总数。

Spark standalone and YARN only:
–executor-cores NUM 每个executor 占用的cores核心数
(默认值: 1 在 YARN 模式,或者 工作机上所有可用的核心处于 standalone 模式)
YARN-only:
–queue QUEUE_NAME 要提交到的YARN队列(默认值: “default”)

  --num-executors NUM         要启动的executors数 (默认值: 2)。如果启用了动态分配,则executors至少为num。

  --archives ARCHIVES         以逗号分隔的要提取到每个执行者的工作目录。

  --principal PRINCIPAL       用于登录到kdc的主体, 在HDFS上安全运行
							   
  --keytab KEYTAB             包含键选项卡的文件的完整路径上面指定的主体。
							  此密钥选项卡将复制到通过安全的分布式缓存,用于更新登录票证tickets 和 定期委派令牌tokens 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

原文链接:https://blog.csdn.net/zimiao552147572/article/details/96482120

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/码创造者/article/detail/888106
推荐阅读
相关标签
  

闽ICP备14008679号