Добрый день. Нормально ли использовать Kafka Connect для передачи данных в\из собственных сервисов? Кратко о юзкейсе: имеется несколько терминалов ручного ввода данных (софт наш) и некая мастер-система (может быть как наша, так и внешняя), необходимо из мастер-системы передавать справочники на терминалы и изменения с терминалов обратно в мастер-систему. Терминалы могут работать автономно, без мастер-системы, в этом случае справочники на терминалах редактируют руками (коллизии при появлении мастер-системы для данного примера не важны, главное, что терминалы не привязаны жёстко к другим системам). Думал про что-нибудь простое типа Rabbit'а, но во-первых, Кафка уже используется для других сервисов, и плодить зоопарк не хочется, во-вторых, могут появляться новые терминалы, которые с минимальными усилиями должны подключаться к системе и получать полные справочники, в-третьих, нужно интегрироваться с внешними системами, которые невозможно доработать, и тут бы хорошо зашли коннекторы кафка коннекта. Как я вижу, есть три варианта решения:
1. Использовать в собственных сервисах Consumer\Producer API. Не нравится тем, что как мастер-система, так и терминалы могут работать автономно, даже не зная о Кафке. Следовательно придётся поддерживать два режима работы. Также придётся использовать распределенные транзакции или создавать какие-то собственные очереди на отправку и обработчики, отправляющие данные в кафку. И всё это никак не помогает связаться с внешними системами, для которых все равно надо будет писать отдельный сервис или коннектор, как в следующих вариантах
2. Написать отдельные сервисы, использующие Consumer\Producer API, и работающие как посредники между Кафкой и системами. Из плюсов - легко написать необходимую нам логику. Минусы - сложность в поддержке, мониторинге, организации отказоустойчивости, и т.д., в общем всё то, что даёт кафка коннект
3. Собственно, Кафка Коннект с кастомным rest-коннектором для наших сервисов и JDBC\Debezium\кастомным для внешних систем. Может даже JDBC подойдёт и для наших систем. Минус - все равно надо будет писать свои сервисы для трансформации данных между системами, но это уже можно сделать или на кафка стримах, или на каком-нибудь флинке\спарке, должно быть все равно проще и удобнее, чем п.2.
В недавнем митапе Леруа Мерлена был похожий доклад, но там как я понял все системы были внешними, то есть п.1 не подходил.

Добрый день! Есть задача сохранять данные из топика в файл. Хочу использовать для этого Kafka connect file sink. Возник только один вопрос: можно ли настроить синк так, чтобы он создавал новый файл, например, каждый день или по достижению определённого размера?

лидер кто?

Welcome! Откуда вестимо?

Большая часть - начинающие коллеги по направлению bigdata. Привет из Алматы))

Привет!

Привет!
В Schema Registry есть тип compatibility - FORWARD_TRANSITIVE. Указано что используя его можно удалять optional поля, как можно указать что поле optional в avro schema?

мониторить кол-во produced сообщений в топик?
> Можно ли быть уверенным, что если мне поступают сообщения из спец. топика с ожидаемой частотой, то и с целевыми топиком/партицией тоже все ок?
это не гарантируется. они могут быть находиться на разных брокерах, например.
и еще, было бы не плохо понимать какие действия предполагается совершать ?
это такой backpressure или что-то больше ?