spark实际工作中，是怎么来根据任务量，判定需要多少资源的？

[西红小柿]

在提交作业时，怎么根据任务量，来判定需要多少core memory，有什么参考依据？

[tchqiq]

Spark的资源主要分为两点：memory，cpu core，涉及到的参数主要有以下6个： spark.executor.instances / —-num-executors 表示启动多少个executor来运行该作业。 spark.executor.cores / —executor.cores 在默认参数spark.task.cpus设置为1时，该参数的值表示在同一个executor里，最多允许多少个task可同时并发运行。 spark.driver.memory / —-driver-memory 表示驱动进程（Drive端）允许使用的内存空间 spark.executor.memory / —-executor-memory 表示每一个executor进程允许使用的内存空间 spark.shuffle.memoryFraction / —conf spark.shuffle.memoryFraction= 表示在shuffle阶段，用于聚合规约数据时，可使用Java堆内存的比例 spark.storage.memoryFraction / —conf spark.storage.memoryFraction= 表示用于spark缓存数据时，可使用Java堆内存的比例 1. spark.executor.cores && spark.executor.instances 在Spark on Yarn架构下，这两个值的乘积（spark.executor.cores * spark.executor.instances）决定了Spark App的并发度。 提高并发度，可以使集群同时执行更多的任务；因此当task数一定时，可减少轮询次数。 比如一个Stage有200个task，当并发度为50时，执行这个作业需要轮询4次；当并发度为100时，仅需要轮询2次。 对于并发度（参数乘积）的设置，需要结合队列资源，期望Spark App运行时间，及App每轮Stage的task数决定。 并发度 spark.executor.cores * spark.executor.instances 不可超过队列的最大分配cpu核数。当请求超过最大值，由于频繁的向集群申请资源，反而降低了App的执行效率。 在保证不影响其他App使用队列资源的前提下，可适当提高并发。但当task数量低于并发度，将存在一部分core空间，导致资源浪费。经验值： 当task数很大（千以上级别），建议可设置并发度为队列最大分配cpu核数的1/2或者1/3，避免影响其他作业。 当task数较小时，评估每个task执行时间，在期望运行时间内，可降低并发度，增加轮询次数，减少资源使用。 在并发度过低的情况下，由于同一个executor要处理的task过多，容易造成shuffle阶段reduce过多从同一个executor拉取数据，造成节点响应延时，甚至引发节点失去连接的问题，使得App运行失败。 在保证相同并发量，和内存充足的情况下，可根据作业类型调整core和instance的分配: 作业为IO密集型：若core值较大，容易引起同一个executor的网络IO负载过重，因此建议将core调小； 作业存在大量静态对象，或使用boardcast变量广播数据：由于task序列化及boardcast的分发粒度为executor，且分发过程类似于pipeline的方式，若core值较大，同样的并发下，executor instance减少，则减少分发次数，一定程度上减少task调度执行的时间（申请减少executor，即资源申请，有利于加快task的调度），因此建议将core调大，但最大core值应该小于8：Spark on Yarn：内存分布# 2. spark.driver.memory 美团没有单独的spark集群，spark部署在Yarn之上。因此提及driver.memory参数，不得不提到的spark on Yarn的两种模式： yarn-cluster: 适合运行在生产环境。Spark Driver运行在由Yarn管理的AppMaster进程中，由AM负责将集群申请资源，并监督作业运行状态。Client在完成作业的提交后，并可关掉，不影响作业在集群的运行。Client日志仅显示Job的运行状况，没有详细日志。 yarn-client: 适合交互和调试。在此模式下，Spark Driver运行在Client端，负责与运行executor的container通信，而AppMaster仅负责向集群申请资源。Client端Spark-submit进程被kill，则运行在集群上的作业将被kill。 使用yarn-cluster模式运行，程序代码中应该避免使用collect、take、show等将执行结果返回drive的API，这些结果将打印在driver的日志，本地Client也不可见。所以，此模式下，driver仅用于作业的提交，spark默认配置driver memory 为512M。下图为cluster模式下，driver的资源使用情况(配额10G)： 使用yarn-client模式运行，若强需直接看到application返回到driver端的输出，一般不建议使用。此模式下，driver memory主要受返回数据大小的影响，视作业具体情况而定。下图为client模式下，driver的资源使用情况(配额10G，无结果返回driver操作)： 3. spark.executor.memory, spark.shuffle.memoryFraction, spark.storage.memoryFraction 介绍这三个参数前，请先了解下spark memory分配： executor 内存由两部分组成：executor.memoryOverhead，executor.memory executor.memoryOverhead：类似于Java non-heap，用于存储已被加载的类信息、常量、静态变量等数据 executor.memory：container分配给executor使用的内存，其大小可认为等于spark.executor.memory设置的值（一般略小于） 该部分有三部分组成：用于shuffle阶段缓存拉取到的数据所使用的内存空间（shuffle.memoryFraction），缓存数据所使用的空间（storage.memoryFraction），用于Java堆栈的空间。 此三部分的配置可以依据Spark Web UI的监控数据作为参考。 Spark History Web UI => Executors： Shuffle Read: 对应spark.shuffle.memoryFraction，基于此列的降序排列，可设置shuffle.memoryFraction所占空间的大小略大于最大值，或者90%左右executor的取值（此时，可能由于数据倾斜导致TopN的空间过于极端，且比例很小，取值视实际而定） Storage Memory: 对应spark.storage.memoryFraction，若资源允许可设置storage.memoryFraction所占空间的大小略大于最大值，或略大于某一百分比的数据存储占用的空间，同时将storage_level设置为MEMORY_AND_DISK或MEMORY_SER。 Spark History Web Ui => Stages => Stage： executor.memory用于Java堆栈的空间，并不能通过监控信息进行估算，唯一反应到该空间使用情况的仅有 GC Time 基于GC Time，推测Java堆栈空间大小是否能够满足要求。 可以通过调整spark.executor.memory, spark.shuffle.memoryFraction, spark.storage.memoryFraction三个参数来优化JVM堆栈使用。

[西红小柿]

经验值： 当task数很大（千以上级别），建议可设置并发度为队列最大分配cpu核数的1/2或者1/3，避免影响其他作业。 当task数较小时，评估每个task执行时间，在期望运行时间内，可降低并发度，增加轮询次数，减少资源使用。 这点是怎么确定task的数量的多少啊？

[tchqiq]

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左右比较合适，也是避免影响其他同学的作业运行。

[shiter]

Executor的CPU core数量设置为4，每个memory 4g