Batch Shuffle #

Overview #

Flink supports a batch execution mode in both DataStream API and Table / SQL for jobs executing across bounded input. In batch execution mode, Flink offers two modes for network exchanges: Blocking Shuffle and Hybrid Shuffle.

• Blocking Shuffle is the default data exchange mode for batch executions. It persists all intermediate data, and can be consumed only after fully produced.
• Hybrid Shuffle is the next generation data exchange mode for batch executions. It persists data more smartly, and allows consuming while being produced. This feature is still experimental and has some known limitations.

Blocking Shuffle #

Unlike the pipeline shuffle used for streaming applications, blocking exchanges persists data to some storage. Downstream tasks then fetch these values via the network. Such an exchange reduces the resources required to execute the job as it does not need the upstream and downstream tasks to run simultaneously.

As a whole, Flink provides two different types of blocking shuffles: Hash shuffle and Sort shuffle.

Hash Shuffle #

The default blocking shuffle implementation for 1.14 and lower, Hash Shuffle, has each upstream task persist its results in a separate file for each downstream task on the local disk of the TaskManager. When the downstream tasks run, they will request partitions from the upstream TaskManager’s, which read the files and transmit data via the network.

Hash Shuffle provides different mechanisms for writing and reading files:

• file: Writes files with the normal File IO, reads and transmits files with Netty FileRegion. FileRegion relies on sendfile system call to reduce the number of data copies and memory consumption.
• mmap: Writes and reads files with mmap system call.
• auto: Writes files with the normal File IO, for file reading, it falls back to normal file option on 32 bit machine and use mmap on 64 bit machine. This is to avoid file size limitation of java mmap implementation on 32 bit machine.

The different mechanism could be chosen via TaskManager configurations.

This option is experimental and might be changed future.

If SSL is enabled, the file mechanism can not use FileRegion and instead uses an un-pooled buffer to cache data before transmitting. This might cause direct memory OOM. Additionally, since the synchronous file reading might block Netty threads for some time, the SSL handshake timeout needs to be increased to avoid connection reset errors.

The memory usage of mmap is not accounted for by configured memory limits, but some resource frameworks like Yarn will track this memory usage and kill the container if memory exceeds some threshold.

Hash Shuffle works well for small scale jobs with SSD, but it also has some disadvantages:

1. If the job scale is large, it might create too many files, and it requires a large write buffer to write these files at the same time.
2. On HDD, when multiple downstream tasks fetch their data simultaneously, it might incur the issue of random IO.

Sort Shuffle #

Sort Shuffle is another blocking shuffle implementation introduced in version 1.13 and it becomes the default blocking shuffle implementation in 1.15. Different from Hash Shuffle, Sort Shuffle writes only one file for each result partition. When the result partition is read by multiple downstream tasks concurrently, the data file is opened only once and shared by all readers. As a result, the cluster uses fewer resources like inode and file descriptors, which improves stability. Furthermore, by writing fewer files and making a best effort to read data sequentially, Sort Shuffle can achieve better performance than Hash Shuffle, especially on HDD. Additionally, Sort Shuffle uses extra managed memory as data reading buffer and does not rely on sendfile or mmap mechanism, thus it also works well with SSL. Please refer to FLINK-19582 and FLINK-19614 for more details about Sort Shuffle.

Here are some config options that might need adjustment when using sort blocking shuffle:

• taskmanager.network.sort-shuffle.min-buffers: Config option to control data writing buffer size. For large scale jobs, you may need to increase this value, usually, several hundreds of megabytes memory is enough. Because this memory is allocated from network memory, to increase this value, you may also need to increase the total network memory by adjusting taskmanager.memory.network.fraction, taskmanager.memory.network.min and taskmanager.memory.network.max to avoid the potential “Insufficient number of network buffers” error.
• taskmanager.memory.framework.off-heap.batch-shuffle.size: Config option to control data reading buffer size. For large scale jobs, you may need to increase this value, usually, several hundreds of megabytes memory is enough. Because this memory is cut from the framework off-heap memory, to increase this value, you need also to increase the total framework off-heap memory by adjusting taskmanager.memory.framework.off-heap.size to avoid the potential direct memory OOM error.

Currently Sort Shuffle only sort records by partition index instead of the records themselves, that is to say, the sort is only used as a data clustering algorithm.

Choices of Blocking Shuffle #

As a summary,

• For small scale jobs running on SSD, both implementation should work.
• For large scale jobs or for jobs running on HDD, Sort Shuffle should be more suitable.

To switch between Sort Shuffle and Hash Shuffle, you need to adjust this config option: taskmanager.network.sort-shuffle.min-parallelism. It controls which shuffle implementation to use based on the parallelism of downstream tasks, if the parallelism is lower than the configured value, Hash Shuffle will be used, otherwise Sort Shuffle will be used. For versions lower than 1.15, its default value is Integer.MAX_VALUE, so Hash Shuffle will be used by default. Since 1.15, its default value is 1, so Sort Shuffle will be used by default.

Hybrid Shuffle #

This feature is still experimental and has some known limitations.

Hybrid shuffle is the next generation of batch data exchanges. It combines the advantages of blocking shuffle and pipelined shuffle (in streaming mode).

• Like blocking shuffle, it does not require upstream and downstream tasks to run simultaneously, which allows executing a job with little resources.
• Like pipelined shuffle, it does not require downstream tasks to be executed after upstream tasks finish, which reduces the overall execution time of the job when given sufficient resources.
• It adapts to custom preferences between persisting less data and restarting less tasks on failures, by providing different spilling strategies.

To use hybrid shuffle mode, you need to configure the execution.batch-shuffle-mode to ALL_EXCHANGES_HYBRID_FULL (full spilling strategy) or ALL_EXCHANGES_HYBRID_SELECTIVE (selective spilling strategy).

Spilling Strategy #

Hybrid shuffle provides two spilling strategies:

• Selective Spilling Strategy persists data only if they are not consumed by downstream tasks timely. This reduces the amount of data to persist, at the price that in case of failures upstream tasks need to be restarted to reproduce the complete intermediate results.
• Full Spilling Strategy persists all data, no matter they are consumed by downstream tasks or not. In case of failures, the persisted complete intermediate result can be re-consumed, without having to restart upstream tasks.

To use hybrid shuffle mode, you need to configure the execution.batch-shuffle-mode to ALL_EXCHANGES_HYBRID_FULL (full spilling strategy) or ALL_EXCHANGES_HYBRID_SELECTIVE (selective spilling strategy).

Data Consumption Constraints #

Hybrid shuffle divides the partition data consumption constraints between producer and consumer into the following three cases:

• ALL_PRODUCERS_FINISHED : hybrid partition data can be consumed only when all producers are finished.
• ONLY_FINISHED_PRODUCERS : hybrid partition can only consume data from finished producers.
• UNFINISHED_PRODUCERS : hybrid partition can consume data from unfinished producers.

These could be configured via jobmanager.partition.hybrid.partition-data-consume-constraint.

• For AdaptiveBatchScheduler : The default constraint is UNFINISHED_PRODUCERS to perform pipelined-like shuffle. If the value is set to ALL_PRODUCERS_FINISHED or ONLY_FINISHED_PRODUCERS, performance may be degraded.
• If SpeculativeExecution is enabled : The default constraint is ONLY_FINISHED_PRODUCERS to bring some performance optimization compared with blocking shuffle. Since producers and consumers have the opportunity to run at the same time, more speculative execution tasks may be created, and the cost of failover will also increase. If you want to fall back to the same behavior as blocking shuffle, you can configure this value to ALL_PRODUCERS_FINISHED. It is also important to note that UNFINISHED_PRODUCERS is not supported in this mode.

Remote Storage Support #

Hybrid shuffle supports to store the shuffle data to the remote storage. The remote storage path can be configured by taskmanager.network.hybrid-shuffle.remote.path. This feature supports various remote storage systems, including OSS, HDFS, S3, etc. See Flink Filesystem for more information about the Flink supported filesystems.

Limitations #

Hybrid shuffle mode is still experimental and has some known limitations, which the Flink community is still working on eliminating.

• No support for Slot Sharing. In hybrid shuffle mode, Flink currently forces each task to be executed in a dedicated slot exclusively. If slot sharing is explicitly specified, an error will occur.
• No pipelined execution for dynamic graph. If auto-parallelism (dynamic graph) is enabled, Adaptive Batch Scheduler will wait until upstream tasks finish to decide parallelism of downstream tasks, which means hybrid shuffle effectively fallback to blocking shuffle (ALL_PRODUCERS_FINISHED constraint).

Performance Tuning #

The following guidelines may help you to achieve better performance especially for large scale batch jobs:

Trouble Shooting #

Here are some exceptions you may encounter (rarely) and the corresponding solutions that may help: