Flink 中并行和多应用的区别
Differences between parallelism and multiple apps in Flink
我打算动态扩展 up/down Flink 应用程序。该应用使用 kafka-flink 连接器使用来自 Kafka 的事件。
由于应用程序的 "warm up" 需要几分钟（缓存...）并且更改并行度涉及重新启动，我更愿意提交（扩大）或杀死（缩小）任务而不是更改并行度。
请问从性能、逻辑和执行计划上，这种方式和Flink自带的并行执行有什么区别吗？
换句话说，10 个相同的 Flink 任务与一个并行度为 10（env.setParallelism(10)）的任务有什么区别？
如果任务是 Redistributing or not
，则并行数将受到影响
- 一对一流（例如在 Source 和 map() 之间
上图中的运算符）保留分区和排序
的元素。这意味着 map() 运算符的 subtask1
将以相同的顺序看到相同的元素，因为它们是由
Source 运算符的子任务1。
- 重新分配流（如上面的 map() 和 keyBy/window 之间，如
以及 keyBy/window 和 Sink 之间）更改分区
溪流。每个算子子任务向不同的目标发送数据
子任务，具体取决于所选的转换。例子是
keyBy()（通过散列键重新分区）、broadcast() 或
rebalance() （随机重新分区）。在重新分配
exchange 元素之间的顺序只保留在
每对发送和接收子任务（例如，subtask1
map() 和 keyBy/window 的子任务 [2]）。所以在这个例子中，
每个键内的顺序被保留，但并行性确实
引入关于聚合顺序的非确定性
不同键的结果到达接收器。
我打算动态扩展 up/down Flink 应用程序。该应用使用 kafka-flink 连接器使用来自 Kafka 的事件。
由于应用程序的 "warm up" 需要几分钟（缓存...）并且更改并行度涉及重新启动，我更愿意提交（扩大）或杀死（缩小）任务而不是更改并行度。
请问从性能、逻辑和执行计划上，这种方式和Flink自带的并行执行有什么区别吗？
换句话说，10 个相同的 Flink 任务与一个并行度为 10（env.setParallelism(10)）的任务有什么区别？
如果任务是 Redistributing or not
，则并行数将受到影响- 一对一流（例如在 Source 和 map() 之间 上图中的运算符）保留分区和排序 的元素。这意味着 map() 运算符的 subtask1 将以相同的顺序看到相同的元素，因为它们是由 Source 运算符的子任务1。
- 重新分配流（如上面的 map() 和 keyBy/window 之间，如 以及 keyBy/window 和 Sink 之间）更改分区 溪流。每个算子子任务向不同的目标发送数据 子任务，具体取决于所选的转换。例子是 keyBy()（通过散列键重新分区）、broadcast() 或 rebalance() （随机重新分区）。在重新分配 exchange 元素之间的顺序只保留在 每对发送和接收子任务（例如，subtask1 map() 和 keyBy/window 的子任务 [2]）。所以在这个例子中， 每个键内的顺序被保留，但并行性确实 引入关于聚合顺序的非确定性 不同键的结果到达接收器。