Apache flink 水印在Flink CEP中远远落后

我使用Flink CEP检测卡夫卡事件的模式。为简单起见，事件只有一种类型。我试图检测连续事件流中字段值的变化。代码如下所示

val streamEnv = StreamExecutionEnvironment.getExecutionEnvironment
streamEnv.setStreamTimeCharacteristic(TimeCharacteristic.EventTime)
streamEnv.addSource(new FlinkKafkaConsumer[..]())
          .filter(...)
          .map(...)
          .assignTimestampsAndWatermarks(
            WatermarkStrategy.forMonotonousTimestamps[Event]().withTimestampAssigner(..)
          )
          .keyBy(...)(TypeInformation.of(classOf[...]))
    
val pattern: Pattern[Event, _] = 
          Pattern.begin[Event]("start", AfterMatchSkipStrategy.skipPastLastEvent()).times(1)
          .next("middle")
          .oneOrMore()
          .optional()
          .where(new IterativeCondition[Event] {
             override def filter(event: Event, ctx:...): Boolean = {
                 val startTrafficEvent = ctx.getEventsForPattern("start").iterator().next()
                 startTrafficEvent.getFieldValue().equals(event.getFieldValue())
             }
          })
          .next("end").times(1)
          .where(new IterativeCondition[Event] {
             override def filter(event: Event, ctx:...): Boolean = {
                  val startTrafficEvent = ctx.getEventsForPattern("start").iterator().next()
                  !startTrafficEvent.getFieldValue().equals(event.getFieldValue())
            }
          })
          .within(Time.seconds(30))

Kafka topic有104个分区，事件均匀分布在各个分区上。当我提交作业时，

parallelism

被设置为104

在Web UI中，有两个任务：第一个任务是

Source->filter->map->timestamp/watermark

；第二个是

ceoperator->sink

。每个任务有104个并行性

子任务上的工作负载是不均匀的，它应该来自

keyBy

。子任务之间的水印是不同的，但它们开始停留在一个值上，很长一段时间没有变化。从日志中，我可以看到CEP不断评估事件，并将匹配结果推送到下游接收器

事件发生率为10k/s，第一个任务的背压保持在

high

，第二个任务的背压保持在

ok

请帮助解释CEP中发生了什么以及如何解决问题

---

谢谢你仔细考虑了你的问题，我正在修改我的答案

听起来好像CEP正在继续产生匹配，它们被推到接收器，但是CEP+接收器任务产生了很高的背压。有助于确定背压的原因

如果可以从所有分区读取事件，而水印只是勉强前进，那么听起来背压严重到足以阻止事件被接收

我怀疑

CEP引擎中的组合爆发力，和/或

足够的火柴，水槽跟不上

可能的原因

获得更多洞察力的一些想法：

（1） 尝试使用探查器确定操作员是否是瓶颈，并可能确定它正在做什么

（2） 禁用CEP操作符和接收器之间的操作符链接，以便隔离CEP——这只是一个调试步骤。这将使您更好地了解CEP和水槽各自在做什么（通过指标和背压监测）

---

（3） 在较小的设置中进行测试，并展开CEP日志。

谢谢您的回答。当我检查带有延迟水印的子任务时，我发现该子任务曾经收到过数据。您认为CEP处理该分区中的数据可能会花费太多时间，最终会降低整个作业的速度吗？您是指“从未收到”还是“仍收到”？我是指“仍收到”？实际上我们将事件均匀地分发到kafka分区。调用

keyBy

后，每个键下的事件数不均匀，KeyedStream上的水印以15分钟的间隔和10分钟的超时时间启用了stuckI检查点，但由于超时，无法写出状态