Я использую Flink CEP для обнаружения шаблонов событий из Kafka. Для простоты события имеют только один тип. Я пытаюсь обнаружить изменение значения поля в непрерывном потоке событий. Код выглядит следующим образом

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 104 раздела, события распределяются по разделам равномерно. Когда я отправил задание, parallelism было установлено на 104.

В веб-интерфейсе было две задачи: первая - Source->filter->map->timestamp/watermark; второй - CepOperator->sink. Каждая задача получила 104 параллелизма.

Нагрузка по подзадачам была неравномерной, она должна исходить от keyBy. Водяные знаки среди подзадач были разными, но они начали застревать на значении, без изменений долгое время. Из журналов я вижу, что CEP продолжает оценивать события, и сопоставленные результаты отправляются в нижний приемник.

Частота событий составляла 10k / s, и противодавление первой задачи поддерживалось high, а второй - ok.

Пожалуйста, помогите объяснить, что произошло в CEP и как решить проблему.

Благодарность

0
Grant 21 Окт 2020 в 05:40

1 ответ

Лучший ответ

Поразмыслив над вашим вопросом, я пересматриваю свой ответ.

Похоже, что CEP продолжает создавать совпадения, и их выталкивают в приемник, но задача приемника CEP + создает высокое противодавление. Что могло бы помочь, так это определить причину противодавления.

Если события доступны для чтения из всех разделов, и все же водяные знаки едва продвигаются вперед, это звучит так, как будто противодавление достаточно серьезное, чтобы предотвратить прием событий вообще.

Я подозреваю

  1. комбинаторный взрыв усилия в двигателе CEP, и / или
  2. достаточно спичек, чтобы раковина не успевала

Как вероятные причины.

Несколько идей для более глубокого понимания:

(1) Попробуйте использовать профилировщик, чтобы определить, является ли CepOperator узким местом, и, возможно, определить, что он делает.

(2) Отключите цепочку операторов между CepOperator и приемником, чтобы изолировать CEP - просто как шаг отладки. Это даст вам лучшую видимость (с помощью показателей и мониторинга противодавления) того, что делают каждый CEP и приемник.

(3) Протестируйте это на меньшей установке и расширьте ведение журнала CEP.

1
David Anderson 24 Окт 2020 в 07:49