如何在Spark UI中定位耗时较长的转换操作

Spark本身是懒执行机制，join、filter、groupBy这类转换算子不会立刻触发计算，所有逻辑会等take(1)这类行动算子触发时，才会被打包成作业提交运行，因此Jobs列表里只会显示行动算子的总耗时，要定位具体哪个转换慢，按以下步骤操作即可：

• 进入目标作业的Job详情页
  在Spark UI首页的Jobs列表，找到对应take(1)的慢作业点击进入，页面会展示该作业拆分出的所有Stage，每个Stage的总耗时、输入数据量、Shuffle读写数据量、Task倾斜情况都会直接展示。
• 结合Stage划分规则匹配对应转换逻辑
  Spark的Stage拆分边界是触发Shuffle的操作，窄依赖操作（比如filter、map）不会拆分Stage。你例子中的join、groupBy都是Shuffle类操作，整个链路会拆成3个Stage：
  1. 首个Stage：执行join操作前的数据源读取、前置预处理逻辑
  2. 第二个Stage：执行join逻辑 + join后的filter逻辑，直到groupBy的Shuffle写入环节结束
  3. 第三个Stage：读取groupBy的Shuffle结果，执行聚合逻辑后返回take(1)的结果
     对比三个Stage的耗时，耗时异常高、Shuffle读写量远超预期的Stage，就是瓶颈所在的大致范围。
• 进入慢Stage详情页定位具体问题
  点击高耗时Stage进入详情，查看所有Task的细分运行指标，对应判断瓶颈点：
  • 如果Shuffle Read耗时占比极高、个别Task读取数据量是其他Task的数倍甚至数十倍：瓶颈在join或groupBy的Shuffle环节，大概率出现了数据倾斜
  • 如果Executor计算时间占比极高、Shuffle数据量符合预期：检查对应Stage内的计算逻辑，比如filter是否存在复杂判断、未做谓词下推扫了大量无关数据，groupBy的聚合逻辑是否存在冗余计算
  • 如果Shuffle Write耗时极高、写入数据量远大于预期：检查当前Stage是否没有提前过滤无效数据，导致大量冗余数据参与Shuffle传输
• 测试环境可临时拆分链路精准定位
  如果靠Stage指标无法精准定位，可以在测试环境用采样后的小批量数据运行代码，在几个转换算子之间临时插入count()这类轻量行动算子，把原本的长计算链路拆成多个独立小作业，直接看每个小作业的耗时就能精准定位慢转换，定位完成后删除临时添加的行动算子即可。

注意：生产环境不要随意插入临时行动算子，会触发重复计算，额外增加集群负载。

内容的提问来源于stack exchange，提问作者Pavel Orekhov