Типовой контракт луча для доработки CheckpointMark's - PullRequest
0 голосов
/ 25 марта 2019

Я работаю над конвейером, который читает сообщения от Kafka с использованием KafkaIO, и я смотрю на параметр commitOffsetsInFinalize () и класс KafkaCheckpointMark.

Я хочу достичь хотя бы раз семантики доставки сообщенийи хотим быть уверены, что смещения зафиксированы в Kafka после их записи в какой-то приемник.

Глядя на интерфейс CheckpointMark , неясно, когда ожидается завершение.

Зависит ли это от бегуна, чего ожидать при выполнении на DataflowRunner?

И чтение KafkaIO.Read Javadoc на commitOffsetsInFinalize также не дает ясности в моем понимании, особенно фразы

Но он не предоставляет жестких гарантий обработки

Вопрос: Для чего нужен контракт в модели Beam, когда контрольные отметки должныбудет завершено, есть ли?

Ответы [ 2 ]

1 голос
/ 30 марта 2019

Да, это поведение зависит от бегуна.В DF Runner финализация происходит в потоковых конвейерах после того, как данные были зафиксированы во внутреннем состоянии потока данных.Т.е. когда весь комплект элементов заканчивается обработкой.

На основе описания документа commitOffsetsInFinalize помогает уменьшить повторную обработку, но теперь имеет значение, используется ли она, в любом случае в DF Runner будет хотя бы однажды семантика.

0 голосов
/ 02 апреля 2019

При использовании бегуна Dataflow завершение контрольной точки происходит, как только результаты чтения из источника надежно фиксируются во внутреннем состоянии Dataflow. Это гарантирует единовременную обработку, пока вы обновляете или истощаете свои конвейеры, но не если вы отменяете работающий конвейер. Когда для commitOffsetsInFinalize установлено значение true, это приводит к тому, что Dataflow таким образом фиксирует смещения разделов.

Когда commitOffsetsInFinalize имеет значение false, KafkaIO использует другой, более эффективный способ чтения из Kafka. В этом режиме поток данных (или другие участники) будут сохранять смещения, до которых он считал данные для каждого раздела. В этом режиме не возникает проблема потери данных, поскольку данные не потребляются из Kafka, и новые конвейеры могут точно указывать, где в потоке Kafka начинать чтение

...