Apache spark 了解DAG可视化。为什么我的工作要花这么长时间？

我有一份很有活力的工作，时间太长了。这是一个包含432项任务的阶段。395项任务几乎立即完成。在接下来的10个小时里，剩下的任务很难完成。在杀死集群、调整代码并重试之前，我还完成了大约30个任务。但是我在黑暗中工作，因为我不知道是什么原因导致这份工作花了这么长时间

我发现了DAG可视化页面。对于此作业，它看起来如下所示：

该页面还报告完成了第31、31、34、35和36阶段。33项待决，37项正在进行中

问题1，作为旁白：当34依赖于33时，第33阶段待决和第34阶段如何完成

如果我钻到第37阶段，我会看到这个DAG

问题2：这是否给了我一些线索，说明我的舞台为什么会长期运行？似乎没有

到目前为止已完成的任务摘要（目前为1.1小时）

放大最大值：

编辑：以下是我的遗嘱执行人的计划：

问题3：这些价值观是否值得关注？在我看来，它们都是合理的

最后一个问题：我还能从哪里了解我的遗嘱执行人在忙些什么

---

编辑：我发现Executors页面上的堆栈转储有助于准确了解瓶颈所在。在优化这项工作方面，我还遗漏了其他线索吗？

你想完成什么样的任务？从图中的边子集，在测量距离的图中遍历区域子集，然后合并所有结果，以找到从每条边到任何种子边的最短路径。阶段37是从一组不超过32条地理上接近的种子边到图形分区的递归A*遍历。线程转储表明，当它递归时，在

Set.diff（Set）

操作中花费了大量时间。所以我重新修改了那个部分以提高效率&再试一次。工作在1.3分钟内完成！！要么我刚刚引入了一个bug，要么这是我一生中可能看到的最简单的优化。你也许可以做到这一点。。。但也许不是。我有一个类似的问题，一些树生成。Spark不是为迭代和相关任务设计的（通常有GraphX，但它也有局限性）。“转换”形成一个AST，该AST在“操作”（如collect）上执行。但是如果你在一个while循环中，AST也会被追加。“递归”似乎是个问题。是的，我学会了不使用

RDD

s进行任何递归工作。相反，工作被分配用于并行化，递归在每个工作单元内完成，结果随后合并。i、 经验法则：永远不要将RDD作为递归方法的参数。