如果 Spark 阶段已经完成，计算是否完成？答案

【问题标题】：If a Spark stage has completed, is the computation done?如果 Spark 阶段已经完成，计算是否完成？
【发布时间】：2018-06-01 09:07:55
【问题描述】：

我正在 Spark Application Master 控制台中查看我的工作，我可以实时看到各个阶段完成，因为 Spark 在我的应用程序的 DAG 中运行。这一切都进行得相当快。有些阶段不到一秒钟，有些则需要一两分钟。

列表顶部的最后阶段是rdd.saveAsTextFile(path, classOf[GzipCodec])。这个阶段需要很长时间。

我了解转换会执行零次、一次或多次，具体取决于由saveAsTextFile 或count 等操作创建的执行计划。

随着工作的进行，我可以在 App Manager 中看到执行计划。有些阶段不存在。有些人不止一次出现。这是意料之中的。我可以实时看到每个阶段的进度（只要我一直按 F5 刷新页面）。执行时间与每个阶段的数据输入大小大致相当。因此，我确信 App Manager 向我展示的是实际转换的进度，而不是 DAG 上的某些元活动。

那么，如果转换发生在每个阶段，为什么最后阶段（从 EMR 向 S3 的简单写入）如此缓慢？

如果像我的同事建议的那样，应用管理器中显示的转换阶段没有进行实际计算，那么它们在做什么会消耗如此多的内存、CPU 和时间？

【问题讨论】：

标签： apache-spark distributed-computing

【解决方案1】：

在 Spark 中，惰性求值是一个关键概念，如果您想使用 Spark，最好熟悉这个概念。

您目睹过快完成的阶段不会进行任何重要的计算。

If they are not doing actual computation, what are they doing?

他们正在更新 DAG。

当一个动作被触发时，Spark 有机会咨询 DAG 以优化计算（如果没有惰性优化，这是不可能的）。

而且，我觉得你的同事急着给你一个答案，并错误地说：

transformation are cheap

真相在ref's RDD operations:

Spark 中的所有转换都是惰性的，因为它们不计算他们的结果马上。相反，他们只记得应用于某些基础数据集（例如文件）的转换。这仅当操作需要结果时才计算转换返回到驱动程序。

便宜不是正确的词。

这解释了为什么在一天结束时，与其他任务相比，您的最后阶段（实际上是要求数据并触发操作）如此缓慢。

我的意思是你提到的每个阶段似乎都不会触发任何动作。因此，最后阶段必须考虑所有之前的阶段，并完成所有需要的工作，但请记住，在优化的 Spark 视图中。

【讨论】：

谢谢。仍然让我感到困惑的是，阶段是编译的 Spark 函数调用我编译的函数。鉴于其中许多需要几分钟才能完成，Spark 只是在做优化吗？还是有额外的工作要做？
@Synesso 我不明白这个问题。尤其是第一行。
例如，当 App Manager 显示一个阶段需要 3 分钟才能完成时，这 3 分钟内发生了什么？只有优化？
我想说@Synesso 的那个阶段没有发生任何优化。应用转换时，DAG 会相应更新。完成后，该阶段就完成了。当另一个应用了动作的阶段被执行时，Spark 将检查 DAG 以了解所有情况，进行概览，然后进行优化。
这是我最初的理解。我仍然很困惑。也许我可以在问题中添加一些代码。

【解决方案2】：

我想真正的困惑在这里：

转型很便宜

转换是懒惰的（大多数时候），但远不便宜。这意味着不会应用转换，除非有一个急切的后代（动作）依赖它。它没有告诉您任何有关其成本的信息。

一般来说，转换是发生真正工作的地方。与转换中执行的逻辑相比，输出操作（不包括存储/网络 IO）通常是廉价的。

【讨论】：

这也是我的理解。然而，尽管在 EMR 上运行，但写入 S3 阶段的速度却非常慢。
S3 通常非常慢，当然还有提交算法的问题。
向 S3 写入工作很慢，因为该提交算法使用重命名，这对 S3 来说很慢且不可靠。如果您没有使用“一致的 EMR”，请担心输出损坏的可能性而不是性能。