Кластер из 10 брокеров

Я просто не знаю, какие тут могут быть подводные камни. Вот и спрашиваю

В чем мотивация для такого количества партиций? Есть лимиты ОС на количество открытых файлов для процесса, метаданные по лидерам/оффсетам для консьюмеров где-то лежат и пухнут. Сколько реально хочется консьюмеров?

Консьюмеров будет не так много, 10-12 я думаю. Но такое количество партиций нужно не потому, что много констюмеров, а потому что нужен компактед топик, в котором лежат данные, которые со временем могут неравномерно расти. Если неравномерность в партициях будет сильной, то придётся создавать новый топик с новым разбиением, а часто этого делать не хочется. Поэтому хочется сделать большой запас — если партиций будет много, то данные размажутся довольно сильно, и неравномерность будет сглажена.

Ну я же не 100к хочу, а условно 1000 на один топик. И это будет только один такой жирный топик

проблема не столько в разрезе партиций на топик, а в разрезе партиций на кластер

Сейчас 2600 партиций (6700 с учётом репликации) на 10 брокеров. Я планирую добавить 750 партиций с репликацией 3, то есть ещё 2250 партиций. Получится условно 9к на 10 брокеров. Одному нужно менеджить менее 1000 партиций.

Вроде в статейках пишут что это вообще не смертельно

Меня больше пугает увеличение количества памяти на консьюмерах.

Вопрос, для тех кто работал c JDBC Sink connector - использую для конверсии ключа обычный StringConverter, pk.mode - record_key.
В ключе лежит обычная строка - test
Почему может ломаться с

Field(s) from the record key are used, which may be a primitive or a struct

Привет.
Есть теоритическая проблема
Топик. 10 партиций. В консьюмер группе 10 консьюмеров.
Консьюмеры залагали. Consumer лаг увеличился.
Консюмеры пофиксили. Но лаг то остался.
Каким образом можно уменьшить лаг?
Консьюмер группа работает медленее чем сообщения поступают сообщения. Или быстрее но не сильно. И по рассчетам лаг будет уменьшаться часов 5-6.

Пока я понял что никак.

Ахиллес и черепаха :)

Если сообщения не нужны, то резетнуться на конец очереди

А так если их нужно отпроцессить то никак, только добавить ресурсов в процессоры

Только нужно учесть, что добавлять ещё консьюмеров не имеет смысла (т.к. всего 10 партиций и уже 10 консьюмеров). Но можно добавить партиций и все новые сообщения уже будут попадать в 20 партиций.

просто добавить партиций и консьюмеров? И пофиг что в старых партициях 100500 сообщений, а в новых мало?

Повысится пропускная способность системы.

Условно, такая ситуация - нормальная?

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

Спасибо

Смотря что считать нормальным.