Допустим, у меня есть A-Event
KStream, объединенный в A-Snapshot
KTable, и B-Event
KStream, объединенный в B-Snapshot
KTable. Ни A-Snapshot
, ни B-Snapshot
не передают нулевые значения (вместо этого события удаления объединяются как атрибут состояния моментального снимка). На данный момент мы можем предположить, что у нас есть постоянная тема журнала изменений kafka и локальное хранилище RocksDB для агрегаций A-KTable
и B-KTable
. Затем моя топология соединит A-KTable
с B-KTable
, чтобы получить объединенное AB-KStream
. Тем не менее, моя проблема связана с жизненными циклами материализации A-KTable
и B-KTable
(как в теме журнала изменений, так и в локальном хранилище RocksDB). Допустим, A-Event
темы и B-Event
стратегии хранения тем были установлены на 2 недели, есть ли способ повлиять на внутреннюю политику хранения темы материализации KTable kafka (журнал изменений и rockDB) с политиками хранения удаления темы исходящего события? В противном случае, можем ли мы настроить материализацию KTable с какой-либо политикой хранения, которая будет управлять как темой журнала изменений, так и жизненным циклом хранилища rockdb? Учитывая, что я не могу явно создавать надгробные плиты A-KTable
и B-KTable
? Я обеспокоен тем, что журнал изменений и локальный магазин будут расти бесконечно,..,
На данный момент KStream не поддерживает готовые функции для внедрения очистки в темы журнала изменений на основе политики хранения исходных тем. По умолчанию используется политика хранения «Компактная».
Для этого есть открытая проблема JIRA: https://issues.apache.org/jira/browse/KAFKA-4212
Один из вариантов — вводить сообщения надгробной плиты, но это нехороший способ.
В случае оконного магазина вы можете использовать политику хранения «сжать, удалить».