эвристика водяного знака потоковой обработки

Насколько точны оценки водяных знаков при потоковой обработке в Apache Beam или Spark Streaming. Моим источником данных являются файлы из gcs/s3, но я использую время события, связанное с каждым событием, в качестве метки времени для оконной функции. Любые идеи о том, как эта эвристика или оценка вычисляются этими механизмами потоковой обработки, и есть ли способ измерить, насколько плохой была эта оценка.

Мой вариант использования: у меня есть несколько серверов, создающих журналы событий на gcs/S3, а затем я читаю эти файлы в потоковом режиме из моего механизма обработки потоков. Таким образом, это может быть отложено из-за сбоев и сбоев файловой системы или из-за того, что серверы не могут очищать события журнала в течение нескольких часов. Итак, в моем конвейере обработки потоков правильность является одним из важных аспектов при агрегировании некоторых событий. Так что мне любопытно, как вычисляется эта оценка водяного знака




Ответы (1)


Вообще говоря, водяной знак определяется источником. Когда источник объявляет водяной знак T, он говорит: «Я не ожидаю больше записей с временем события раньше, чем T». Затем механизм потоковой передачи может приступить к закрытию соответствующих окон и т. д. Все еще могут быть некоторые события, которые поступают с отметкой времени меньше, чем T, и они будут считаться «поздними». В Apache Beam вы также можете контролировать такие поздние события. Источники в Apache Beam добавляют водяные знаки, реализуя интерфейс getWatermark() (документация там тоже весьма полезна).

В вашем случае важно знать, насколько задержанными могут быть эти файлы. Вы упомянули пару часов. Простой эвристикой может быть сохранение водяного знака на 'latest event time - 2 hours'. Основываясь на ожидаемом распределении задержек, вы можете ограничить это время до 10 минут, чтобы получить максимальную пользу, и рассматривать дальнейшие задержанные события как "поздние".

person Raghu Angadi    schedule 25.01.2018
comment
Я уже использую предварительно реализованный источник. Мои события — это события мобильного приложения, которые регистрируются серверами в корзинах gcs. Итак, как источник файловой системы может иметь какое-либо представление о последней временной метке событий, поскольку все, что он видит, - это время создания файла журнала и ничего не знает о временных метках событий в журналах. - person user179156; 25.01.2018
comment
Какой источник вы используете? Если можно, укажите пример кода. - person Raghu Angadi; 25.01.2018
comment
Я не думаю, что AvroIO поддерживает неограниченное чтение для потокового приложения, у него нет понятия водяного знака (я проверял AvroIO.java). - person Raghu Angadi; 26.01.2018
comment
Я думаю, вы можете читать записи в потоковом режиме, используя watchForNewFiles, а затем readAll - person user179156; 26.01.2018
comment
Я точно знаю, что это можно сделать для FileIO, а затем прочитать файл за файлом, который будет расширен в записи avro. - person user179156; 26.01.2018
comment
Другими словами, вы реализуете неограниченный источник, используя FileIO в качестве утилиты для поиска и извлечения файлов. В этом случае вам также необходимо реализовать «getWatermark()», как указано выше. - person Raghu Angadi; 26.01.2018
comment
Водяной знак зависит от источника данных; в некоторых случаях это оценка. В других, таких как Pub/Sub с назначаемыми системой отметками времени, водяной знак может предоставить точную границу того, какие данные обработал конвейер. - person George; 26.01.2018
comment
@raghu: я думал, что этот неограниченный источник, созданный с использованием fileIO, имеет некоторую реализацию по умолчанию для оценки водяного знака? Если нет, то какой хороший способ использовать imolemnet и какие другие методы мне нужно реализовать, чтобы убедиться, что это работает правильно. Я предположил, что это были потоковые файлы из gcs, которые обрабатывали их все ровно один раз, поэтому у него уже было какое-то понятие водяного знака. - person user179156; 26.01.2018