spark如何合理的分配资源（executor-memory,num-executors,executor-cores）

以下为经验之谈，结合个人对spark框架的理解，如有错误，欢迎指正。

以yarn为例：

一。executor-memory，在集群资源允许的情况下，且不oom的情况下，通常越多越好，同时要在webui观察gc时长，达到平衡值(过多的内存会导致单次gc所需时间过长，过少的内存会导致频繁gc)，个人建议上限为单个containers最大值的75%。

二。num-executors和executor-cores，由于执行任务的并发数=num-executors * executor-cores 。所以这一点经常会思考是100*1好，还是50*2比较好。

1.假设shuffer压力不大，

①在数据分布均匀，executor-memory=8G，100*1是比50*2的理论上是要好些的，因为这样单个任务所拥有的内存会更充足，gc的次数会更少。

②在数据分布不均匀的情况下，可设置executor-memory=16G，50*2理论上是比100*1效果要好些的，因为如果设置为100*1，数据量小的任务会很快执行完，造成executor空闲。资源浪费。且在数据不均匀的情况下，executor-memory要适当提高，以免oom

2.若shuffer有一定压力。

shuffer的本质是在网络磁盘IO，假设每个executor都分布在不同的节点，那么过多的executor-num会造成网络之间的IO过大，shuffer read可能造成timeout。所以这个时候理论上是设置较小的executor-num,较多的executor-cores，和较大的executor-memory是比较合理。以上文为例： executor-memory=32G num-executors=25 executor-cores =4

3.若任务主要是sc.textFile().map().saveAsTextFile。那么其瓶颈主要是在读取hdfs文件，以及业务代码运行效率上。在单个节点给予过多的executor-cores，可能造成节点和hdfs的IO打满。那么这个时候应该适当降低executor-cores，增加executor-num。

三。

总之，调参的本质是要思考任务的瓶颈在哪里，因为所有的参数到最后基本上都是内存，磁盘IO，网络IO这些东西。除此之外，spark的其他参数，如 spark shuffer调优 这一系列的参数，也是需要参考调整的