精华内容
下载资源
问答
  • spark-submit 参数设置

    万次阅读 2019-12-03 17:05:02
    在使用spark时,根据集群资源情况和任务数据量等,合理设置参数,包括但不限于以下: 参数 说明 master yarn E-MapReduce 使用 Yarn 的模式 yarn-client:等同于 –-master yarn —deploy-mode client, ...

    在使用spark时,根据集群资源情况和任务数据量等,合理设置参数,包括但不限于以下:

    参数说明
    masteryarn  E-MapReduce 使用 Yarn 的模式
    yarn-client:等同于 –-master yarn —deploy-mode client, 此时不需要指定deploy-mode。 
    yarn-cluster:等同于 –-master yarn —deploy-mode cluster, 此时不需要指定deploy-mode。
    class作业的主类
    deploy-modeclient 模式表示作业的 AM 会放在 Master 节点上运行。要注意的是,如果设置这个参数,那么需要同时指定上面 master 为 yarn。
    cluster 模式表示 AM 会随机的在 worker 节点中的任意一台上启动运行。要注意的是,如果设置这个参数,那么需要同时指定上面 master 为yarn。
    executor-cores每个executor使用的内核数,默认为1
    num-executors启动executor的数量,默认为2
    executor-memoryexecutor的内存大小,默认为1G
    driver-coresdriver使用的内核数,默认为1
    driver-memorydriver的内存大小,默认为1G
    queue指定了放在哪个队列里执行
    spark.default.parallelism该参数用于设置每个stage的默认task数量。这个参数极为重要,如果不设置可能会直接影响你的Spark作业性能,Spark官网建议的设置原则是,设置该参数为num-executors * executor-cores的2~3倍较为合适
    spark.storage.memoryFraction   该参数用于设置RDD持久化数据在Executor内存中能占的比例,默认是0.6。也就是说,默认Executor 60%的内存,可以用来保存持久化的RDD数据。根据你选择的不同的持久化策略,如果内存不够时,可能数据就不会持久化,或者数据会写入磁盘。
    spark.shuffle.memoryFraction 该参数用于设置shuffle过程中一个task拉取到上个stage的task的输出后,如果发现使用的内存超出了这个20%的限制,那么多余的数据就会溢写到磁盘文件中去,如果发现使用的内存超出了这个20%的限制,那么多余的数据就会溢写到磁盘文件中去,此时就会极大地降低性能。
    total-executor-cores所有executor的总核数

     

    (1)executor_cores*num_executors 
         表示的是能够并行执行Task的数目不宜太小或太大!一般不超过总队列 cores 的 25%,比如队列总 cores    400,最大不要超过100,最小不建议低于40,除非日志量很小。

    (2)executor_cores 
         不宜为1!否则 work 进程中线程数过少,一般 2~4 为宜。

    (3)executor_memory 
         一般 6~10g 为宜,最大不超过20G,否则会导致GC代价过高,或资源浪费严重。

    (4)driver-memory 
         driver 不做任何计算和存储,只是下发任务与yarn资源管理器和task交互,除非你是 spark-shell,否则一般 1-2g
         
    (5)如果需要对RDD进行cache,那么更多的内存,就可以缓存更多的数据,将更少的数据写入磁盘,甚至不写入磁盘。减少了磁盘IO。

    (6)对于shuffle操作,reduce端,会需要内存来存放拉取的数据并进行聚合。如果内存不够,也会写入磁盘。
         如果给executor分配更多内存以后,就有更少的数据,需要写入磁盘,甚至不需要写入磁盘。减少了磁盘IO,提升了性能。

    (7)对于task的执行,可能会创建很多对象.如果内存比较小,可能会频繁导致JVM堆内存满了,然后频繁GC,垃圾回收 ,minor GC和full GC.(速度很慢).内存加大以后,带来更少的GC,垃圾回收,避免了速度变慢,性能提升。
     

     

    展开全文
  • Spark-submit参数说明

    千次阅读 2019-06-25 11:56:22
    spark-submit [--options] <app jar | python file> [app arguments] 参数名称 含义 --masterMASTER_URL 可设置模式如: spark://host:port mesos://host:port...

     

    spark-submit [--options] <app jar | python file> [app arguments] 

    参数名称

    含义

    --master MASTER_URL

    可设置模式如:

    spark://host:port

    mesos://host:port

    yarn

    yarn-cluster

    yarn-client

    local

    --deploy-mode DEPLOY_MODE

    Driver程序运行的地方:client、cluster

    --class CLASS_NAME

    app主类名称,含包名

    --name NAME

    app名称

    --jars JARS

    Driver和Executor依赖的第三方jar包

    --properties-file FILE

    应用程序属性的文件路径,默认是conf/spark-defaults.conf

    --py-files PY_FILES放置在Python应用程序Python path上的.zip,  .egg, .py文件列表,用逗号分隔

    --supervise

    仅限于Spark  Alone模式,失败后是否重启Driver

      

     

    设置Driver

    --driver-cores NUM 

    Driver程序使用的CPU核数(只限于cluster),默认为1  

    --driver-memory MEM

    Driver程序使用内存大小

    --driver-library-path

    Driver程序的库路径

    --driver-class-path

    Driver程序的类路径

    --driver-java-options

     

     

    设置Executor

    --files FILES

    要放置在每个executor工作目录的文件列表,用逗号分隔

    --total-executor-cores所有executor的总核数

    --num-executors NUM

    仅限于Spark on Yarn模式,启动的executor的数量,默认为2

    --executor-cores NUM

    仅限于Spark on Yarn模式,每个executor使用的CPU核数,默认为1

    --executor-memory MEM

    每个executor内存大小,默认为1G

    --queue QUEUE_NAME

    仅限于Spark on Yarn模式,提交应用程序给哪个YARN的队列,默认是default队列

    --archives ARCHIVES

    仅限于Spark on Yarn模式

     

    如:

    spark-submit \
    --class com.sm.liujinhe.job.Idmapping \
    --master yarn \
    --deploy-mode client \
    --driver-memory 4G \
    --num-executors 30 \
    --executor-memory 6G \
    --executor-cores 3 \
    --conf spark.default.parallelism=180 \
    /liujinhe/jars/idmapping-1.0-SNAPSHOT.jar

     

    spark提交任务常见的两种模式:

    • local[k]:

    本地使用k个线程运行saprk程序,适合少量数据在本地调试代码。

    • Spark on yarn模式:

     yarn-client模式:以client模式连接到yarn集群,driver运行在client上。

     yarn-cluster模式:以cluster模式连接到yarn集群,driver运行在worker节点上。

     yarn-cluster适合生产环境,yarn-client适合交互和调试。

    展开全文
  • spark并行度设置及submit参数

    千次阅读 2020-04-10 21:12:06
    –spark submit –num-executors 该参数主要用于设置该应用总共需要多少executors来执行,Driver在向集群资源管理器申请资源时需要根据此参数决定分配的Executor个数,并尽量满足所需。在不带的情况下只会分配少量...

    –spark submit

    spark-submit --conf spark.default.parallelism=40 --num-executors 5 --executor-cores 4 --executor-memory 8G --master yarn --class com.xx.TopDiscount topnDiscount-1.0-SNAPSHOT.jar $1 $2

    spark-submit --conf spark.default.parallelism=12 --num-executors 3 --executor-cores 2 --executor-memory 2G --master yarn --class com.heroking.spark.WordCount spark-word-count.jar

    1.Spark的并行度指的是什么?
    spark作业中,各个stage的task的数量,也就代表了spark作业在各个阶段stage的并行度!
    当分配完所能分配的最大资源了,然后对应资源去调节程序的并行度,如果并行度没有与资源相匹配,那么导致你分配下去的资源都浪费掉了。同时并行运行,还可以让每个task要处理的数量变少(很简单的原理。合理设置并行度,可以充分利用集群资源,减少每个task处理数据量,而增加性能加快运行速度。)

    举例:
    假如, 现在已经在spark-submit 脚本里面,给我们的spark作业分配了足够多的资源,比如50个executor ,每个executor 有10G内存,每个executor有3个cpu core 。 基本已经达到了集群或者yarn队列的资源上限。
    task没有设置,或者设置的很少,比如就设置了,100个task 。 50个executor ,每个executor 有3个core ,也就是说
    Application 任何一个stage运行的时候,都有总数150个cpu core ,可以并行运行。但是,你现在只有100个task ,平均分配一下,每个executor 分配到2个task,ok,那么同时在运行的task,只有100个task,每个executor 只会并行运行 2个task。 每个executor 剩下的一个cpu core 就浪费掉了!你的资源,虽然分配充足了,但是问题是, 并行度没有与资源相匹配,导致你分配下去的资源都浪费掉了。合理的并行度的设置,应该要设置的足够大,大到可以完全合理的利用你的集群资源; 比如上面的例子,总共集群有150个cpu core ,可以并行运行150个task。那么你就应该将你的Application 的并行度,至少设置成150个,才能完全有效的利用你的集群资源,让150个task ,并行执行,而且task增加到150个以后,即可以同时并行运行,还可以让每个task要处理的数量变少; 比如总共 150G 的数据要处理, 如果是100个task ,每个task 要计算1.5G的数据。 现在增加到150个task,每个task只要处理1G数据。

    2.如何去提高并行度?
    1、task数量,至少设置成与spark Application 的总cpu core 数量相同(最理性情况,150个core,分配150task,一起运行,差不多同一时间运行完毕)官方推荐,task数量,设置成spark Application 总cpu core数量的2~3倍 ,比如150个cpu core ,基本设置 task数量为 300~ 500. 与理性情况不同的,有些task 会运行快一点,比如50s 就完了,有些task 可能会慢一点,要一分半才运行完,所以如果你的task数量,刚好设置的跟cpu core 数量相同,可能会导致资源的浪费,因为 比如150task ,10个先运行完了,剩余140个还在运行,但是这个时候,就有10个cpu core空闲出来了,导致浪费。如果设置2~3倍,那么一个task运行完以后,另外一个task马上补上来,尽量让cpu core不要空闲。同时尽量提升spark运行效率和速度。提升性能。

    2、如何设置一个Spark Application的并行度?

      spark.defalut.parallelism   默认是没有值的,如果设置了值比如说10,是在shuffle的过程才会起作用(val rdd2 = rdd1.reduceByKey(_+_) //rdd2的分区数就是10,rdd1的分区数不受这个参数的影响)
    
      new SparkConf().set(“spark.defalut.parallelism”,”“500)
    

    3、如果读取的数据在HDFS上,增加block数,默认情况下split与block是一对一的,而split又与RDD中的partition对应,所以增加了block数,也就提高了并行度。
    4、RDD.repartition,给RDD重新设置partition的数量
    5、reduceByKey的算子指定partition的数量
    val rdd2 = rdd1.reduceByKey(+,10) val rdd3 = rdd2.map.filter.reduceByKey(+)
    6、val rdd3 = rdd1.join(rdd2) rdd3里面partiiton的数量是由父RDD中最多的partition数量来决定,因此使用join算子的时候,增加父RDD中partition的数量。
    7、spark.sql.shuffle.partitions //spark sql中shuffle过程中partitions的数量

    –num-executors
    该参数主要用于设置该应用总共需要多少executors来执行,Driver在向集群资源管理器申请资源时需要根据此参数决定分配的Executor个数,并尽量满足所需。在不带的情况下只会分配少量Executor。这个值得设置还是要看分配的队列的资源情况,太少了无法充分利用集群资源,太多了则难以分配需要的资源。

    –executor-memory
    设置每个executor的内存,对Spark作业运行的性能影响很大。一般4-8G就差不多了,当然还要看资源队列的情况。num-executor*executor-memory的大小绝不能超过队列的内存总大小,保险起见不能超过队列总大小的2/3,因为还有一些调度任务或其它spark任务

    –executor-cores
    设置每个executor的cpu核数,其决定了每个executor并行执行task的能力。Executor的CPU core数量设置为2-4个即可。但要注意,num-executor*executor-cores也不能超过分配队列中cpu核数的大小,保险起见不能超过队列总大小的2/3,因为还有一些调度任务或其它spark任务。具体的核数的设置需要根据分配队列中资源统筹考虑,取得Executor,核数,及任务数的平衡。对于多任务共享的队列,更要注意不能将资源占满

    –driver-memory
    运行sparkContext的Driver所在所占用的内存,通常不必设置,设置的话1G就足够了,除非是需要使用collect之类算子经常需要将数据提取到driver中的情况。
    –total-executor-cores
    是所有executor总共使用的cpu核数 standalone default all cores,一般大公司的集群会有限制不会允许一个任务把资源都用完

    –conf

    –conf spark.default.parallelism
    此参数用于设置每个stage经TaskScheduler进行调度时生成task的数量,此参数未设置时将会根据读到的RDD的分区生成task,即根据源数据在hdfs中的分区数确定,若此分区数较小,则处理时只有少量task在处理,前述分配的executor中的core大部分无任务可干。通常可将此值设置为num-executors*executor-cores的2-3倍为宜,如果与其相近的话,则对于先完成task的core则无任务可干。2-3倍数量关系的话即不至于太零散,又可是的任务执行更均衡。!!个人建议配置该参数

    –conf spark.storage.memoryFraction
    参数说明:该参数用于设置RDD持久化数据在Executor内存中能占的比例,默认是0.6。也就是说,默认Executor 60%的内存,可以用来保存持久化的RDD数据。根据你选择的不同的持久化策略,如果内存不够时,可能数据就不会持久化,或者数据会写入磁盘。
    参数调优建议:如果Spark作业中,有较多的RDD持久化操作,该参数的值可以适当提高一些,保证持久化的数据能够容纳在内存中。避免内存不够缓存所有的数据,导致数据只能写入磁盘中,降低了性能。但是如果Spark作业中的shuffle类操作比较多,而持久化操作比较少,那么这个参数的值适当降低一些比较合适。此外,如果发现作业由于频繁的gc导致运行缓慢(通过spark web ui可以观察到作业的gc耗时),意味着task执行用户代码的内存不够用,那么同样建议调低这个参数的值。个人不太建议调该参数

    –conf spark.shuffle.memoryFraction
    参数说明:该参数用于设置shuffle过程中一个task拉取到上个stage的task的输出后,进行聚合操作时能够使用的Executor内存的比例,默认是0.2。也就是说,Executor默认只有20%的内存用来进行该操作。shuffle操作在进行聚合时,如果发现使用的内存超出了这个20%的限制,那么多余的数据就会溢写到磁盘文件中去,此时就会极大地降低性能。
    参数调优建议:如果Spark作业中的RDD持久化操作较少,shuffle操作较多时,建议降低持久化操作的内存占比,提高shuffle操作的内存占比比例,避免shuffle过程中数据过多时内存不够用,必须溢写到磁盘上,降低了性能。此外,如果发现作业由于频繁的gc导致运行缓慢,意味着task执行用户代码的内存不够用,那么同样建议调低这个参数的值。个人不太建议调该参数

    –conf spark.sql.codegen
    默认值为false,当它设置为true时,Spark SQL会把每条查询的语句在运行时编译为java的二进制代码。这有什么作用呢?它可以提高大型查询的性能,但是如果进行小规模的查询的时候反而会变慢,就是说直接用查询反而比将它编译成为java的二进制代码快。所以在优化这个选项的时候要视情况而定。
    这个选项可以让Spark SQL把每条查询语句在运行前编译为java二进制代码,由于生成了专门运行指定查询的代码,codegen可以让大型查询或者频繁重复的查询明显变快,然而在运行特别快(1-2秒)的即时查询语句时,codegen就可能增加额外的开销(将查询语句编译为java二进制文件)。codegen还是一个实验性的功能,但是在大型的或者重复运行的查询中使用codegen

    –conf spark.sql.inMemoryColumnStorage.compressed
    默认值为false 它的作用是自动对内存中的列式存储进行压缩

    –conf spark.sql.inMemoryColumnStorage.batchSize
    默认值为1000 这个参数代表的是列式缓存时的每个批处理的大小。如果将这个值调大可能会导致内存不够的异常,所以在设置这个的参数的时候得注意你的内存大小
    在缓存SchemaRDD(Row RDD)时,Spark SQL会安照这个选项设定的大小(默认为1000)把记录分组,然后分批次压缩。
    太小的批处理会导致压缩比过低,而太大的话,比如当每个批处理的数据超过内存所能容纳的大小时,也有可能引发问题。
    如果你表中的记录比价大(包含数百个字段或者包含像网页这样非常大的字符串字段),就可能需要调低批处理的大小来避免内存不够(OOM)的错误。如果不是在这样的场景下,默认的批处理 的大小是比较合适的,因为压缩超过1000条压缩记录时也基本无法获得更高的压缩比了。

    –conf spark.sql.parquet.compressed.codec
    默认值为snappy 这个参数代表使用哪种压缩编码器。可选的选项包括uncompressed/snappy/gzip/lzo uncompressed这个顾名思义就是不用压缩的意思

    –conf spark.speculation
    推测执行优化机制采用了典型的以空间换时间的优化策略,它同时启动多个相同task(备份任务)处理相同的数据块,哪个完成的早,则采用哪个task的结果,这样可防止拖后腿Task任务出现,进而提高作业计算速度,但是,这样却会占用更多的资源,在集群资源紧缺的情况下,设计合理的推测执行机制可在多用少量资源情况下,减少大作业的计算时间。
    检查逻辑代码中注释很明白,当成功的Task数超过总Task数的75%(可通过参数spark.speculation.quantile设置)时,再统计所有成功的Tasks的运行时间,得到一个中位数,用这个中位数乘以1.5(可通过参数spark.speculation.multiplier控制)得到运行时间门限,如果在运行的Tasks的运行时间超过这个门限,则对它启用推测。简单来说就是对那些拖慢整体进度的Tasks启用推测,以加速整个Stage的运行
    spark.speculation.interval 100毫秒 Spark经常检查要推测的任务。
    spark.speculation.multiplier 1.5 任务的速度比投机的中位数慢多少倍。
    spark.speculation.quantile 0.75 在为特定阶段启用推测之前必须完成的任务的分数。

    –conf spark.shuffle.consolidateFiles
    默认值:false
    参数说明:如果使用HashShuffleManager,该参数有效。如果设置为true,那么就会开启consolidate机制,会大幅度合并shuffle write的输出文件,对于shuffle read task数量特别多的情况下,这种方法可以极大地减少磁盘IO开销,提升性能。
    调优建议:如果的确不需要SortShuffleManager的排序机制,那么除了使用bypass机制,还可以尝试将spark.shffle.manager参数手动指定为hash,使用HashShuffleManager,同时开启consolidate机制。在实践中尝试过,发现其性能比开启了bypass机制的SortShuffleManager要高出10%~30%。

    –conf spark.shuffle.file.buffer
    默认值:32k
    参数说明:该参数用于设置shuffle write task的BufferedOutputStream的buffer缓冲大小。将数据写到磁盘文件之前,会先写入buffer缓冲中,待缓冲写满之后,才会溢写到磁盘。
    调优建议:如果作业可用的内存资源较为充足的话,可以适当增加这个参数的大小(比如64k,一定是成倍的增加),从而减少shuffle write过程中溢写磁盘文件的次数,也就可以减少磁盘IO次数,进而提升性能。在实践中发现,合理调节该参数,性能会有1%~5%的提升。

    –conf spark.reducer.maxSizeInFlight
    默认值:48m
    参数说明:该参数用于设置shuffle read task的buffer缓冲大小,而这个buffer缓冲决定了每次能够拉取多少数据。
    调优建议:如果作业可用的内存资源较为充足的话,可以适当增加这个参数的大小(比如96m),从而减少拉取数据的次数,也就可以减少网络传输的次数,进而提升性能。在实践中发现,合理调节该参数,性能会有1%~5%的提升。

    –conf spark.shuffle.io.maxRetries
    默认值:3
    参数说明:shuffle read task从shuffle write task所在节点拉取属于自己的数据时,如果因为网络异常导致拉取失败,是会自动进行重试的。该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功,就可能会导致作业执行失败。
    调优建议:对于那些包含了特别耗时的shuffle操作的作业,建议增加重试最大次数(比如60次),以避免由于JVM的full gc或者网络不稳定等因素导致的数据拉取失败。在实践中发现,对于针对超大数据量(数十亿~上百亿)的shuffle过程,调节该参数可以大幅度提升稳定性。
    shuffle file not find taskScheduler不负责重试task,由DAGScheduler负责重试stage

    –conf spark.shuffle.io.retryWait
    默认值:5s
    参数说明:具体解释同上,该参数代表了每次重试拉取数据的等待间隔,默认是5s。
    调优建议:建议加大间隔时长(比如60s),以增加shuffle操作的稳定性。

    –conf spark.shuffle.memoryFraction
    默认值:0.2
    参数说明:该参数代表了Executor内存中,分配给shuffle read task进行聚合操作的内存比例,默认是20%。
    调优建议:在资源参数调优中讲解过这个参数。如果内存充足,而且很少使用持久化操作,建议调高这个比例,给shuffle read的聚合操作更多内存,以避免由于内存不足导致聚合过程中频繁读写磁盘。在实践中发现,合理调节该参数可以将性能提升10%左右。

    –conf spark.shuffle.manager
    默认值:sort|hash
    参数说明:该参数用于设置ShuffleManager的类型。Spark 1.5以后,有三个可选项:hash、sort和tungsten-sort。HashShuffleManager是Spark 1.2以前的默认选项,但是Spark 1.2以及之后的版本默认都是SortShuffleManager了。tungsten-sort与sort类似,但是使用了tungsten计划中的堆外内存管理机制,内存使用效率更高。
    调优建议:由于SortShuffleManager默认会对数据进行排序,因此如果你的业务逻辑中需要该排序机制的话,则使用默认的SortShuffleManager就可以;而如果你的业务逻辑不需要对数据进行排序,那么建议参考后面的几个参数调优,通过bypass机制或优化的HashShuffleManager来避免排序操作,同时提供较好的磁盘读写性能。这里要注意的是,tungsten-sort要慎用,因为之前发现了一些相应的bug。

    –conf spark.shuffle.sort.bypassMergeThreshold
    默认值:200
    参数说明:当ShuffleManager为SortShuffleManager时,如果shuffle read task的数量小于这个阈值(默认是200),则shuffle write过程中不会进行排序操作,而是直接按照未经优化的HashShuffleManager的方式去写数据,但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件,并会创建单独的索引文件。
    调优建议:当你使用SortShuffleManager时,如果的确不需要排序操作,那么建议将这个参数调大一些,大于shuffle read task的数量。那么此时就会自动启用bypass机制,map-side就不会进行排序了,减少了排序的性能开销。但是这种方式下,依然会产生大量的磁盘文件,因此shuffle write性能有待提高。

    –conf spark.shuffle.consolidateFiles
    默认值:false
    参数说明:如果使用HashShuffleManager,该参数有效。如果设置为true,那么就会开启consolidate机制,会大幅度合并shuffle write的输出文件,对于shuffle read task数量特别多的情况下,这种方法可以极大地减少磁盘IO开销,提升性能。
    调优建议:如果的确不需要SortShuffleManager的排序机制,那么除了使用bypass机制,还可以尝试将spark.shffle.manager参数手动指定为hash,使用HashShuffleManager,同时开启consolidate机制。在实践中尝试过,发现其性能比开启了bypass机制的SortShuffleManager要高出10%~30%。

    展开全文
  • spark 关于spark-submit 参数调优策略

    千次阅读 2018-08-13 14:26:00
    --sparksubmit  --num-executors  该参数主要用于设置该应用总共需要多少executors来执行,Driver在向集群资源管理器申请资源时需要根据此参数决定分配的Executor个数,并尽量满足所需。在不带的情况下只会分配...

    --sparksubmit
       --num-executors  
            该参数主要用于设置该应用总共需要多少executors来执行,Driver在向集群资源管理器申请资源时需要根据此参数决定分配的Executor个数,并尽量满足所需。在不带的情况下只会分配少量Executor。这个值得设置还是要看分配的队列的资源情况,太少了无法充分利用集群资源,太多了则难以分配需要的资源。

       --executor-memory
            设置每个executor的内存,对Spark作业运行的性能影响很大。一般4-8G就差不多了,当然还要看资源队列的情况。num-executor*executor-memory的大小绝不能超过队列的内存总大小。

       --executor-cores
            设置每个executor的cpu核数,其决定了每个executor并行执行task的能力。Executor的CPU core数量设置为2-4个即可。弹药注意,num-executor*executor-cores也不能超过分配队列中cpu核数的大小。具体的核数的设置需要根据分配队列中资源统筹考虑,取得Executor,核数,及任务数的平衡。对于多任务共享的队列,更要注意不能将资源占满    

      --driver-memory
            运行sparkContext的Driver所在所占用的内存,通常不必设置,设置的话1G就足够了,除非是需要使用collect之类算子经常需要将数据提取到driver中的情况。
      --total-executor-cores    
            是所有executor总共使用的cpu核数 standalone default all cores

    --conf

     --conf spark.default.parallelism
            此参数用于设置每个stage经TaskScheduler进行调度时生成task的数量,此参数未设置时将会根据读到的RDD的分区生成task,即根据源数据在hdfs中的分区数确定,若此分区数较小,则处理时只有少量task在处理,前述分配的executor中的core大部分无任务可干。通常可将此值设置为num-executors*executor-cores的2-3倍为宜,如果与其相近的话,则对于先完成task的core则无任务可干。2-3倍数量关系的话即不至于太零散,又可是的任务执行更均衡。!!个人建议配置该参数      

        --conf spark.storage.memoryFraction
            参数说明:该参数用于设置RDD持久化数据在Executor内存中能占的比例,默认是0.6。也就是说,默认Executor 60%的内存,可以用来保存持久化的RDD数据。根据你选择的不同的持久化策略,如果内存不够时,可能数据就不会持久化,或者数据会写入磁盘。
            参数调优建议:如果Spark作业中,有较多的RDD持久化操作,该参数的值可以适当提高一些,保证持久化的数据能够容纳在内存中。避免内存不够缓存所有的数据,导致数据只能写入磁盘中,降低了性能。但是如果Spark作业中的shuffle类操作比较多,而持久化操作比较少,那么这个参数的值适当降低一些比较合适。此外,如果发现作业由于频繁的gc导致运行缓慢(通过spark web ui可以观察到作业的gc耗时),意味着task执行用户代码的内存不够用,那么同样建议调低这个参数的值。个人不太建议调该参数

        --conf spark.shuffle.memoryFraction
            参数说明:该参数用于设置shuffle过程中一个task拉取到上个stage的task的输出后,进行聚合操作时能够使用的Executor内存的比例,默认是0.2。也就是说,Executor默认只有20%的内存用来进行该操作。shuffle操作在进行聚合时,如果发现使用的内存超出了这个20%的限制,那么多余的数据就会溢写到磁盘文件中去,此时就会极大地降低性能。
            参数调优建议:如果Spark作业中的RDD持久化操作较少,shuffle操作较多时,建议降低持久化操作的内存占比,提高shuffle操作的内存占比比例,避免shuffle过程中数据过多时内存不够用,必须溢写到磁盘上,降低了性能。此外,如果发现作业由于频繁的gc导致运行缓慢,意味着task执行用户代码的内存不够用,那么同样建议调低这个参数的值。个人不太建议调该参数

        --conf spark.sql.codegen
            默认值为false,当它设置为true时,Spark SQL会把每条查询的语句在运行时编译为java的二进制代码。这有什么作用呢?它可以提高大型查询的性能,但是如果进行小规模的查询的时候反而会变慢,就是说直接用查询反而比将它编译成为java的二进制代码快。所以在优化这个选项的时候要视情况而定。
            这个选项可以让Spark SQL把每条查询语句在运行前编译为java二进制代码,由于生成了专门运行指定查询的代码,codegen可以让大型查询或者频繁重复的查询明显变快,然而在运行特别快(1-2秒)的即时查询语句时,codegen就可能增加额外的开销(将查询语句编译为java二进制文件)。codegen还是一个实验性的功能,但是在大型的或者重复运行的查询中使用codegen

        --conf spark.sql.inMemoryColumnStorage.compressed
            默认值为false 它的作用是自动对内存中的列式存储进行压缩

        --conf spark.sql.inMemoryColumnStorage.batchSize    
            默认值为1000 这个参数代表的是列式缓存时的每个批处理的大小。如果将这个值调大可能会导致内存不够的异常,所以在设置这个的参数的时候得注意你的内存大小
            在缓存SchemaRDD(Row RDD)时,Spark SQL会安照这个选项设定的大小(默认为1000)把记录分组,然后分批次压缩。
            太小的批处理会导致压缩比过低,而太大的话,比如当每个批处理的数据超过内存所能容纳的大小时,也有可能引发问题。
            如果你表中的记录比价大(包含数百个字段或者包含像网页这样非常大的字符串字段),就可能需要调低批处理的大小来避免内存不够(OOM)的错误。如果不是在这样的场景下,默认的批处理 的大小是比较合适的,因为压缩超过1000条压缩记录时也基本无法获得更高的压缩比了。

        --conf spark.sql.parquet.compressed.codec
            默认值为snappy 这个参数代表使用哪种压缩编码器。可选的选项包括uncompressed/snappy/gzip/lzo        uncompressed这个顾名思义就是不用压缩的意思

        --conf spark.speculation 
            推测执行优化机制采用了典型的以空间换时间的优化策略,它同时启动多个相同task(备份任务)处理相同的数据块,哪个完成的早,则采用哪个task的结果,这样可防止拖后腿Task任务出现,进而提高作业计算速度,但是,这样却会占用更多的资源,在集群资源紧缺的情况下,设计合理的推测执行机制可在多用少量资源情况下,减少大作业的计算时间。
            检查逻辑代码中注释很明白,当成功的Task数超过总Task数的75%(可通过参数spark.speculation.quantile设置)时,再统计所有成功的Tasks的运行时间,得到一个中位数,用这个中位数乘以1.5(可通过参数spark.speculation.multiplier控制)得到运行时间门限,如果在运行的Tasks的运行时间超过这个门限,则对它启用推测。简单来说就是对那些拖慢整体进度的Tasks启用推测,以加速整个Stage的运行
            spark.speculation.interval    100毫秒    Spark经常检查要推测的任务。
            spark.speculation.multiplier    1.5    任务的速度比投机的中位数慢多少倍。
            spark.speculation.quantile    0.75    在为特定阶段启用推测之前必须完成的任务的分数。
            
        --conf spark.shuffle.consolidateFiles
            默认值:false
            参数说明:如果使用HashShuffleManager,该参数有效。如果设置为true,那么就会开启consolidate机制,会大幅度合并shuffle write的输出文件,对于shuffle read task数量特别多的情况下,这种方法可以极大地减少磁盘IO开销,提升性能。
            调优建议:如果的确不需要SortShuffleManager的排序机制,那么除了使用bypass机制,还可以尝试将spark.shffle.manager参数手动指定为hash,使用HashShuffleManager,同时开启consolidate机制。在实践中尝试过,发现其性能比开启了bypass机制的SortShuffleManager要高出10%~30%。    

        --conf spark.shuffle.file.buffer    
            默认值:32k
            参数说明:该参数用于设置shuffle write task的BufferedOutputStream的buffer缓冲大小。将数据写到磁盘文件之前,会先写入buffer缓冲中,待缓冲写满之后,才会溢写到磁盘。
            调优建议:如果作业可用的内存资源较为充足的话,可以适当增加这个参数的大小(比如64k,一定是成倍的增加),从而减少shuffle write过程中溢写磁盘文件的次数,也就可以减少磁盘IO次数,进而提升性能。在实践中发现,合理调节该参数,性能会有1%~5%的提升。

        --conf spark.reducer.maxSizeInFlight
            默认值:48m
            参数说明:该参数用于设置shuffle read task的buffer缓冲大小,而这个buffer缓冲决定了每次能够拉取多少数据。
            调优建议:如果作业可用的内存资源较为充足的话,可以适当增加这个参数的大小(比如96m),从而减少拉取数据的次数,也就可以减少网络传输的次数,进而提升性能。在实践中发现,合理调节该参数,性能会有1%~5%的提升。

        --conf spark.shuffle.io.maxRetries
            默认值:3
            参数说明:shuffle read task从shuffle write task所在节点拉取属于自己的数据时,如果因为网络异常导致拉取失败,是会自动进行重试的。该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功,就可能会导致作业执行失败。
            调优建议:对于那些包含了特别耗时的shuffle操作的作业,建议增加重试最大次数(比如60次),以避免由于JVM的full gc或者网络不稳定等因素导致的数据拉取失败。在实践中发现,对于针对超大数据量(数十亿~上百亿)的shuffle过程,调节该参数可以大幅度提升稳定性。
            shuffle file not find    taskScheduler不负责重试task,由DAGScheduler负责重试stage

        --conf spark.shuffle.io.retryWait
            默认值:5s
            参数说明:具体解释同上,该参数代表了每次重试拉取数据的等待间隔,默认是5s。
            调优建议:建议加大间隔时长(比如60s),以增加shuffle操作的稳定性。

        --conf spark.shuffle.memoryFraction
            默认值:0.2
            参数说明:该参数代表了Executor内存中,分配给shuffle read task进行聚合操作的内存比例,默认是20%。
            调优建议:在资源参数调优中讲解过这个参数。如果内存充足,而且很少使用持久化操作,建议调高这个比例,给shuffle read的聚合操作更多内存,以避免由于内存不足导致聚合过程中频繁读写磁盘。在实践中发现,合理调节该参数可以将性能提升10%左右。    

        --conf spark.shuffle.manager
            默认值:sort|hash
            参数说明:该参数用于设置ShuffleManager的类型。Spark 1.5以后,有三个可选项:hash、sort和tungsten-sort。HashShuffleManager是Spark 1.2以前的默认选项,但是Spark 1.2以及之后的版本默认都是SortShuffleManager了。tungsten-sort与sort类似,但是使用了tungsten计划中的堆外内存管理机制,内存使用效率更高。
            调优建议:由于SortShuffleManager默认会对数据进行排序,因此如果你的业务逻辑中需要该排序机制的话,则使用默认的SortShuffleManager就可以;而如果你的业务逻辑不需要对数据进行排序,那么建议参考后面的几个参数调优,通过bypass机制或优化的HashShuffleManager来避免排序操作,同时提供较好的磁盘读写性能。这里要注意的是,tungsten-sort要慎用,因为之前发现了一些相应的bug。

        --conf spark.shuffle.sort.bypassMergeThreshold
            默认值:200
            参数说明:当ShuffleManager为SortShuffleManager时,如果shuffle read task的数量小于这个阈值(默认是200),则shuffle write过程中不会进行排序操作,而是直接按照未经优化的HashShuffleManager的方式去写数据,但是最后会将每个task产生的所有临时磁盘文件都合并成一个文件,并会创建单独的索引文件。
            调优建议:当你使用SortShuffleManager时,如果的确不需要排序操作,那么建议将这个参数调大一些,大于shuffle read task的数量。那么此时就会自动启用bypass机制,map-side就不会进行排序了,减少了排序的性能开销。但是这种方式下,依然会产生大量的磁盘文件,因此shuffle write性能有待提高。

        --conf spark.shuffle.consolidateFiles
            默认值:false
            参数说明:如果使用HashShuffleManager,该参数有效。如果设置为true,那么就会开启consolidate机制,会大幅度合并shuffle write的输出文件,对于shuffle read task数量特别多的情况下,这种方法可以极大地减少磁盘IO开销,提升性能。
            调优建议:如果的确不需要SortShuffleManager的排序机制,那么除了使用bypass机制,还可以尝试将spark.shffle.manager参数手动指定为hash,使用HashShuffleManager,同时开启consolidate机制。在实践中尝试过,发现其性能比开启了bypass机制的SortShuffleManager要高出10%~30%。                

    展开全文
  • spark-submit参数优化配置

    千次阅读 2017-09-13 00:01:22
    Spark的资源参数,基本都可以在spark-submit命令中作为参数设置。很多Spark初学者,通常不知道该设置哪些必要的参数,以及如何设置这些参数,最后就只能胡乱设置,甚至压根儿不设置。资源参数设置的不合理,
  • spark submit参数调优

    万次阅读 多人点赞 2016-12-01 14:27:23
    Spark的资源参数,基本都可以在spark-submit命令中作为参数设置。很多Spark初学者,通常不知道该设置哪些必要的参数,以及如何设置这些参数,最后就只能胡乱设置,甚至压根儿不设置。资源参数设置的不合理,可能会...
  • Spark-Submit参数设置说明

    千次阅读 2019-09-26 09:56:15
    可以看到总的资源没有超过集群的总资源,那么遵循这个原则,您还可以有很多种配置,如计算超大数据,可将executor-memory调大,参考如下参数: --master yarn-client --driver-memory 5g –-num-executors 8 --...
  • spark submit 参数解释说明及调优

    千次阅读 2018-05-30 10:34:58
    Usage: spark-submit [options] &lt;app jar | python file&gt; [app arguments]Usage: spark-submit --kill [submission ID] --master [spark://...]Usage: spark-submit --status [submission ID] --...
  • spark-submit 参数设置说明

    千次阅读 2018-08-01 09:27:25
    本章节将介绍如何在 E-MapReduce 场景下设置 spark-submit参数。 集群配置 软件配置 E-MapReduce 产品版本 1.1.0 Hadoop 2.6.0 Spark 1.6.0 硬件配置 Master 节点 8 核 ...
  • spark作业配置及spark-submit参数说明

    千次阅读 2018-11-20 19:27:54
    1.spark作业配置的三种方式 读取指定配置文件,默认为conf/spark-defaults.conf。 在程序中的SparkConf中指定,如conf.setAppName(“myspark”)。...可以在spark-submit中使用–verbos参数查看起作...
  • 如何合理设置spark-submit参数

    千次阅读 2018-01-24 15:40:05
    基础的一些参数: --executor-cores 2(每台机器核数) --num-executors 20 (executor 节点数,不要太多5-20,如果程序涉及数据交换较多,节点数过多会,大量shuffle write需要跨机器网络传输数据,影响实际执行...
  • 常用参数: --master 指定任务运行方式,可以是: spark://host:port, mesos://host:port, yarn, yarn-cluster,yarn-client, local --deploy-mode Driver程序运行的地方:client或者cluster,默认是client --...
  • spark submit参数及调试

    千次阅读 2018-03-15 13:27:33
    原文:http://www.cnblogs.com/haoyy/p/6893943.htmlspark submit参数介绍你可以通过spark-submit --help或者spark-shell --help来查看这些参数。使用格式: ./bin/spark-submit \ --class &lt;main-class&...
  • spark-submit传递参数有两种方式: –conf k1=v1 --conf k2=v2 cli args,在jar包后追加 详见官方文档: 2.解析 –conf方式解析: sparkContext.getConf.get("k1") cli args方式解析: parse(args.toList) .....
  • spark-submit 详细参数说明

    千次阅读 2019-05-12 18:58:02
    版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_29303759/article/details/82659185 ... 在spark命令行输入 ./bin/spark-submit --help 可以看到spark-sub...
  • Spark spark-submit 参数

    千次阅读 2017-12-06 20:52:02
    参数翻译 参数名 格式 参数说明 –master MASTER_URL spark://host:port, mesos://host:port, yarn, or local. –deploy-mode DEPLOY_MODE 是否在本地启动驱动程序(“client”) 或者 在集群内部的一个工作...
  • filepath=path+os.sep+fileitem args=[filepath,thu1,Words] newTask=executor.submit(lambdap:doFileParse(*p),args)
  • Spark-Submit提交参数详解

    万次阅读 2018-08-12 23:10:21
    通用可选参数:  --master  MASTER_URL, 可 以 是 spark://host:port, mesos://host:port, yarn, yarn-cluster,yarn-client, local --deploy-mode  DEPLOY_MODE, Driver 程序运行的地方,client 或者 cluster,...
  • spark submit 提交脚本的参数详解

    千次阅读 2019-08-02 17:18:52
    这里主要是有关spark的运行任务…一些常用的提交参数配置如下所示: 参数参数说明 - -master master 的地址,提交任务到哪里执行,例如 spark://host:port, yarn, local - -deploy-mode 在本地 (client...
  • spark-submit参数说明

    千次阅读 2018-12-07 14:16:45
    提交spark job时需要传入的参数说明 Usage: spark-submit [options] &lt;app jar | python file&gt; [app options]
  • 今天我们主要来说一下spark-submit的时候一些重要的参数的配置,和spark提交的两种模式;spark提交任务常见的两种模式: 1,local[k]:本地使用k个worker线程运行saprk程序.这种模式适合小批量数据在本地调试代码用.(若...
  • https://blog.csdn.net/weixin_38750084/article/details/104146054?utm_source=app
  • spark-submit参数files

    千次阅读 2016-12-28 17:26:52
    参考:http://blog.csdn.net/book_mmicky/article/details/25714545 –files FILES 用逗号隔开的要放置在每个executor工作目录的文件列表
  • spark-submit参数名称解析

    千次阅读 2017-01-23 23:37:51
    Usage: spark-submit [options] [app options] 参数名称 含义 --master MASTER_URL 可以是spark://host:port, mesos://host:port, yarn, yarn-cluster,yarn-client, local
  • 1 示范 spark-submit --master xxx demo.jar "arg1" "arg2" 运行的jar包和传参放在最后,就可以了 转载于:https://www.cnblogs.com/QuestionsZhang/p/10992967.html

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 255,854
精华内容 102,341
关键字:

submit参数