apache-spark - 缓存和检查点是否应该在数据集上一起使用？如果是这样，这是如何在引擎盖下工作的？

Question

我正在研究一个 Spark ML 管道，我们在较大的数据集上遇到 OOM 错误。在训练之前，我们使用 cache() ;我把它换成了 checkpoint()我们的内存需求显着下降。但是，在 RDD 的文档中的 checkpoint()它说:

It is strongly recommended that this RDD is persisted in memory, otherwise saving it on a file will require recomputation.

DataSet 没有给出相同的指导的检查点，这就是我正在使用的。无论如何遵循上述建议，我发现使用 cache() 后，内存需求实际上略有增加。独自的。

我的期望是当我们这样做时

...
ds.cache()
ds.checkpoint()
...

对检查点的调用强制评估 DataSet ，在被检查点之前同时缓存。之后，对 ds 的任何引用将引用缓存的分区，如果需要更多内存并且分区被疏散，则将使用检查点分区而不是重新评估它们。这是真的，还是在幕后发生了一些不同的事情？理想情况下，如果可能的话，我希望将 DataSet 保留在内存中，但从内存的角度来看，使用缓存和检查点方法似乎没有任何好处。

Answer 1

TL;博士 您不会在后续操作中受益于内存缓存 ( default storage level for Dataset is MEMORY_AND_DISK anyway )，但如果计算 ds，您仍应考虑缓存。价格昂贵。

说明

你的期望

ds.cache()
ds.checkpoint()
...

the call to checkpoint forces evaluation of the DataSet

是正确的。 Dataset.checkpoint有不同的风格，允许急切和懒惰的检查点，以及 the default variant is eager

def checkpoint(): Dataset[T] = checkpoint(eager = true, reliableCheckpoint = true)

因此，后续操作应重用检查点文件。

然而，在幕后 Spark 只是 applies checkpoint on the internal RDD ，所以评估规则没有改变。 Spark 先评估 action，然后创建 checkpoint (这就是为什么首先推荐缓存的原因)。

所以如果你省略 ds.cache() ds将在 ds.checkpoint() 中评估两次:

一次换 internal count .

一次为实际checkpoint .

因此没有任何改变和 cache仍然推荐，尽管与普通 RDD 相比，推荐可能略弱, 如 Dataset缓存被认为在计算上很昂贵，并且根据上下文，简单地重新加载数据可能更便宜(请注意，没有 Dataset.count 的 cache 通常是优化的，而带有 Dataset.count 的 cache 不是 - Any performance issues forcing eager evaluation using count in spark? ) .