使用 .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被丢弃，所以不是我可以call.unpersist（）对我的datafames知道我会不会在未来的需要，所以，我不降的DF我会需要并且必须稍后重新加载它们。

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

提前致谢 ：）

Answer 1

似乎有一些误解。虽然 usingunpersist是更好地控制存储的有效方法，但它并不能避免垃圾收集。事实上，所有与缓存数据相关的堆上对象都将被垃圾收集器留下。

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

为了限制 GC 的 unpersist 可能值得看一下OFF_HEAP StorageLevel.