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

标签 bigdata apache-flink partitioning flink-streaming

我正在做我的学士期末项目,该项目是关于 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

最佳答案

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

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

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

关于bigdata - Apache Flink 中 shuffle() 和 rebalance() 的区别,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/43956510/

相关文章:

php - WordPress 批量产品上传 (woocommerce) - 650K

apache-flink - 如何为flink Table而不是Stream设置并行度

algorithm - 对于具有 N 个成员的集合,每个子集的大小为 1 或 2 的集合分区的数量是多少?

apache-spark - Hive无法读取Spark生成的分区 Parquet 文件

hadoop - MapReduce Job 中的排序是在哪里完成的?

apache-spark - 使用 Apache Spark 获取大量时间范围的最快方法是什么?

caching - 在 Redis 中构建这样的数据是否可行且经济?

java - Apache Flink 中通用模式转换的 InvalidTypesException

stream - 如何在 Flink 中使用 ListState 进行 BroadcastProcessFunction

mysql - 如何为mysql Hierarchy 表结构做分区