bigdata - Apache Flink 中 shuffle() 和 rebalance() 的区别

Question

我正在做我的学士期末项目，该项目是关于 Apache Spark Streaming 和 Apache Flink(仅流)之间的比较，我刚刚到达 Flink 文档中的“物理分区”。问题是在这个文档中它没有很好地解释这两个转换是如何工作的。直接从文档:

shuffle(): Partitions elements randomly according to a uniform distribution.

rebalance(): Partitions elements round-robin, creating equal load per partition. Useful for performance optimisation in the presence of data skew.

来源: https://ci.apache.org/projects/flink/flink-docs-release-1.2/dev/datastream_api.html#physical-partitioning
两者都是自动完成的，所以 我的理解 是它们均等地重新分配( shuffle() > 均匀分布和 rebalance() > 循环)并随机分配数据。然后我推断出 rebalance()以更好的方式分发数据(“每个分区的负载相等”)，因此任务必须处理相同数量的数据，但 shuffle()可能会创建越来越小的分区。 那么，在哪些情况下您可能更喜欢使用 shuffle()比rebalance() ?
我唯一想到的是可能 rebalance()需要一些处理时间，因此在某些情况下，它可能需要更多的时间来进行重新平衡，而不是在 future 的转换中改进的时间。
我一直在找这个，没有人谈过这个，只在Flink的一个邮件列表中，但他们没有解释如何 shuffle()作品。
感谢 Sneftel谁帮助我改进了我的问题，让我重新思考我想问什么；并到 Till谁回答了我的问题。 :D

Answer 1

正如文档所述，shuffle将随机分布数据，而 rebalance将以循环方式分发数据。后者效率更高，因为您不必计算随机数。此外，根据随机性，您最终可能会得到某种不那么均匀的分布。

另一方面，rebalance将始终开始将第一个元素发送到第一个 channel 。因此，如果你只有很少的元素(元素比子任务少)，那么只有一些子任务会接收元素，因为你总是开始将第一个元素发送到第一个子任务。在流的情况下，这最终应该无关紧要，因为您通常有一个无界的输入流。

这两种方法存在的实际原因是历史原因。 shuffle首先介绍。为了使批处理与流式 API 更加相似，rebalance然后被介绍。