我计划动态放大/缩小flink应用程序。应用程序使用kafka-flink连接器使用kafka的事件。
由于应用程序的“预热”需要几分钟（缓存…）并且更改并行级别需要重新启动，因此我更喜欢提交（放大）或终止（缩小）任务，而不是更改并行级别。
从性能、逻辑和执行计划来看，这种方法和flink内置的并行执行有什么区别吗？
换句话说，10个相同的flink任务与一个并行级别为10（env.setparallelism（10））的任务有什么区别？
我计划动态放大/缩小flink应用程序。应用程序使用kafka-flink连接器使用kafka的事件。
由于应用程序的“预热”需要几分钟（缓存…）并且更改并行级别需要重新启动，因此我更喜欢提交（放大）或终止（缩小）任务，而不是更改并行级别。
从性能、逻辑和执行计划来看，这种方法和flink内置的并行执行有什么区别吗？
换句话说，10个相同的flink任务与一个并行级别为10（env.setparallelism（10））的任务有什么区别？
1条答案
按热度按时间5ssjco0h1#
如果任务正在重新分配或没有重新分配，则并行数将受到影响
一对一流（例如上图中的source和map（）操作符之间）保留了元素的分区和顺序。这意味着map（）操作符的subtask1将以与源操作符的subtask1相同的顺序看到相同的元素。
重新分配流（如上面的map（）和keyby/window之间，以及keyby/window和sink之间）会更改流的分区。每个操作符子任务将数据发送到不同的目标子任务，具体取决于选定的转换。例如keyby（）（通过散列键重新分区）、broadcast（）或rebalance（）（随机重新分区）。在重新分配交换中，元素之间的顺序仅保留在每对发送和接收子任务中（例如，map（）的子任务1和keyby/window的子任务[2]）。因此在本例中，每个键内的顺序都被保留，但是并行性确实引入了关于不同键的聚合结果到达接收器的顺序的不确定性。