так это, я хочу файл получить от пользователя, условно его распарсить, вытащить нужную мне инфу, а потом складировать в тот же S3.

Понятно, что в этом случае для передачи через очередь файл придётся бить на чанки какого-то там размера.

Меня интересует адекватность самого подхода

Только бить на чанки а потом собирать

Кафка это много маленьких сообщений быстро

само собой, да. на стороне сервиса потом соберу воедино и ок будет

Ну в этом случае с точки зрения Кафка это не гигабайт, а тысяча сообщений по мегабайту

совершенно верно. мне просто интересно, нормальные люди используют такой подход или нет

само собой внутри системы я больше швыряться файлами не собираюсь за зря

За нормальных не знаю, но мне, например, пришлось так сделать

Единственный канал был.

Работает

А почему тогда не сделать вариант,  что пользователь нужную инфу в очередь, а файл в s3?

Чисто академический интерес

Дробить большие файлы на мелкие, наверное будет греть CPU.
Плюсом потом ещё на конечном устройстве это все собирать,  что бы вытащить кусочек

Да это какой-то очень странный кейс

Или если все через очередь хочется, то просто не допускать накопления одного файла в 100мб. Пусть клиент при формировании файла сразу же кусками шлёт.

Собственно так и собираюсь сделать

привет, еще есть вопросы по SMT
можно ли имея один источник в реляционной БД (конкретная таблица со значениями что искать и на что менять)
использовать в SMT для всех входящих значений пар ключь значение, до попадания в кафку топик

т.е. например в нашей таблице очень много значений, среди них известно что слово Андрей надо менять на слово Василий, цифру в тексте 12 меняем на 15



в SMT приходит сообщение с текстом "Андрей купил 12 яблок"
в топик должна сесть запись как "Василий купил 15 яблок"

это возможно реализовать на SMT
или надо это делать с помощью KSQL и уже создавать новый топик

?

оказывается закоммитили и ридми появился на гитхабе, а то упирался в 1 МБ при репликации и никак победить не мог, в КИПах как и в доке как всегда ничего актуального нет, может кому полезно будет

Producer / Consumer / Admin Config used by MM2
In many cases, customized values for producer or consumer configurations are needed. In order to override the default values of producer or consumer used by MM2, target_cluster_alias.producer.producer_config_name, source_cluster_alias.consumer.consumer_config_name or cluster_alias.admin.admin_config_name are the formats to use in MM2 configuration. For example,

 backup.producer.compression.type = gzip
 backup.producer.buffer.memory = 32768
 primary.consumer.isolation.level = read_committed
 primary.admin.bootstrap.servers = localhost:9092