После добавления некоторого управляемого состояния во время обработки мы обнаружили вызывающее беспокойство увеличение размера и продолжительности контрольных точек, несмотря на использование инкрементной контрольной точки с RocksDb.
Чтобы изолировать проблему, мы создали простую топологию с источником, оператором карты и приемником.
Источник создает в памяти произвольное количество событий с пропускной способностью 1 событие в секунду. Каждое событие имеет уникальный идентификатор, который используется для секционированного потока (с помощью оператора keyBy) и проходит через функцию карты, которая добавляет около 100 КБ к управляемому состоянию (используется ValueState). Затем события просто передаются в приемник, который ничего не делает.
Используя вышеописанную настройку, мы отправили 1200 событий с интервалом проверки и минимальной паузой, равной 5 с. Поскольку события происходили с постоянной скоростью и равным количеством состояний, мы ожидали, что размер контрольных точек будет более или менее постоянным. Однако мы наблюдали линейно растущие пики размера контрольных точек (при этом последний пик имел почти 120 МБ, близкий к размеру всего ожидаемого управляемого состояния) с небольшими контрольными точками между ними. Для мониторинга мы использовали метрику, выставленную Флинком и Прометеем с Графаной, см. Некоторые:
контрольных точек
Мы хотели бы понять, почему мы наблюдаем пики ХП и почему они постоянно растут?
Каковы причины того, что некоторые CP сохраняют ожидаемый размер (около 500 кБ), а некоторые имеют размер вокруг всего текущего размера управляемого состояния, даже если нагрузка постоянна?
Что именно измеряется метрикой lastCheckpointSize при использовании инкрементной контрольной точки?
Любые намеки, объяснения будут высоко оценены,
Заранее спасибо.