scala - 使用 .unpersist() 手动管理内存是个好主意吗？

Question

我在这里阅读了很多关于数据帧上的 unpersist() 的问题和答案。到目前为止，我还没有找到这个问题的答案:

在 Spark 中，一旦我完成了一个数据帧，调用 .unpersist() 来手动强制该数据帧从内存中取消持久化，而不是等待 GC(这是一项昂贵的任务)是个好主意吗？ 就我而言，我正在加载许多数据帧，以便我可以执行连接和其他转换。

因此，例如，如果我希望加载并加入 3 个数据帧 A、B 和 C:
我加载数据帧 A 和 B，加入这两个创建 X，然后 .unpersist() B 因为我不再需要它(但我将需要 A)，并且可以使用内存加载 C(这是很大的)。然后我加载 C，并将 C 连接到 X，在 C 上使用 .unpersist() 这样我就有更多的内存用于我现在将在 X 和 A 上执行的操作。

我知道 GC 最终对我来说不会持久，但我也明白 GC 是一项昂贵的任务，应该尽可能避免。重新表述我的问题:这是手动管理内存以优化我的 Spark 作业的合适方法吗？

我的理解(如有错误请指正):

我知道 .unpersist() 是一个非常便宜的操作。

我知道 GC 最终会在我的数据帧上调用 .unpersist() 。

我知道 spark 会根据最近使用的策略来监控缓存和丢弃。但在某些情况下，我不希望删除“最后使用的”DF，因此我可以在我知道将来不需要的数据名上调用.unpersist()，这样我就不会删除我将要使用的 DF需要并且必须稍后重新加载它们。

如果不清楚，请再次重新表述我的问题:这是 .unpersist() 的适当用法，还是应该让 Spark 和 GC 完成他们的工作？

提前致谢 :)

Answer 1

似乎有些误解。使用时 unpersist是更好地控制存储的有效方法，它不会避免垃圾收集。事实上，所有与缓存数据相关的堆上对象都将被留在垃圾收集器中。

因此，虽然操作本身相对便宜，但它触发的一系列事件可能并不便宜。幸运的是，显式持久化并不比等待自动清理器或 GC 触发清理器更糟糕，因此如果您想清理特定对象，请继续执行。

要将 GC 限制为非持久化，可能值得查看 OFF_HEAP StorageLevel .