Как стать автором
Обновить

Комментарии 12

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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

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


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

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

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

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

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

Все эти особенности легко обнаружить еще на стадии чтения документации. Самое интересное начинается при моделирование таблиц, агрегатов.
Немного моего опыта работы с ksql:

1) Написать запрос для создания агрегата действительно очень легко и быстро. Но сразу возникает вопрос, а как проинициализировать изначальные данные? Часто бывает, что топик-источник либо слишком огромный, чтобы его перечитывать, либо вообще нету данных старее X лет. И в таком случае приходится городить специальный инициализирующий топик агрегат и из-за этого монстра вся модель данных из простой и красивой превращается в что-то сложное и непонятное.
2) Изменения схемы агрегатов практически невозможно, так что если вам необходима будет дополнительная колонка, то скорее всего придется делать новый агрегат. И тут вы либо придете к якорной модели, либо придется выдумывать сложный механизм создания нового агрегата и миграции старых данных.

---

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

Зарегистрируйтесь на Хабре , чтобы оставить комментарий