Every symptom in Part 2 was found on one screen. Spark's docs: "Apache Spark provides a suite of web user interfaces (UIs) that you can use to monitor the status and resource consumption of your Spark cluster." It runs on the driver, on port 4040 by default, and these are its five tabs and the one question each answers.
The five tabs
Jobs. "The Jobs tab displays a summary page of all jobs in the Spark application and a details page for each job." One row per action, with status and duration. Which action is slow?
Stages. "The Stages tab displays a summary page that shows the current state of all stages of all jobs." Each stage's page has its DAG and a table of task metrics: duration, "GC time", "Shuffle Read Size / Records", "Shuffle spill (memory)" and "(disk)". Which stage, and is it one task or all of them? One long task among many short ones is skew. Every task spilling is the memory shape. Thousands of millisecond tasks is too many pieces.
Storage. "The Storage tab displays the persisted RDDs and DataFrames, if any, in the application. The summary page shows the storage levels, sizes and partitions of all RDDs." Is the cache there, and how big?
SQL. "The SQL tab lists all SQL and DataFrame queries submitted to the Spark application." Each query's page draws its physical plan as a graph with metrics on every operator: rows, bytes, time. Which operator? This is the plan from Reading a Plan with the numbers on it.
Executors. "The Executors tab lists every executor that has been allocated to the application, including the driver." Memory, disk, cores, tasks, shuffle totals, GC time, per process. Is one executor the problem, or the driver?
A route through it
Slow job: Jobs, find the long one. Stages, find the long stage and look at how its tasks are spread. One task long: skew (When One Key Has Everyone). Every task spilling: memory (Where the Memory Goes) or pieces (How Many Pieces). A long stage with a join in it: SQL, read the plan, check the strategy (How a Join Is Planned). Something built twice that should have been kept: Storage (Keep It Around). One machine or the driver standing out: Executors.
What this site shows
No UI: one process, no port 4040. What this site gives you is the plan, which is what the SQL tab draws, and the vocabulary every tab is written in: job, stage, task, shuffle, partition, spill.
The symptom, and the fix
The fix for "it's slow" is a route, not a setting: Jobs, then Stages, then the task distribution, then the lesson the shape points to. Guessing a config is what people do instead, and it is why spark.executor.memory gets doubled on jobs whose problem was one hot key.
Self-check
The Stages tab shows a stage where 199 tasks took two seconds each and one took forty minutes. Which lesson?
When One Key Has Everyone: one key with most of the rows, one task with most of the work.
That is Part 2. Eight lessons on why a job is slow and what to do about it, every engine claim measured here and every Spark claim quoted from its documentation. You can now read a plan, count its pieces, spot a hot key, name a join's strategy, decide what to cache, read an out-of-memory error, choose a file layout, and find all of it on the Spark UI. The glossary holds every term with Spark's own definition beside it.