executor-memory
在集群資源允許的情況下，且不oom的情況下，通常越多越好，同時要在webui觀察gc時長，達到平衡值(過多的內存會導致單次gc所需時間過長，過少的內存會導致頻繁gc)，個人建議上限為單個containers最大值的75%。
num-executors,executor-cores
num-executors和executor-cores，由於執行任務的並發數=num-executors * executor-cores 。所以這一點經常會思考是100*1好，還是50*2比較好？
1.假設shuffer壓力不大
（1）在數據分布均勻，executor-memory=8G，100*1是比50*2的理論上是要好些的，因為這樣單個任務所擁有的內存會更充足，gc的次數會更少。
（2）在數據分布不均勻的情況下，可設置executor-memory=16G，50*2理論上是比100*1效果要好些的，因為如果設置為100*1，數據量小的任務會很快執行完，造成executor空閑。資源浪費。且在數據不均勻的情況下，executor-memory要適當提高，以免oom。
2.若shuffer有一定壓力
（1）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。