DataFrame orderBy 后跟 Spark 中的限制

Question

我有一个程序需要生成一个数据帧，它会在上面运行类似的东西

    Select Col1, Col2...
    orderBy(ColX) limit(N)

但是，当我最后收集数据时，我发现如果我取足够大的top N，它会导致驱动程序OOM

另外一个观察是，如果我只做排序和顶部，这个问题就不会发生。因此，只有在同时存在 sort 和 top 时才会发生这种情况。

我想知道为什么会发生这种情况？特别是，这两种转换组合背后的真正原因是什么？spark将如何评估带有排序和限制的查询以及下面相应的执行计划是什么？

也只是好奇数据帧和 RDD 之间的火花处理排序和顶部不同吗？

编辑，对不起，我不是说收集，我原来的意思是当我调用任何操作来实现数据时，无论它是收集（或任何将数据发送回驱动程序的操作）还是不是（所以问题肯定是不在输出尺寸上）

Answer 1

虽然不清楚为什么在这种特殊情况下会失败，但您可能会遇到多个问题：

• 当您使用limit它时，它只是将所有数据放在一个分区上，无论它有多大n。因此，虽然它没有明确收集它几乎同样糟糕。
• 最重要的是，orderBy需要使用范围分区进行完全洗牌，这可能会在数据分布偏斜时导致不同的问题。
• 最后，当您的collect结果可能大于驱动程序上可用的内存量时。

如果您collect无论如何都没有太多可以改进的地方。在一天结束时，驱动程序内存将是一个限制因素，但仍有一些可能的改进：

• 首先不要使用limit.
• 替换collect为toLocalIterator。
• 使用orderBy|> rdd|> zipWithIndex|>filter或者如果确切数量的值不是filter直接基于近似分布的硬要求数据，如在不重新分区的情况下将 spark 数据帧保存在多个部分中所示（在 Spark 2.0.0+ 中，有一个方便的approxQuantile方法）。