До сих пор я играл с этим довольно долго, и я изо всех сил пытаюсь найти золотую середину в отношении объектов Window в Apache Beam.

Window.into(FixedWindows.of(Duration.standardMinutes(15)))
            .triggering(AfterWatermark
                .pastEndOfWindow())
            .withAllowedLateness(Duration.ZERO)
            .discardingFiredPanes()

Моя первоначальная мысль об объекте Window, который срабатывает каждые 15 минут, была предыдущей. Однако этот подход дает мне droppedDueToLateness. Чтобы решить эту проблему, я подумал: «Хорошо, тогда давайте увеличим допустимые опоздания!».

Изменена следующая строка .withAllowedLateness(Duration.standardMinutes(60)), чтобы поздние события все еще могли попадать в окно.

Однако после внесения этого изменения отброшенные события droppedDueToClosedWindow снова вернулись, а именно тех, которых я пытался избежать в своих первоначальных реализациях! (Не входит в этот вопрос, но не имеет отношения к вопросу).

Сообщения поступают из очереди PubSub с событием отметки времени из самих полезных данных сообщения (атрибут в объекте JSON, а не отметка времени из PubSub).

Любая подсказка, почему это может происходить? Должен ли я просто увеличить ресурсы или все же немного подправить свой объект Window?

0
czr_RR 21 Окт 2019 в 11:14

2 ответа

Не могли бы вы поделиться кодом, в котором вы читаете данные из PubSubIO? Вы использовали withTimestampAttribute метод?

0
Yueyang Qiu 22 Окт 2019 в 09:31
Я не мог использовать это, поскольку события закодированы в байтах, поэтому мне нужно было бы десериализовать их, и все равно это был бы JSON. Для вывода этих отметок времени (при декодировании JSON и получении информации об этом поле) я использую WithTimestamps.of(new SetTimestampFn()).withAllowedTimestampSkew(new Duration(Long.MAX_VALUE)))
 – 
czr_RR
22 Окт 2019 в 10:52