我面临一个与spark的持久性机制有关的怪异问题。我正在尝试使用以下spark（2.1.1）配置来保留相当大的数据集（MEMORY_AND_DISK_SER）：
--num-executors 27
-执行器内存30GB
--executor-cores 5
我正在运行spark应用程序的集群具有以下特征：
节点数：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上注意到的是，在计算mydataset2之前，mydataset是非持久性的。这是预期的行为还是我缺少了什么？
谢谢。
最佳答案
我的建议是（如果您有选择的话）只将数据集写入您当前尝试保留的HDFS，然后再读回。保持简单！过去，我发现缓存/持久性存在各种奇怪的问题，通常得出的结论是，稍长的运行时间值得我继续工作；如果将数据集放在第一位的成本很高，则尤其如此。