spark thrift server configuration

# MainApplicationProperties
# --master yarn --deploy-mode client 下的配置, client 模式表示,driver 是在本地机器上跑的,thrift server 设置就是 client 模式,这样会方便从 driver 中拿数
# spark job 临时保存的目录
spark.local.dir                     /tmp
# spark YARN Application Master 申请的内存,这个中会保存查询返回的数据,所以设置的大一些比较好。
# dw02 因为本身内存比较小,所以这里设置4G
spark.yarn.am.memory                12g
# YARN Application Master 设置的核数,默认是1,但是不够用,在处理 broad cast 变量时候会出问题,这里设置为5.
spark.yarn.am.cores       5
#spark.kryoserializer.buffer.max     1024m
#spark.master                          spark://10.62.34.223:7077

# --master yarn --deploy-mode cluster 下的配置
# 对应 YARN Application Master 申请的 core
spark.driver.cores    3
# 对应 YARN Application Master 申请的 memory, 注意这个和 yarn container 分配的最小内存有关, container 如果是 8G, 这里设置为4G, 实际分配也是 8G
spark.driver.memory     12g
# 返回结果的最大容量,如果这里超出了 driver memory 或者 jvm 的设置,就会 OOM
spark.driver.maxResultSize    10g

# Shuffle Behavior
# 影响一个Spark Job 的主要因素还是 代码开发, 资源参数, 以及数据倾斜, shuffle调优只能在整个 Spark 性能调优中占到一小部分
# shuffle 开启压缩
spark.shuffle.compress                             true
# 该参数用于设置shuffle write task的BufferedOutputStream的buffer缓冲大小。将数据写到磁盘文件之前,会先写入buffer缓冲中,待缓冲写满之后,才会溢写到磁盘。
spark.shuffle.file.buffer                         64k
# 开启 External Shuffle Service ,避免 Executor 任务过重挂掉
spark.shuffle.service.enabled                     true
# shuffle 的 port
spark.shuffle.service.port                         7337
# 在 分割文件的时候 压缩数据
spark.shuffle.spill.compress                     true
# shuffle read task从shuffle write task所在节点拉取属于自己的数据时,如果因为网络异常导致拉取失败,是会自动进行重试的。该参数就代表了可以重试的最大次数。如果在指定次数之内拉取还是没有成功,就可能会导致作业执行失败。
spark.shuffle.io.maxRetries                       10
# retry 的重试时间
spark.shuffle.io.retryWait                       30s

# Compression
# 数据传输过程中进行序列化
spark.serializer                                org.apache.spark.serializer.KryoSerializer

# Spark UI,
# 每个Job的监控
spark.ui.enabled             true
spark.ui.port                 4040
spark.ui.killEnabled         true

# Execution Behavior
# 每个 Executor 申请的最小内存, 对应 YARN 的最小内存 8G, 这里就算比8G 小,申请下来的内存还是8G
spark.executor.memory                 8G
# 每个 Executor 的核数,默认为 1, 实际上为1 是不够用的,如果计算量大,就会失去响应,这里设置为2,如果还是出现没有响应,继续调大
spark.executor.cores                 2

# Scheduling
# FIFO 的资源分配模式
spark.scheduler.mode                              FIFO

# 开启预测, spark 会计算每个 task 跑的时间,如果某个 task 跑的太慢了,超出了预期,就会再启动一个相同的 task,看谁先跑完,谁先跑完,就用谁的计算结果。
# 如果出现 Lost task 239.0 in stage 144.0 (TID 398794, sha2hdpw17, executor 761): TaskKilled (another attempt succeeded), 就代表这个 task 因为计算时间太长被干掉了。
spark.speculation                                true
# 执行间隔
spark.speculation.interval                        1000ms
# 任务完成
spark.speculation.quantile                        0.8
# 比其他的慢多少倍时启动推测, 设置为2 的时候,有太多的task 被 retry 了, 如果到 5 了还没跑完,可能是真的有问题了,当然也有可能是某个task 执行很复杂的计算。
# 总之,开启推测后,日志中不要经常出现 kill 信息,如果太经常了,说明设置的不好, 加大倍数,或者彻底关闭
spark.speculation.multiplier                    5

#Others
# 开启动态分配,如果 job 需要的资源多,会自动向 yarn 申请资源
# 注意啊,使用 spark streaming 最好不要开这个。
spark.dynamicAllocation.enabled                       true
# 动态分配,最小的 executors 个数
spark.dynamicAllocation.minExecutors                  3
# 最大分为 executors 个数
spark.dynamicAllocation.maxExecutors                  600
# 如果有 task 等待的时间超过了1S,就会申请资源
spark.dynamicAllocation.schedulerBacklogTimeout     1s
# 如果有 executor 超过 30s 没有被使用,就干掉
spark.dynamicAllocation.executorIdleTimeout          30s

# Spark Sql shuffle task 的并行度
spark.sql.shuffle.partitions                        400

# 增加 broadcast time out 的时间,默认是 300s,但是我们有的 broadcast join 会超过这个事件,这个时候任务就会失败
spark.sql.broadcastTimeout    6000
# 增加窗口文件的大小,避免产生过多的小文件
spark.sql.windowExec.buffer.spill.threshold 1500000
# spark 默认的通信时间是120s, 有的时候会出现超时,这里调增为300s
spark.network.timeout 300s
#AppName
#yarn 上指定队列的名字,注意不同的机器需要修改
spark.yarn.queue spark_123
    原文作者:spark
    原文地址: https://www.cnblogs.com/SpeakSoftlyLove/p/8005993.html
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞