One Spark task runs for an hour while the rest finish in seconds. What is happening and how do you fix it?

That is data skew: one key holds a disproportionate share of the rows, so a single partition does most of the work after a shuffle. Confirm it by checking the distribution of the join or group key. Fix it by enabling adaptive query execution's skew join handling, broadcasting the small side if it fits, salting the hot key across multiple partitions, or filtering and processing the outlier keys separately.

Long tail on one task almost always means skew: after the shuffle, one key landed in one partition and that partition has most of the rows. First I confirm it rather than assume, so a group by on the join key with a count, and a look at the stage in the Spark UI where the max task duration and shuffle read size dwarf the median. Throwing executors at it does nothing, because the work is not distributed. The fix depends on shape. If the other side of the join is small, broadcast it and skip the shuffle entirely. If it is genuinely large on both sides, adaptive query execution can split skewed partitions automatically, and beyond that I salt: append a random suffix to the hot key, replicate the small side across those salts, join, then aggregate. The one that catches people is nulls. We had a join key that was null for about 40% of rows, all of which hashed to one partition, and filtering nulls before the join fixed it outright.