пакеты. При этом в агрегационном топике после компактификации (некоторое время до поступления новых пакетов) остаются пакеты с одним и тем же key. Видимо это связано с записями в активном сегменте.
Вопрос: как средствами kafka-streams получать только последнее состояние пакетов (последнюю запись)?
Количество контролирую тaким кодом:
table.toStream()
.groupByKey()
.count()
.toStream()
.print(Printed.toSysOut());
Он выдает такие значения:
[KTABLE-TOSTREAM-0000000015]: 27, 2
[KTABLE-TOSTREAM-0000000015]: 27, 3
где первое число это ключ, второе - count
kafka 2.4.1
нюанс в том, что каждое изменение - отправляется в стрим. каждая итерация не знает, будут ли потом еще записи с этим же ключом. каждое сообщение входного стрима проходит группировку, это приводит к обновлению вашего "батча" с ключом 27, и каждое это изменение попадает в выходной стрим. возможно - вам не нужно иметь уникальные группы (т.е. существование 2 групп с одним ключом допустимо, главное чтобы каждое сообщение было учтено лишь в одной), а просто вы не хотите 2 раза обрабатывать одно и то же значение, но хотите их группировать. тогда, чтобы вести обработку с учетом вашего случая - можно делать оконную функцию. поясню: ведь в момент обработки нового сообщения и добавления его в группу по ключу - группировка, как и стрим, не знает, есть ли в очереди далее еще сообщения с таким же ключом. например, если (с одинаковым ключом 27) пришли сообщения 1,2, а спустя некоторое время - 3, то сначала вы получите в стриме батч с сообщениями 1,2, а потом еще его же, но уже 1,2,3, в виде нового ивента в стриме. может вам стоит группировать и по временному окну? т.е. группировать в батчи не только по ключу, но и по временному окну. самое примитивное - берем tumbling окна по N минут, и аггрегируем все сообщения с одинаковым ключом за этот период. т.к. функция оконная - она позволит в итоге все сообщения, полученные за этот период, собрать в один ивент. и это будет единственным сообщением, что позволит вам учесть каждое сообщение лишь 1 раз, но при этом группировать их, чтобы сократить количество итераций. если же это не подходит - можно размер окна сделать как максимальное время, за которое приходят сообщения с одним ключом. однако в большинстве сценариев такого времени нет или оно слишком большое, чтобы делать оконную функцию такого размера наверняка есть другие способы, но в практике мне хватало таких. может кто еще поделится своими..
Как раз дело в том, что нужны уникальные группы. Окна тоже используются. Весь фокус с настройкой компактификациии: активный сегмент в ней не участвует. Несмотря на малое значение segment.ms и min.cleanable.dirty.ratio в топике вижу не финальный пакет, а финальный и его версии на этапе формирования.
оконная будет в окне собирать ваши батчи,и сбрасывать в конце. т.о. один раз, а не при каждом изменении компакшн не дает никакой гарантии, он не для этого
А если посередине окна выключили свет? Как это будет работать без фикса в топиках?
можно в окно пропущенные сообшения включать ведь оффсет не закреплен
Обсуждают сегодня