If I have the stages more than 3, say 4 I have the following result [[[], [7, 4, 1], [8, 5, 2], [9, 6, 3, 0]]]
However if I have the stages to be set as 3, then I have the following [[[], [8, 5, 2], [9, 7, 6, 4, 3, 1, 0]]]
There are 3 possible keys: 0, 1, and 2. Those keys are going to be hashed from which the partitions are calculated. (The hash: option allows generating hashes for partitioning directly, on the other hand)
So of those 3 keys, two of those are evidently hashing to very similar values, so when it partitions out the hash value space between the stages there is one reducer that isn’t getting any values. I’m guessing that it does an equal partition between stages, so with 3 stages each gets a third of the hash space and with 4 stages each gets a fourth of the hash space. This would make sense as the stages can not know in advance the distribution of keys.
This would only be a problem when there are few stages and a narrow and sufficiently similar set of keys to hash on. Which is exactly what you have in your example, resulting in one reducer getting zero inputs. As the number of stages increases, the hashing of the 3 values becomes apparent: three reducers get values and the others don’t.