sparksql参数

全局参数：

1. --master yarn-cluster (or yarn-client)

参数说明：

制定yarn的执行模式，分集群模式和客户端模式，通常使用集群模式

2. --num-executors 50

参数说明：
　　该参数用于设置Spark做业总共要用多少个Executor进程来执行。Driver在向YARN集群管理器申请资源时，YARN集群管理器会尽量按照你的设置来在集群的各个工做节点上，启动相应数量的Executor进程。这个参数很是之重要，若是不设置的话，默认只会给你启动少许的Executor进程，此时你的Spark做业的运行速度是很是慢的。
参数调优建议：
　　每一个Spark做业的运行通常设置20~50个左右的Executor进程比较合适，设置太少或太多的Executor进程都很差。设置的太少，没法充分利用集群资源；设置的太多的话，大部分队列可能没法给予充分的资源。

3.--executor-memory 6G

参数说明：
　　该参数用于设置每一个Executor进程的内存。Executor内存的大小，不少时候直接决定了Spark做业的性能，并且跟常见的JVM OOM异常，也有直接的关联。
参数调优建议：
　　每一个Executor进程的内存设置4G~8G较为合适,最大不超过 20G，不然会致使 GC 代价太高，或资源浪费严重。可是这只是一个参考值，具体的设置仍是得根据不一样部门的资源队列来定。能够看看本身团队的资源队列的最大内存限制是多少，num-executors乘以executor-memory，是不能超过队列的最大内存量的。此外，若是你是跟团队里其余人共享这个资源队列，那么申请的内存量最好不要超过资源队列最大总内存的1/3~1/2，避免你本身的Spark做业占用了队列全部的资源，致使别的同窗的做业没法运行

4.--conf spark.executor.cores=4

参数说明：
    该参数用于设置每一个Executor进程的CPU core数量。这个参数决定了每一个Executor进程并行执行task线程的能力。由于每一个CPU core同一时间只能执行一个task线程，所以每一个Executor进程的CPU core数量越多，越可以快速地执行完分配给本身的全部task线程。
参数调优建议：
    Executor的CPU executor_cores 不宜为1！不然 work 进程中线程数过少，通常 2~4 为宜。。一样得根据不一样部门的资源队列来定，能够看看本身的资源队列的最大CPU core限制是多少，再依据设置的Executor数量，来决定每一个Executor进程能够分配到几个CPU core。一样建议，若是是跟他人共享这个队列，那么num-executors * executor-cores不要超过队列总CPU core的1/3~1/2左右比较合适，也是避免影响其余同窗的做业运行。

5.--conf spark.yarn.executor.memoryOverhead=2048

Ececutor堆外内存 
当Spark处理超大数据量时(数十亿,百亿级别),executor的堆外内存可能会不够用,出现shuffle file can’t find, task lost,OOM等状况 
默认状况下,这个堆外内存是300M,当运行超大数据量时,一般会出现问题,所以须要调节到1G,2G,4G等大小 
调节方法必须在spark-submit提交脚本中设置而不能在程序中设置

6.--driver-memory 2G

参数说明：
    该参数用于设置Driver进程的内存。
参数调优建议：
    Driver的内存一般来讲不设置，或者设置2G左右应该就够了。惟一须要注意的一点是，若是须要使用collect算子将RDD的数据所有拉取到Driver上进行处理，那么必须确保Driver的内存足够大，不然会出现OOM内存溢出、GC FULL等问题。

7.--conf spark.default.parallelism=150

参数说明：
　　spark_parallelism通常为executor_cores*num_executors 的 1~4 倍，系统默认值 64，不设置的话会致使 task 不少的时候被分批串行执行，或大量 cores 空闲，资源浪费严重

8.动态executor    --避免使用

--conf spark.dynamicAllocation.enable=true //打开动态executor模式
--conf spark.shuffle.service.enabled=true //动态executor须要的服务，须要和上面的spark.dynamicAllocation.enable同时打开或关闭

9.--conf spark.storage.memoryFraction=0.2

参数说明：
　　该参数用于设置RDD持久化数据在Executor内存中能占的比例，默认是0.6。也就是说，默认Executor 60%的内存，能够用来保存持久化的RDD数据。

10.exector、storage内存分配

当Spark一个JOB被提交，就会开辟内存空间来存储和计算
Spark中执行计算和数据存储都是共享同一个内存区域（M），spark.memory.fraction 表示M的大小，其值为相对于JVM堆内存的比例（默认0.6）。剩余的40%是为其余用户数据结构、Spark内部元数据以及避免OOM错误的安全预留空间（大量稀疏数据和异常大的数据记录）。

spark.memory.storageFraction 表示数据存储比例（R）的大小，其值为相对于M的一个比例（默认0.5）。R是M中专门用于缓存数据块，且这部分数据块永远不会因执行计算任务而逐出内存。
因此当发生FULL GC以后，有两种办法：
第一就是增大M区域，也就是增长--executor-memory 10G
这样至关于增大了new generation区和old generation区，能放得下大数据块

第二就是减少R区域，也就是减少-- spark.memory.storageFraction
这样至关于增大了内存中用于计算的区域，从而避免FULL GC的问题

spark.memory.fraction这个参数建议保持默认值，非特殊状况不要修改。

 

shuffle参数：

 1.--conf spark.shuffle.memoryFraction=0.5

参数说明：
    该参数用于设置shuffle过程当中一个task拉取到上个stage的task的输出后，进行聚合操做时可以使用的Executor内存的比例，默认是0.2。

　　　　也就是说，Executor默认只有20%的内存用来进行该操做。shuffle操做在进行聚合时，若是发现使用的内存超出了这个20%的限制，那么多余的数据就会溢写到磁盘文件中去，此时就会极大地下降性能。
参数调优建议：

　　若是Spark做业中的RDD持久化操做较少，shuffle操做较多时，建议下降持久化操做的内存占比，提升shuffle操做的内存占比比例，避免shuffle过程当中数据过多时内存不够用，必须溢写到磁盘上，下降了性能。此外，若是发现做业因为频繁的gc致使运行缓慢，意味着task执行用户代码的内存不够用，那么一样建议调低这个参数的值。

按实际状况设置这个参数，可是不推荐超过0.6 

2.--conf spark.sql.shuffle.partitions=20

默认值：300
spark中有partition的概念，每一个partition都会对应一个task，task越多，在处理大规模数据的时候，就会越有效率。不过task并非越多越好，若是发现数据量没有那么大，则没有必要task数量太多。
其实这个参数至关于Hive参数mapred.reduce.tasks，那种大促期间数据量翻好几倍的任务不推荐写死这个参数，不然会形成单个task处理的数据量激增致使任务失败或者阻塞。

3.--conf spark.shuffle.compress=true   //shuffle过程是否压缩

4.--conf spark.shuffle.file.buffer=512

默认值：32k
参数说明：
　　该参数用于设置shuffle write task的BufferedOutputStream的buffer缓冲大小。将数据写到磁盘文件以前，会先写入buffer缓冲中，待缓冲写满以后，才会溢写到磁盘。
调优建议：
　　若是做业可用的内存资源较为充足的话，能够适当增长这个参数的大小（好比64k），从而减小shuffle write过程当中溢写磁盘文件的次数，也就能够减小磁盘IO次数，进而提高性能。在实践中发现，合理调节该参数，性能会有1%~5%的提高。

5.--conf spark.reducer.maxSizeInFlight=256m

默认值：48m
参数说明：
　　该参数用于设置shuffle read task的buffer缓冲大小，而这个buffer缓冲决定了每次可以拉取多少数据。
调优建议：
　　若是做业可用的内存资源较为充足的话，能够适当增长这个参数的大小（好比96m），从而减小拉取数据的次数，也就能够减小网络传输的次数，进而提高性能。在实践中发现，合理调节该参数，性能会有1%~5%的提高。

6.--conf spark.shuffle.io.maxRetries=20

默认值：3
参数说明：
　　shuffle read task从shuffle write task所在节点拉取属于本身的数据时，若是由于网络异常致使拉取失败，是会自动进行重试的。该参数就表明了能够重试的最大次数。若是在指定次数以内拉取仍是没有成功，就可能会致使做业执行失败。
调优建议：
　　对于那些包含了特别耗时的shuffle操做的做业，建议增长重试最大次数（好比60次），以免因为JVM的full gc或者网络不稳定等因素致使的数据拉取失败。在实践中发现，对于针对超大数据量（数十亿~上百亿）的shuffle过程，调节该参数能够大幅度提高稳定性。

7.--spark.shuffle.io.retryWait=5s

默认值：5s
参数说明：
　　具体解释同上，该参数表明了每次重试拉取数据的等待间隔，默认是5s。调优建议：建议加大间隔时长（好比60s），以增长shuffle操做的稳定性。

动态分配

 1.reducer的可伸缩化

--spark.sql.adaptive.enabled=true
--spark.sql.adaptive.shuffle.targetPostShuffleInputSize=102400000

2.JOIN过程动态广播

--spark.sql.autoBroadcastJoinThreshold=10485760  //(10 MB)

相似Hive中的mapjoin，在join的过程当中把小于10M的小表广播到全部节点，从而进行Hashjoin，提高join的效率。

目前动态分配在处理几十亿以上的数据量时仍是有不少未知bug缺陷，使用需谨慎