Make shuffle robust to small partitions
- Dominant language
- Python
- Stars
- 1.7k
- Forks
- 778
- Avg merge
- 2h 50m
- Merged PRs (30d)
- 3
Description
My understanding is that we saw that benchmark performance increased substantially in shuffle workloads if we reduced the number of partitions. This led to optimizations like https://github.com/dask-contrib/dask-expr/pull/327 . This seems great.
I'm curious though if we can also make p2p shuffle more robust to partition size. For example, one dumb idea would be to add yet-another-buffer and just accrue partitions until we had, say 512 MB of data, and only then start sharding things. Presumably then we wouldn't care if we were given very small partitions or not.
Reducing the number of input partitions is a great decision regardless. However, I suspect that there will be other times where we'll get lots of small partitions (https://github.com/dask/dask/pull/10542 comes to mind). If we can become less sensitive here that seems good.
(Please excuse any ignorance on my part here. It's been a while since I've looked at P2P code)
Contributor guide
Assessment
This issue has not been assessed yet.