【Spark2运算效率】第二节影响生产集群运算效率之集群设置

最新推荐文章于 2020-12-31 11:52:20 发布

Jack_Roy

最新推荐文章于 2020-12-31 11:52:20 发布

阅读量1.5w

点赞数 22

分类专栏： Spark 文章标签： spark

本文链接：https://blog.csdn.net/Jack_Roy/article/details/104272313

版权

Spark 专栏收录该内容

15 篇文章 1 订阅

订阅专栏

【Spark2运算效率】第二节影响生产集群运算效率之集群设置

前言

相较于Spark任务submit时的一些参数指定，作为资源调度框架的yarn，以及底层支撑或作为接口对接的hive与其他hadoop生态组件，它们的一些硬性指标的设置影响着任务提交后的资源申请模式及运行模式。
因此，在优化我们集群的运算效率时，第一步就是将底层相关指标调整到位，下面就相关参数，给出相应的讲解。

IO（磁盘IO及网络IO）

就论HDFS本身而言，它往往承载着整个数仓的数据，因此节点底层的磁盘IO和节点间的网络IO很是影响数据传输的速度。对于磁盘本身来说，采用多盘、多分区的方式总是能够提升机器的数据瞬时吞吐量。
而对于网络IO来说，千兆网和万兆网的区别对于JOB本身的运行效率的影响是很直观的，此前博主曾深有这方面的感触，由20个节点采用超线程40核、256G、3T的机器在万兆网环境中，处理TB级别的表尚能达到我们期望的速率（正常按1G数据1千万条，一张ITB的表就是一百亿条），但之后博主在由12个节点采用超线程40核、256G、2T的机器在千兆网环境中，处理100G级别的数据竟比万兆网环境中TB级别的数据来的卡顿。
这里的卡顿主要体现在stage之间传输数据时，由于跨节点需要走网络IO，因此速率大打折扣。单论计算速率的话，同样的配置又缩小一个量级的数据，20个节点当然是比12个节点快的，但网络IO这里也是缩小了一个量级，因此整体上看，网络IO的影响是甚大的。

yarn.nodemanager.resource.memory-mb

参数说明：默认8192MB，该参数指定单节点上可供yarn分配的最大可用内存（如果是异构集群这里是需要设定多个模板的，，最好不要超过我们实际拥有的内存）；
设定建议：应该在不影响宿主机文件系统的情况下，尽可能的将资源分配出去，拿256G40核的配置来说，博主将220G38核分配给了yarn，宿主机文件系统能够稳定运行

yarn.nodemanager.resource.cpu-vcores

参数说明：单个节点可用虚拟CPU个数（如果是异构集群这里是需要设定多个模板的，最好不要超过我们实际拥有的核）；
设定建议：拿256G40核的配置来说，博主将38核分配出去，留了两个核给文件系统，妥妥的够了。

yarn.nodemanager.vmem-pmem-ratio

参数说明：虚拟内存和真实物理内存的比率
设定建议：默认是2.1，该数值不能太小，因为yarn在监控 Container的虚拟内存使用情况时，一旦发现虚拟内存超过Container物理内存*该比率的大小，便会杀死进程，如果在处理大批次数据时，stage中的task频频失败导致任务终止，可尝试调大该数值，以排除是Container的虚拟内存超出限制，yarn主动kill线程的可能（以0.3为单位往上调试，一般3左右较安全。）

yarn.scheduler.minimum-allocation-mb

参数说明：分别为ApplicationMaster可向yarn申请的容器最小内存
设定建议：这里介绍一下博主的设置，拿220G38核举例，最小容器内存设定为220/38/2取整为2G。

yarn.scheduler.maximum-allocation-mb

参数说明：分别为ApplicationMaster可向yarn申请的容器最大内存
设定建议：这里介绍一下博主的设置，拿220G38核举例，最大内存为220/38*6取整为24G。

yarn.scheduler.maximum-allocation-vcores

参数说明：分别为ApplicationMaster可向yarn申请的容器最小虚拟核数
设定建议：拿220G38核举例，最小核数为1

yarn.scheduler.minimum-allocation-vcores

参数说明：分别为ApplicationMaster可向yarn申请的容器最大虚拟核数
设定建议：拿220G38核举例，最大核数为6（前面设置的Container最大内存为24G，这里24G/6*38(单台机器的虚拟核)≈220（单台机器的可用内存），可是在实际操作过程中，我们总要将数值设定的小一点，因为每个container所使用的实际内存总是要超出我们设定的值）

结语

这里贴一个提交脚本的submit命令供各位参考:

spark2-submit --driver-memory 16G --executor-memory 14G --driver-cores 1 --executor-cores 4 --num-executors 60 --conf spark.scheduler.listenerbus.eventqueue.size=100000 --conf spark.executor.extraJavaOptions="-XX:+PrintGCDetails -XX:+PrintGCTimeStamps" --conf spark.sql.shuffle.partitions=400  --conf spark.memory.useLegacyMode=false --conf spark.memory.fraction=0.8 --conf spark.memory.storageFraction=0.6 --conf spark.dynamicAllocation.maxExecutors=100 --master yarn --deploy-mode client --name /data/bdetl/adm/sql/a_fact_sharechg_kulebin  /data/bdetl/tmp/amtec/amtec-pl/breakeven/BreakEvenMain.py

如有疑问可流言交流。