Kafka Streams — непростая жизнь в production

[darkit]

Kafka Streams может умереть и по другой причине: не пойманные исключения в вашем коде.… Второй вариант кажется лучше — совсем не ловить исключение и дать Kafka Streams умереть...

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

А так стримы хороши когда сами в себе :(

[sintez]

особенно если планируете использовать следующий уровень абстракции — KSQL.

А можете поподробнее прокомментировать этот момент? Чем опасен KSQL?

[Maxilect]

У KSQL “под капотом” всё та же kafka-streams. То есть все проблемы, которые я описал выше, имеют место быть и в случае с KSQL. Но при этом KSQL внешне выглядит ещё проще: вроде бы просто написал SQL запрос и радуйся.
Проблема в том, что такая простота обманчива. Без глубокого понимания, как это работает, она может стать большой проблемой при увеличении нагрузок на систему.
При повышении уровня абстракции всегда приносится в жертву производительность.
В случае с KSQL такая жертва, думаю, будет чересчур велика.
Также уточню, что опыта работы с KSQL в production у нас нет, так что рассуждения выше — это только рассуждения.

[maxim_ge]

Иначе будете неприятно удивлены тем, что при каждом рестарте будет удаляться вся локальная база RocksDB.

А как организована связь RocksDB с разделами темы? На каждый раздел своя база или как-то иначе?

И что происходит, если данных в разделе/теме много и они не помещаются в локальную базу?

[darkit]

И что происходит, если данных в разделе/теме много и они не помещаются в локальную базу?

давайте либо много диска чтобы помещалось либо делаете несколько инстансов на которых бегают стримы и у каждого свой локальный сторадж

[maxim_ge]

Количество инстансов со стримами чем-то ограничено (partitions?)?

[darkit]

и да и нет.
у вас активных консюмеров топика не может быть больше чем кол-ва партишинов. но вы можете держать про запас у вас могут быть разные топики и следовательно кафка распределит консюмеров по ним.

[Maxilect]

Под разделами темы вы имеете ввиду партиции топика кафки?
Если да, то выглядит это так.
Например, у вас в топике 10 партиций и топик читают две ноды kafka streams.
Каждая нода берёт себе по 5 партиций. Соответственно у каждой ноды в её локальной базе RocksDB будут данные только с этих 5 партиций.
При условии, что ноды находятся в одной consumer-группе, естественно.
Если данные не умещаются в локальную базу, то будете получать стандартные для этого исключения: no space left on device, GC overhead limit exceeded и т.п.

[maxim_ge]

Под разделами темы вы имеете ввиду партиции топика кафки?

Если точнее, я имею ввиду такую терминологию:

• Тема — Topic
• Раздел — Partition

См. здесь или здесь.

Если данные не умещаются в локальную базу, то будете получать стандартные для этого исключения: no space left on device, GC overhead limit exceeded и т.п.

Как же тогда масштабироваться, если на входе много данных?

[darkit]

Как же тогда масштабироваться, если на входе много данных?

бейте на много партишинов ваш топик

[Maxilect]

Вы можете добавить ещё серверов с kafka-streams. Например, если у вас будет 5 серверов вместо 2, то в моём примере на каждого будет приходиться по 2 партиции и, соответственно, в 2,5 раза меньше данных.