确定提交的spark计算任务在spark集群上的最佳分区数

在spark集群上，对于提交的spark计算任务设置合适的分区数可以极大的改善大数据的处理性能。分区数设置的太少会导致一个executor一次处理一个大容量数据块，分区数设置的太多，每个分片处理的数据量太少，在进行数据持久化时需要进行多次连接，对系统造成很大的压力，反而会降低大数据的处理性能。分区数与集群cpu核数有关。

需要明确如下一些概念：

• Spark worker节点是集群中执行大数据处理的机器节点。executors是worker节点上在cpu的一个核中运行的处理大数据计算任务的进程。executors由worker节点管理。所以numWorkerNodes <= numExecutors
• 一个partition对应一个task。一个task只能在一个cpu中执行。
• 一个executor可以并行执行多个task，具体取决于每一个executor中分配的核数即–executor-cores参数

根据经验原则最合适的分区数：
numPartitions = numWorkerNodes * numCpuCoresPerWorker
参考：https://stackoverflow.com/questions/39381041/determining-optimal-number-of-spark-partitions-based-on-workers-cores-and-dataf?r=SearchResults

另外并没有一个最合适的分区数设置，具体需要根据大数据的计算任务决定，取决于shuffle过程。假如无法确定正确分区数请尽可能多分区吧。
参考https://blog.cloudera.com/how-to-tune-your-apache-spark-jobs-part-2/

In fact, when in doubt, it’s almost always better to err on the side of a larger number of tasks (and thus partitions). This advice is in contrast to recommendations for MapReduce, which requires you to be more conservative with the number of tasks. The difference stems from the fact that MapReduce has a high startup overhead for tasks, while Spark does not.

需要注意：

• yarn集群，每个节点yarn.nodemanager.resource.memory-mb和yarn.nodemanager.resource.cpu-vcores数量要小于各节点cpu和内存数量。需要预留资源给os和hadoop守护进程。可以预留1核cpu和1GB内存。
• num-executors*executor-cores需要小于yarn集群可用cpu总核数(各节点yarn.nodemanager.resource.cpu-vcores的和)需要预留空间给Application Master。
• executor-memory计算原则：(各节点可用内存/num-executors)*0.93
  计算规则参考https://blog.cloudera.com/how-to-tune-your-apache-spark-jobs-part-2/