Spark：阶段边界上的磁盘 I/O 解释

Question

我在官方文档中找不到关于Spark临时数据在磁盘上持久化的信息，只能在一些Spark优化文章中找到这样的信息：

在每个阶段边界，数据由父阶段中的任务写入磁盘，然后由子阶段中的任务通过网络获取。由于阶段边界会产生大量磁盘和网络 I/O，因此成本高昂，应尽可能避免。

Is persistance to disk on each stage boundary always applied for both: HashJoin and SortMergeJoin? Why does Spark (in-memory engine) does that persistance for tmp files before shuffle? Is that done for task-level recovery or something else?

P.S. Question relates mainly to Spark SQL API, while I'm also interested in Streaming & Structured Streaming

UPD: found a mention and more details of Why does it happens at "Stream Processing with Apache Spark book". Look for "Task Failure Recovery" and "Stage Failure Recovery" topics on referrenced page. As far as I understood, Why = recovery, When = always, since this is mechanics of Spark Core and Shuffle Service, that is responsible for data transfer. Moreover, all Spark's APIs (SQL, Streaming & Structured Streaming) are based on the same failover guarantees (of Spark Core/RDD). So I suppose that this is common behaviour for Spark in general

Answer 1

这是一个很好的问题，因为我们听说过内存 Spark 与 Hadoop，所以有点令人困惑。这些文档很糟糕，但我运行了一些东西并通过环顾四周找到最优秀的来源来验证观察结果：http://Hydroxygen.com/apache-spark-shuffles-explained-in-depth.html

假设已经调用了一个 Action - 为了避免在没有说明的情况下出现明显的注释，假设我们不是在谈论 ResultStage 和广播连接，那么我们正在谈论 ShuffleMapStage。我们首先查看 RDD。

然后，借用url：

• 涉及洗牌的 DAG 依赖意味着创建单独的 Stage。
• Map 操作之后是Reduce 操作和Map 等等。

当前阶段

• 所有（融合的）Map 操作都是在Stage 内执行的。
• 下一个Stage 要求是Reduce 操作，例如reduceByKey，意味着在当前Stage 的Map 操作结束时按键(K) 对输出进行散列或排序。
• 这些分组数据被写入执行器所在的工作器上的磁盘 - 或与该云版本绑定的存储。（如果数据很小，我本以为在内存中是可能的，但正如文档中所述，这是一种架构 Spark 方法。）
• ShuffleManager 会收到散列映射数据可供下一阶段使用的通知。一旦所有地图端工作完成，ShuffleManager 就会跟踪所有键/位置。

下个阶段

• 下一阶段是减少，然后通过咨询洗牌管理器并使用块管理器从这些位置获取数据。
• Executor 可以在另一个 Worker 上重复使用或成为新的，或者在同一个 Worker 上使用另一个 Executor。

所以，我的理解是，从架构上来说，阶段意味着写入磁盘，即使有足够的内存。考虑到 Worker 的资源有限，这种类型的操作写入磁盘是有意义的。当然，更重要的一点是“Map Reduce”的实现。我总结了这篇优秀的帖子，这是您的规范来源。

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

类似的方面也适用于 DF。