Spark从来不是，而且从来都不是“内存引擎”。如果检查内部结构，很显然它既没有针对内存中的处理进行优化，也没有针对内存中的硬件进行优化。

相反，几乎所有设计决策都是在这样一个假设下做出的，即整个数据的大小以及单个任务的输入和输出可能超过集群和单个执行器的可用内存量。 / executor线程分别。此外，它显然设计用于商品硬件。

这样的实现可用于恢复或避免重新计算（例如，参见What does "Stage Skipped" mean in Apache Spark web UI?），但这是重新设定目的而不是最初的目标。

这是一个很好的问题，因为我们听说了内存中的Spark与Hadoop，因此有些混乱。这些文档太糟糕了，但是我跑了几步，环顾四周以寻找最出色的资料来源，验证了观察结果：http://hydronitrogen.com/apache-spark-shuffles-explained-in-depth.html

假定已调用一个动作-如果未声明，则避免明显的注释，假设我们不在谈论ResultStage和广播联接，那么我们在谈论ShuffleMapStage。我们首先看一下RDD。

然后，从URL借用：

涉及洗牌的
• DAG依赖性意味着创建单独的舞台。
• Map操作后跟着Reduce操作和Map等。

当前阶段

  

  
• 所有（融合）地图操作均在阶段内执行。
  
• 下一阶段的需求，即减少操作-例如reduceByKey，表示在地图末尾对输出进行散列或按键排序（K）   当前阶段的操作。
  
• 此分组的数据被写入执行器所在的工作器上的磁盘，或与该Cloud版本绑定的存储。 （我会   如果数据很小，则认为在内存中是可能的，但这是体系结构性的Spark   文档中所述的方法。）
  
• ShuffleManager收到通知，下一个阶段可以使用散列的映射数据。 ShuffleManager跟踪所有   完成地图端所有工作后的关键位置。
  

下一阶段

  

  
• 下一阶段是精简，然后通过咨询Shuffle管理器并使用块管理器从这些位置获取数据。
  
• 执行人可以在其他工人上重用，也可以是新的，也可以在同一工人上重新使用。
  

因此，我的理解是，从结构上讲，即使有足够的内存，阶段也要写入磁盘。在给定Worker的有限资源的情况下，对于这种类型的操作会发生写入磁盘的情况。当然，更重要的一点是“ Map Reduce”实施。我总结了出色的文章，这是您的经典信息。

当然，这种持久性有助于减少容错，减少重新计算工作。

类似的方面也适用于DF。