VG
Size: a a a
2020 September 22
S
Привет!
Кто-то пилил rules engine на Kafka Streams?
Какой подход применяли?
Мы думаем как бы красивее реализовать систему алертинга, которая простыми конфигами натравливается на нужные метрики
Кто-то пилил rules engine на Kafka Streams?
Какой подход применяли?
Мы думаем как бы красивее реализовать систему алертинга, которая простыми конфигами натравливается на нужные метрики
Может вам всё же систему мониторинга+timeseries db? Influx, Grafana, Premetheus из того, что я юзал. Мне кажется, кафку не надо для этого использовать.
S
Kafka это pull-модель, RabbitMQ и вся классика очередей - это push. Постоянно консультирую фирмы на эту тему и очень не советую мыслить одно как другое. Если вы хотите к каждому сообщению относиться как-то индивидуально (e.g. Rule engine, BPM), то используйте классику, зачем вы используете Кафку? Вы всё равно её убьёте своими процессами. Она для производительности, а не для правил.
IR
мб они хотят производительных правил =)
V
Kafka это pull-модель, RabbitMQ и вся классика очередей - это push. Постоянно консультирую фирмы на эту тему и очень не советую мыслить одно как другое. Если вы хотите к каждому сообщению относиться как-то индивидуально (e.g. Rule engine, BPM), то используйте классику, зачем вы используете Кафку? Вы всё равно её убьёте своими процессами. Она для производительности, а не для правил.
ну будет несколько инстансов rule engine как это убьет кафку?
S
Возможно, у нас еще случился рассинхрон в терминах)
Вероятно )
Вы, наверное, говорите про так называемые reaction rules, по сути простейшие правила.
Проблема правил в том, что они часто имеют структуру сложного логического дерева, если то, то сё, а если нет, то это. Плюс в BPM ещё и сходи сначала туда, потом отсюда возьми результат. Всё это можно сделать на кафке, если нужна и производительность/масштабируемость и правила, но будьте готовы к миллиарду топиков и микросервисов, чтобы всю эту логику максимально развязать. А потом ещё в вашей организации придётся всем бизнес-аналитикам и программистам мозг сломать, чтобы понять, зачем ТАК ;)
Вы, наверное, говорите про так называемые reaction rules, по сути простейшие правила.
Проблема правил в том, что они часто имеют структуру сложного логического дерева, если то, то сё, а если нет, то это. Плюс в BPM ещё и сходи сначала туда, потом отсюда возьми результат. Всё это можно сделать на кафке, если нужна и производительность/масштабируемость и правила, но будьте готовы к миллиарду топиков и микросервисов, чтобы всю эту логику максимально развязать. А потом ещё в вашей организации придётся всем бизнес-аналитикам и программистам мозг сломать, чтобы понять, зачем ТАК ;)
I
Добрый день! Подскажите, при использовании стримов можно автоматически делать репартишн топиков, на основе чего принимается решение по репартишн и итоговому количеству?
"Kafka Streams optimizations are an attempt to automatically make Kafka Streams applications more efficient by reorganizing a topology based on the inital construction of the Kafka Streams application. Right now there are two possible optimizations, reusing the source topic as a changelog topic for a KTable created directly from an input topic. The second optimization is merging multiple repartiton topics into one repartition topic when there mulitple grouping or join operations after a key-changing operation."
"Kafka Streams optimizations are an attempt to automatically make Kafka Streams applications more efficient by reorganizing a topology based on the inital construction of the Kafka Streams application. Right now there are two possible optimizations, reusing the source topic as a changelog topic for a KTable created directly from an input topic. The second optimization is merging multiple repartiton topics into one repartition topic when there mulitple grouping or join operations after a key-changing operation."
VG
VG
Добрый день! Подскажите, при использовании стримов можно автоматически делать репартишн топиков, на основе чего принимается решение по репартишн и итоговому количеству?
"Kafka Streams optimizations are an attempt to automatically make Kafka Streams applications more efficient by reorganizing a topology based on the inital construction of the Kafka Streams application. Right now there are two possible optimizations, reusing the source topic as a changelog topic for a KTable created directly from an input topic. The second optimization is merging multiple repartiton topics into one repartition topic when there mulitple grouping or join operations after a key-changing operation."
"Kafka Streams optimizations are an attempt to automatically make Kafka Streams applications more efficient by reorganizing a topology based on the inital construction of the Kafka Streams application. Right now there are two possible optimizations, reusing the source topic as a changelog topic for a KTable created directly from an input topic. The second optimization is merging multiple repartiton topics into one repartition topic when there mulitple grouping or join operations after a key-changing operation."
Надо кип искать. Пока зацепка только KIP-295. А в чем собственно вопрос - понять какие оптимизации Kstreams делают?
I
Надо кип искать. Пока зацепка только KIP-295. А в чем собственно вопрос - понять какие оптимизации Kstreams делают?
да, хотелось бы понять механизм, т.е. если делается репартишн, то добавляются избыточные топики, означает ли это, что будет пропорциональный рост объёма данных на диске?