You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 2ced43b
Browse filesBrowse the repository at this point in the historyBrowse files
[SPARK-48290][CORE][FOLLOWUP] Bound the skewed block count and the selection cost
Address two problems with enabling the accurate recording of skewed block
sizes by default.
The number of accurately recorded blocks was only bounded by the size of the
cutoff block, so blocks tied at that size were all recorded and could exceed
spark.shuffle.maxAccurateSkewedBlockNumber by orders of magnitude. With 50000
reduce partitions, 25001 blocks of 1 KiB and 24999 blocks of 8 KiB, all 24999
larger blocks were recorded instead of at most 100. The blocks strictly larger
than the cutoff are now counted up front, and the rest of the budget admits the
tied blocks in block index order, which keeps the map status deterministic.
Blocks at or above spark.shuffle.accurateBlockThreshold are still always
recorded, as they were before.
Utils.nthSmallest picked the middle element as the pivot, which is quadratic
for an organ pipe distribution of block sizes. It is now an introselect: the
pivot is the median of the first, middle and last element, and the range still
under consideration is sorted once the ranges have stopped shrinking quickly
enough, which bounds the worst case at O(numPartitions * log(numPartitions)).
Both cases are covered by new tests, the ordering that the block count relies
on is now asserted directly, and the benchmark also reports the organ pipe
distribution.
0 commit comments