Spark 'limit' 不并行运行？答案

【问题标题】：Spark 'limit' does not run in parallel?Spark 'limit' 不并行运行？
【发布时间】：2018-07-22 13:56:52
【问题描述】：

我有一个简单的连接，我限制了双方。在解释计划中我看到在执行限制之前有一个 ExchangeSingle 操作，实际上我看到在这个阶段只有一个任务在集群中运行。

这当然会极大地影响性能（取消限制会消除单个任务的瓶颈，但会延长连接，因为它适用于更大的数据集）。

limit 真的不能并行化吗？如果是这样 - 是否有解决方法？

我在 Databricks 集群上使用 spark。

编辑：关于可能的重复。答案并没有解释为什么所有东西都被洗牌到一个分区中。另外，我征求了解决此问题的建议。

【问题讨论】：

为什么一切都被洗牌 - 因为这是唯一合理的实现，可以确保单次传递数据和准确的结果。 建议解决此问题。 - 考虑放宽要求和样本，而不是限制？
@user8371915，起初我以为 Spark 会提前知道每个分区的确切大小——但我想我错了。假设有一个过滤器后跟一个限制。 Spark 事先不知道分区的大小，必须对其进行评估才能从那里获取元素。我猜 spark 可以同时推测和评估多个分区，但设计者选择不参与其中。我理解正确吗？
@user8371915，我将限制切换为样本，它就像一个魅力。我将其发布为答案，我会接受。如果您可以通过对实施细节的解释作为对社区的奖励，那就更好了。谢谢。
通常 Spark 不知道分区的大小。在某些情况下，它可能知道输入大小（来自输入拆分）或记录数（如果使用基于成本的优化器或其他形式的计算统计信息 - 这需要额外的扫描），但一般情况并非如此。您可以编写某种形式的优化器规则，但很难一概而论。
我认为没有必要这样做，而且我确信那里有更好的重复目标 - 只是我今天的搜索技能不太好。我很高兴我的评论对您有所帮助，而且我认为这个问题不值得投反对票，所以不要介意我并删除它，或者如果您更喜欢自己回答:)

【解决方案1】：

按照 user8371915 在 cmets 中给出的建议，我使用了 sample 而不是 limit。它打开了瓶颈。

一个小而重要的细节：我仍然必须在样本之后对结果集施加可预测的大小约束，但是样本输入了一个分数，因此结果集的大小可以在很大程度上取决于输入的大小。

对我来说幸运的是，使用 count() 运行相同的查询非常快。所以我首先计算了整个结果集的大小，并用它来计算我后来在样本中使用的分数。

【讨论】：

【解决方案2】：

限制后并行化的解决方法： .repartition(200)

这会再次重新分配数据，以便您可以并行工作。

【讨论】：