拉姆提供的答案是正确的，我只是想再解释一下为什么你应该像他说的那样做。
当您运行spark作业时，您将拥有n x m个线程，这些线程能够基于physcal计划对分区数据执行查询。现在每个线程在一个时间点上计算一个分区上的任务。
如果您总共有10个执行器，每个执行器有2个内核，那么您将有20个线程，这意味着20个任务将并行运行。如果您有22个分区，那么2个分区将等待第一个可用的核心以恢复。
这意味着如果核心数较少，一些任务将不得不等待。但这是一个必须的行为，因为我们知道对于某些操作，密钥不是均匀分布的。这意味着一些分区的计算时间会更长，而另一些分区的计算时间会更少。
考虑到这一点，不要盲目地把2-3倍的线程数作为分区大小，评估阶段中任务的运行时间是多少，你就会看到有多少任务偏离了平均运行时间。分区太少也会导致内存溢出，分区太多会导致调度开销。
编辑：要完成重新分区建议，如果您正在对倾斜的键执行连接，并且无法广播，则重新分区不会对您有所帮助。重新分区仅在窄操作的情况下才有助于确保数据的均匀分布。

伊莫，你不应该使用执行者的数量，这相当于partitons的数量。。。
假设您有1000个分区，根据您的逻辑，您需要分配1000个执行器来处理1000个分区，这是错误的。
在你的情况下描述在后。。。。您的分区号可以/应该等于 number executors * number of cores * 2-3 例如，你的执行者数量=5，每个执行者有4个核心，那么你应该这样做。
注意：确保分区大小几乎相等，以确保使用 repartition 或者 coalesce 基于您的用例。