KafkaIO withLogAppendTime против withProcessingTime - PullRequest
0 голосов
/ 11 декабря 2018

В документации Beam рекомендуется использовать withLogAppendTime вместо withProcessingTime.Почему это так?

Ответы [ 2 ]

0 голосов
/ 15 декабря 2018

Несколько причин предпочесть обработку времени события:

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

Последовательное, детерминированное поведение - если вы запустите одни и те же данные через один и тот же код, вы получите те же результаты.Это не относится ко времени обработки.Опять же, это облегчает некоторые вещи (например, тестирование).

0 голосов
/ 12 декабря 2018

Как сказал cricket_007, это зависит от вашего варианта использования.

Одной из ключевых концепций в Beam является обработка времени события.Таким образом, вы можете определить свою логику обработки данных не с точки зрения того, когда служба (конвейер Beam) получает данные, а с точки зрения того, когда событие действительно произошло (например, когда пользователь фактически нажал на объявление).Это помогает в случаях потоковой передачи, когда ваши потоки данных могут содержать поздние или неупорядоченные события.Beam позволяет вам обрабатывать эти случаи.

Например, если в вашем конвейере есть шаг, который делает что-то вроде "агрегатных событий, которые произошли между 13:00 и 14:00 23 октября 2018 г." , что произойдет, еслиСобытие, которое действительно произошло в 13:30, наступает поздно (скажем, в 15:30) из-за некоторых сетевых задержек или чего-то еще?В подходе, основанном на времени обработки, это позднее событие, вероятно, будет учитываться в следующем окне (например, «14:00 - 15:00»).Но есть большая вероятность, что ваша бизнес-логика предпочтет пересчитать исходную агрегацию «с 13:00 до 14:00» вместо использования позднего события в другой агрегации.Обработка бизнес-кейсов, как это, является основной причиной обработки времени события.

Однако вам может быть неинтересно обрабатывать это в вашей бизнес-логике, например, если вы не выполняете какие-либо работы с окнами / агрегатами (например, базовые ETL) или если у вас вообще нет запоздалых данных (например, когда вы читаете из существующего файла), или ваша бизнес-логика просто не заботится об этом, или события редки, а доставка достаточно надежна, или выможет не иметь надежной метки времени, доступной вам в данных о событиях, и т. д. и т. д. и т. д. Поэтому вы можете вместо этого использовать время обработкиВсе зависит от того, как ваша бизнес-логика нуждается в обработке данных.

Метки времени события назначаются близко к источнику события в Beam (обычно в IO), поэтому в случае Kafka у вас есть эти варианты, чтобы выбрать, где событиеметка времени прибывает из: https://beam.apache.org/releases/javadoc/2.8.0/org/apache/beam/sdk/io/kafka/TimestampPolicy.html.Другие источники могут использовать другие способы назначения временных меток для событий (например, PubsubIO может читать временную метку, указанную в атрибутах сообщения).

Я рекомендую просмотреть презентации здесь, они углубляются в эту тему: https://beam.apache.org/documentation/resources/

...