我正在完成学士学位的最后一个项目，这是关于apachespark流媒体和apacheflink（仅流媒体）之间的比较，我刚刚谈到flink文档中的“物理分区”。问题是，在这个文档中，它没有很好地解释这两个转换是如何工作的。直接从文件中： shuffle() ：根据均匀分布随机划分元素。 rebalance() ：分区元素循环，为每个分区创建相等的负载。有助于在数据倾斜的情况下优化性能。
资料来源：https://ci.apache.org/projects/flink/flink-docs-release-1.2/dev/datastream_api.html#physical-分区
两者都是自动完成的，所以我的理解是它们都是平等地重新分配的( shuffle() >均匀分布和 rebalance() >循环）和随机数据。然后我推断 rebalance() 以更好的方式分发数据（“每个分区的负载相等”），因此任务必须处理相同数量的数据，但是 shuffle() 可能会产生越来越大和越来越小的分区。那么，在哪些情况下您更愿意使用 shuffle() 比 rebalance() ?
我唯一想到的是 rebalance() 需要一些处理时间，因此在某些情况下，它可能需要更多的时间来执行重新平衡，而不是在将来的转换中改进。
我一直在寻找这个，没有人谈论这个，只有在一个邮件列表的Flink，但他们没有解释如何 shuffle() 作品。
感谢斯内夫特尔，他帮助我改进了我的问题，让我重新思考我想问的问题；还有蒂尔，他很好地回答了我的问题d
2条答案
按热度按时间qnakjoqk1#
Flink的这一说法具有误导性：
有助于在数据倾斜的情况下优化性能。
因为它是用来形容
rebalance，但不是shuffle，说明这是区别因素。我的理解是，如果有些项目处理速度慢，而有些项目处理速度快，分区器将使用下一个空闲通道将项目发送到。但事实并非如此，请比较rebalance以及shuffle. 这个rebalance只需添加到下一个频道，不管它有多忙。这个语句也可以有不同的理解：“load”并不意味着实际的处理时间，只意味着项目的数量。如果您的原始分区有偏差（分区中的项数相差很大），那么操作会将项统一地分配给分区。但是在这种情况下，它适用于这两种操作。
我的结论是：
shuffle以及rebalance做同样的事，但是rebalance它的效率稍微高一点。但差别很小，你不可能注意到，java.util.Random可以在我的机器上的一个线程中生成70m个随机数。gkl3eglg2#
如文件所述，
shuffle将随机分发数据rebalance将以循环方式分发数据。后者效率更高，因为您不必计算随机数。此外，根据随机性的不同，最终可能会得到某种不太均匀的分布。另一方面，
rebalance将始终开始将第一个元素发送到第一个通道。因此，如果只有很少的元素（元素比子任务少），那么只有一些子任务将接收元素，因为您总是开始将第一个元素发送到第一个子任务。在流式处理的情况下，这最终应该无关紧要，因为您通常有一个无限的输入流。这两种方法存在的实际原因是历史原因。
shuffle先介绍的。为了使批处理成为更相似的流式api，rebalance然后介绍。