工会流以不同频率更新后导致消费者滞后

Question

我们使用的是Flink 1.2.1，我们通过将一个流合并为另一个流并处理该合并的流来消耗2个kafka流。 例如 stream1.union（stream2） 但是，stream2的容量是stream1的100倍以上，而我们正在体验的是stream2的耗时巨大（超过3天的数据），但是stream1的耗时很小。 我们已经有9个分区，但其中1个为Parallelism，将会增加parelelism解决stream2的耗时问题，或者在这种情况下我们完全不应该合并。

Answer 1

.union()不应助长时间延迟，即AFAIK。

是的，如果实际上处理方面的滞后是由于消耗您的运算符（或接收器）受到CPU限制，那么增加并行度应该会有所帮助。

如果问题出在接收器端的某些问题无法通过更高的并行度来解决（例如，您正在写入数据库，并且达到最大接收速率），那么增加接收器并行度将无济于事，当然。

Answer 2

是的，请尝试增加stream2源的并行度-它应该可以帮助： env.addSource(kafkaStream2Consumer).setParallelism(9)

当前，您有一个1核的瓶颈，该瓶颈需要跟上消费stream2数据的速度。为了充分利用Kafka的并行性，FlinkKafkaConsumer并行性应为> =它从中消耗的主题分区数。