In this lesson, you will learn how to pinpoint specific performance bottlenecks by correlating physical plan nodes with stage-level metrics and task-level execution timelines in the Spark UI.
When a Spark job runs slowly, you shouldn't guess where the bottleneck lies; you should use the Spark UI to triangulate it. The process begins at the Stages tab. If you identify a stage with high duration, click into it to see the DAG Visualization. This allows you to map specific physical plan nodes—like Exchange (which indicates a shuffle) or HashAggregate—directly to the stage.
Connecting Metrics to Tasks
Once you’ve identified a problematic stage, scroll down to the Task Summary section. This is your primary diagnostic tool:
- Min/Median/Max/Max duration: If your
Maxduration is significantly higher than yourMedian, you are dealing with data skew. Some tasks are processing far more data than others, forcing the rest of the cluster to wait for one slow task to finish. - Shuffle Read/Write: If you see large values here, your bottleneck is likely I/O bound due to network traffic or disk spilling.
- GC Time: If Garbage Collection time is high, your executors are likely struggling with memory pressure, possibly due to over-caching or objects that don't fit in the execution memory.
Examining the Execution Timeline
For a granular view, look at the Event Timeline at the bottom of the stage page. By hovering over individual tasks, you can visualize the start and end times. If you see a long bar followed by a large "gap" before other tasks finish, you have identified a straggler.
Consider this simple join operation:
# A potential bottleneck if 'df_small' is large, causing a massive shuffle
result = df_large.join(df_small, "id")
In the UI, the Exchange node preceding this join will show up as a high-latency stage. By checking the Shuffle Write metrics, you can verify if the data volume is too large for the current partition count, prompting you to repartition or broadcast the smaller table.
Key Takeaway: By correlating the visual DAG nodes with the Task Summary’s min/max duration and shuffle metrics, you can definitively distinguish between data skew, inefficient shuffles, and resource-constrained execution.