火花:舞台边界上的磁盘I/O解释

Question

我无法在官方文档中找到有关火种临时数据存储在磁盘上的信息，只能在一些火种优化文章中找到，比如这。

在每个阶段边界，数据通过父阶段的任务写入磁盘，然后通过子阶段的任务在网络上获取。因为它们会产生大量的磁盘和网络I/O，所以阶段边界可能很昂贵，应该尽可能避免。

在每个阶段边界上对磁盘的坚持是否总是同时适用于: HashJoin和SortMergeJoin？为什么斯派克(内存中的引擎)在洗牌前对tmp文件有持续的坚持？这是为了任务级的恢复还是其他什么的？

P.S.问题主要涉及Spark，而我也对流和结构化流感兴趣

UPD:找到了关于为什么会在“用Apache火花书进行流处理”发生这种情况的更多细节。在参考页面上查找“任务故障恢复”和“阶段故障恢复”主题。据我所知，为什么=恢复，为什么=总是，因为这是火花核心和洗牌服务的机制，负责数据传输。此外，所有Spark的API (SQL、流和结构化流)都基于相同的故障转移保证(Spark/RDD)。所以我认为这是星火的普遍行为

Answer 1

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

假设一个Action已经被调用--如果没有声明，为了避免明显的评论，假设我们不是在谈论ResultStage和一个广播连接，那么我们是在谈论ShuffleMapStage。我们首先看一个RDD。

然后，从网址借款：

• 涉及洗牌的DAG依赖意味着创建一个单独的阶段。
• 在映射操作之后，依次是还原操作和Map等等。

当前级

• 所有(融合的)映射操作都是在内部执行的。
• 下一个阶段的需求，一个约简操作--例如一个reduceByKey，意味着输出在当前阶段的Map操作的末尾被散列或按键(K)排序。
• 这些分组数据被写入执行器所在的工作程序上的磁盘，或者与云版本绑定的存储。(如果数据很小，我会认为内存中的数据是可能的，但这是一种从文档中声明的体系结构火花方法。)
• 通知ShuffleManager，哈希映射的数据可以在下一阶段使用。一旦完成所有的映射端工作，ShuffleManager就会跟踪所有的键/位置。

下一阶段

• 下一个阶段，作为一个缩减，然后通过咨询Shuffle和使用块管理器从这些位置获取数据。
• 遗嘱执行人可以在另一工人身上被重复使用，或者是一个新的执行者，或者在同一工人上是另一个执行者。

因此，我的理解是，在体系结构上，阶段意味着写入磁盘，即使有足够的内存。给定工作人员的有限资源，对于这种类型的操作，写入磁盘是有意义的。当然，更重要的一点是“地图缩减”实现。我总结了优秀的帖子，那是你的规范来源。

当然，容错是由于这种持久性，较少的重新计算工作。

类似的方面也适用于外勤部。

Answer 2

火花不是，也从来不是“内存中的引擎”。如果您检查内部，很明显，它既没有优化的内存处理，也没有调优为内存为中心的硬件。

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

这种实现可以用于恢复或避免重新计算(例如，请参阅在中，“阶段跳过”意味着什么？)，但这是重定向而不是初始目标。