Github user srowen commented on a diff in the pull request:

    https://github.com/apache/spark/pull/5074#discussion_r27292232
  
    --- Diff: docs/programming-guide.md ---
    @@ -1086,6 +1086,66 @@ for details.
     </tr>
     </table>
     
    +### Shuffle operations
    +
    +Certain operations within Spark trigger an event known as the shuffle. The 
shuffle is Spark's
    +mechanism for re-distributing data so that is grouped differently across 
partitions. This typically
    +involves copying data across executors and machines, making the shuffle a 
complex and
    +costly operation.
    +
    +#### Background
    +
    +To understand what happens during the shuffle we can consider the example 
of the
    +[`reduceByKey`](#ReduceByLink) operation. The `reduceByKey` operation 
generates a new RDD where all
    +values for a single key are combined into a tuple - the key and the result 
of executing a reduce
    +function against all values associated with that key. The challenge is 
that not all values for a
    +single key necessarily reside on the same partition, or even the same 
machine, but they must be
    +co-located to compute the result.
    +
    +In Spark, data is generally not distributed across partitions to be in the 
necessary place for a
    +specific operation. During computations, a single task will operate on a 
single partition - thus, to
    +organize all the data for a single `reduceByKey` reduce task to execute, 
Spark needs to perform an
    +all-to-all operation. It must read from all partitions to find all the 
values for all keys, and then
    +organize those such that all values for any key lie within the same 
partition - this is called the
    +**shuffle**.
    +
    +Although the set of elements in each partition of newly shuffled data will 
be deterministic, the
    +ordering of these elements is not. If one desires predictably ordered data 
following shuffle
    --- End diff --
    
    Fair point, yeah. This could be a dumb question, but do we know that the 
partitions will always appear in the same order? I suppose it depends on the 
partitioner, but, even for `HashPartitioner` -- do we know that, say, 
everything hashing to 0 occurs in partition 0 every time? If this is order of 
partitions is deterministic for any reasonable case, then I get it at last, 
yeah.
    
    _If_ that understanding is correct, then, here's another pass at the 
paragraph:
    
    Although the set of elements in each partition of newly shuffled data will 
be deterministic, and so is the ordering of partitions themselves, the ordering 
of these elements within each partition is not. If one desires predictably 
ordered data following shuffle operations, then it's possible to use:
    
    - `mapPartitions` to sort each partition using, for example, `.sorted`
    - `repartitionAndSortWithinPartitions` to efficiently sort partitions while 
simultaneously repartitioning
    - `sortBy` to make a globally ordered RDD


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at [email protected] or file a JIRA ticket
with INFRA.
---

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to