У меня задание flink (scala), которое в основном читает из kafka-topic (1.0), агрегирует данные (окно переворачивания времени события 1 минута) с использованием функции fold , которая, как я знаю, устарела, но проще в реализации, чем агрегатная функция), и записывает результат в 2 различные темы kafka.
Вопрос в том, что когда я использую бэкэнд состояния FS, все работает гладко, контрольные точки берут 1-2 секунды, со средним размером состояния 200 мегабайт, то есть до тех пор, пока размер состояния не увеличится (например, при закрытии разрыва).
Я подумал, что для контрольных точек я бы попробовал rocksdb (через hdfs)- но пропускная способность ЗНАЧИТЕЛЬНО меньше, чем у бэкэнда состояния fs.Насколько я понимаю, flink не нуждается в ser / deserialize для каждого доступа к состоянию при использовании fs state backend, потому что состояние сохраняется в памяти (куча), качает db DOES, и я предполагаю, что именно это и объясняет замедление (и обратное давление, и контрольные точки занимают НАМНОГО дольше, иногда время ожидания через 10 минут).
Тем не менее, бывают ситуации, когда состояние не может поместиться в памяти, и я пытаюсь выяснить, в основном, как заставить обработчик состояния rockdb state выполнять"лучше".
Это из-за устаревшей функции сгиба?Нужно ли настраивать некоторые параметры, которые не легко найти в документации?какие-нибудь советы?