Комментарии 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