Question

我正面临一个与spark的持久性机制相关的奇怪问题。我试图使用以下spark（2.1.1）配置来保持相当大的数据集（MEMORY_AND_DISK_SER）：

- num-executors 27 --executor-memory 30GB --executor-cores 5

我正在运行spark app的群集具有以下特征：

节点数量：9，每个节点的内存：100GB，每个节点的核心数：15

数据集有：

810个分区（27 * 5 * 6）

数据集的内存大小达到1.4TB，这就解释了为什么我使用MEMORY_AND_DISK_SER持久性。但是，在某些时候，当每个节点15G（30 * 0.5）完全用于内存持久性而不是写入磁盘时，Spark执行器会失败，spark程序也会失败。有没有人遇到过这种问题？有谁能建议替代解决方案？我绝对需要坚持我的数据集，因为重新计算它们非常（非常！）昂贵。

在类似的说明中，我有一个关于持久性顺序的问题。我们假设，我的代码如下：

Dataset<T> mydataset = loading a file;
mydataset.map(...).persist().count();
Dataset<T> mydataset2 = mydataset.map(...);
mydataset.unpersist();
mydataset2.persist().count();

我知道坚持是一种懒惰的操作。如果我分解代码，我会假设mydataset将被计算并持久化，然后，mydataset2将使用mydataset（持久化）进行计算。 Mydataset是立即无法使用的，并且在内存存储中替换为mydataset2。对？那么我在SparkUI上注意到的是mydataset在计算mydataset2之前是未加载的方式。这是预期的行为还是我错过了什么？

感谢。

Answer 1

我的建议是（如果你有选择）只将数据集写入HDFS，你当前正试图坚持，然后再读回来。保持简单！我在过去发现了缓存/持久化的各种奇怪问题，并且通常认为稍微长一点的运行时间比值得花时间坚持工作更值得;如果首先制作数据集非常昂贵，那么尤其如此。

关于Spark的持久性机制

1 个答案: