Комментарии 12
Kafka Streams может умереть и по другой причине: не пойманные исключения в вашем коде.… Второй вариант кажется лучше — совсем не ловить исключение и дать Kafka Streams умереть...
Вот это меня удивляет больше всего — почему они не могут просто откатывать оффсет и репроцесить сообщение, если добавлять счетчик ретраем в метаданные то было бы вообще хорошо. И тогда пользовательский код решал что бы хватит уже ретраить или же продолжаем ретраить пока не подымется база.
А так стримы хороши когда сами в себе :(
особенно если планируете использовать следующий уровень абстракции — KSQL.
А можете поподробнее прокомментировать этот момент? Чем опасен KSQL?
Проблема в том, что такая простота обманчива. Без глубокого понимания, как это работает, она может стать большой проблемой при увеличении нагрузок на систему.
При повышении уровня абстракции всегда приносится в жертву производительность.
В случае с KSQL такая жертва, думаю, будет чересчур велика.
Также уточню, что опыта работы с KSQL в production у нас нет, так что рассуждения выше — это только рассуждения.
Иначе будете неприятно удивлены тем, что при каждом рестарте будет удаляться вся локальная база RocksDB.
А как организована связь RocksDB с разделами темы? На каждый раздел своя база или как-то иначе?
И что происходит, если данных в разделе/теме много и они не помещаются в локальную базу?
И что происходит, если данных в разделе/теме много и они не помещаются в локальную базу?
давайте либо много диска чтобы помещалось либо делаете несколько инстансов на которых бегают стримы и у каждого свой локальный сторадж
Если да, то выглядит это так.
Например, у вас в топике 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 и т.п.
Как же тогда масштабироваться, если на входе много данных?
Все эти особенности легко обнаружить еще на стадии чтения документации. Самое интересное начинается при моделирование таблиц, агрегатов.
Немного моего опыта работы с ksql:
1) Написать запрос для создания агрегата действительно очень легко и быстро. Но сразу возникает вопрос, а как проинициализировать изначальные данные? Часто бывает, что топик-источник либо слишком огромный, чтобы его перечитывать, либо вообще нету данных старее X лет. И в таком случае приходится городить специальный инициализирующий топик агрегат и из-за этого монстра вся модель данных из простой и красивой превращается в что-то сложное и непонятное.
2) Изменения схемы агрегатов практически невозможно, так что если вам необходима будет дополнительная колонка, то скорее всего придется делать новый агрегат. И тут вы либо придете к якорной модели, либо придется выдумывать сложный механизм создания нового агрегата и миграции старых данных.
---
В целом текущее состояние развития технологий в стриминговой обработки пока очень плохо работает с агрегатами для которых необходимо хранить состояние. Если хочется легко и быстро, то пока это только агрегаты с маленьким окном в минуты/часы, максимум день, для которых не нужна история всех данных
Kafka Streams — непростая жизнь в production