在大数据处理时候，基于MapReduce的思想，通常是分而治之，将数据分割，然后并行处理，这样每一个executor只需要处理自己所负责的那一部分数据即可，这样各个
executor就可以同处理一小部分工作，加快大数据处理，这一切看上去很美好，但是不可 避免的存在极端情况下，数据在各个executor上分布不均，导致个别executor
数据远大于其他节点，导致executor负载不均衡，从而拖慢整体处理进度，严重情况下很可能平时几分钟就可以完成的任务导致最终几个小时也没有出结果甚至OOM错误。
因此数据倾斜的处理很关键，。
RDD在计算的时候，每个分区都会起一个task，所以rdd的分区数目决定了总的的task数目。申请的计算节点（Executor）数目和每个计算节点核数，决定了你同一时刻可以并行执行的task。比如的RDD有100个分区，那么计算的时候就会生成100个task，你的资源配置为10个计算节点，每个两2个核，同一时刻可以并行的task数目为20，计算这个RDD就需要5个轮次。如果计算资源不变，你有101个task的话，就需要6个轮次，在最后一轮中，只有一个task在执行，其余核都在空转。如果资源不变，你的RDD只有2个分区，那么同一时刻只有2个task运行，其余18个核空转，造成资源浪费。这就是在spark调优中，增大RDD分区数目，增大任务并行度的做法。
1.在partition总数目大于Executor数目 * 每个Executor核数的情况下是这样。如果只有1个partition并发就只能是1了，只有一个executor的一个core在执行，剩下的就会闲置。”即使只有一个Executor， 但 这个node上有 100 core， 那么就可以并行100 partition”。
2. 实际场景，数据一般是存在hdfs上的，而不会放在单台机器上。getSplits阶段只是做partition的划分，真正处理数据时还是集群的机器去hdfs上取数据。
3. 每个executor的core数目通过spark.executor.cores参数设置。这里的cores其实是指的工作线程。cpu info里看到的核数是物理核(或者一般机器开了超线程以后是的物理核数*2)，和spark里的core不是一个概念，但是一般来说spark作业配置的executor核数不应该超过机器的物理核数。
