我想知道如果我对Spark中的分区的理解是正确的。 我一直在考虑分区数量及其大小，而不是 他们由处理的工作人员。
昨天，由于我正在玩分区，我发现我能够使用WEB UI（存储 - ＆gt;缓存RDD - ＆gt;数据分发）跟踪缓存分区的位置，这让我感到惊讶。
我有一个30个核心的集群（3个核心* 10个执行程序），我有一个类似10个分区的RDD。我试图将其扩展到100个分区以增加并行性，只是为了发现几乎90％的分区都在同一个工作节点上，因此我的并行性不受集群中cpu总数的限制，而是受到数量的限制。包含90％分区的节点的cpu。
我试图在stackoverflow上找到答案，我唯一可以得到的答案就是数据局部性。 Spark检测到我的大多数文件都在这个节点上，所以它决定将大部分分区保留在这个节点上。
我的理解是否正确？
如果是的话，有没有办法告诉Spark 真的改组数据？ 到目前为止，这个“数据位置”导致我的集群严重未充分利用......
答案 0 :(得分：-1)
Spark严重依赖于数据位置。它总是尝试将工作室壁橱运行到数据所在的位置。
现在RDD的问题有10个分区，但是spark作业有30 * 3个分区。这基本上意味着最多10个执行器可以并行运行，其余的将处于空闲状态。
所以有两种选择。您可以减少spark作业执行程序，以便从集群中使用更少的资源。或者您可以增加RDD中的分区数。
要做的就是重新分配。
val newDF = df.repartition(100).
这会强制改组原始数据，并会创建更多分区。
然而，拥有许多分区会产生反效果。如果每个分区都很小，那么火花任务将花费越来越少的时间来完成。然后，您将看到每个任务比处理数据花费更多时间来启动/安排。
理想情况下，您希望保持每个RDD分区等于HDFS块大小，以获得（128MB）最佳效益。
由于您只有4个节点，因此底层数据最多可以存在于4个节点中。如果rdd分区10建议的数据很小。数据可能存在于1个框中。这使得Spark在不同的物理盒中产生执行器的空间非常小。由于spark基本上试图将数据局部性作为主要目标，同时产生执行程序，因此它会在最初存在数据的同一个框中产生工作者。
因此，当您进行重新分区时，您最终会在同一个框中显示所有数据。我建议你用更大的数据集和更大数量的节点来测试它，其中spark重新分配将提供所需的好处。