Apache flink - инкрементная контрольная точка - неожиданный размер cp

После добавления некоторого управляемого состояния во время обработки мы заметили тревожный рост размера и продолжительности контрольных точек, несмотря на использование инкрементной контрольной точки с RocksDb.

Чтобы изолировать проблему, мы создали простую топологию с источником, оператором карты и приемником.

Источник создает в памяти произвольное количество событий с пропускной способностью 1 событие в секунду. Каждое событие имеет уникальный идентификатор, который используется для секционированного потока (с использованием оператора keyBy) и проходит через функцию карты, которая добавляет около 100 КБ к управляемому состоянию (используется ValueState). Затем события просто передаются в приемник, который ничего не делает.

Используя описанную выше настройку, мы отправили 1200 событий с интервалом контрольной точки и минимальной паузой, равной 5 секундам. Поскольку события происходили с постоянной скоростью и равным количеством состояний, мы ожидали, что размер контрольных точек будет более или менее постоянным. Однако мы наблюдали линейно растущие пики размера контрольных точек (последний пик имел почти 120 МБ, что близко к размеру всего ожидаемого управляемого состояния) с небольшими контрольными точками между ними. Для мониторинга мы использовали метрику, предоставленную Flink и Prometheus с Grafana, см. Некоторые: графики контрольных точек

Мы хотели бы понять, почему мы наблюдаем пики CP и почему они постоянно растут?

Что является причиной того, что некоторые CP сохраняют ожидаемый размер (около 500 КБ), а некоторые имеют размер, равный всему текущему размеру управляемого состояния, даже если нагрузка постоянна?

Что именно измеряется метрикой lastCheckpointSize при использовании инкрементной контрольной точки?

Будем очень признательны за любые подсказки, объяснения,

Заранее спасибо.

1
0
688
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Инкрементная контрольная точка Flink должна (1) хорошо масштабироваться до очень большого состояния и (2) позволять восстановление с контрольных точек, чтобы быть достаточно эффективным, даже после выполнения миллионов контрольных точек после нескольких недель или месяцев работы. В частности, необходимо периодически объединять / объединять старые контрольные точки, чтобы не приходилось пытаться восстанавливаться из неограниченной цепочки контрольных точек, уходящей в далекое прошлое. Вот почему вы увидите, что некоторые контрольные точки выполняют больше работы, чем другие, даже при постоянной нагрузке. Также обратите внимание, что этот эффект более заметен при тестировании с небольшим количеством состояний (120 МБ - это мало по сравнению с 10+ терабайтами состояния, с которыми, как сообщают некоторые пользователи Flink, работают).

Чтобы понять, как работает инкрементная контрольная точка Flink, я предлагаю посмотреть Выступление Стефана Рихтера из Flink Forward.

Обновлять:

Для тех, кто более знаком с RocksDB, проблема заключается в том, что сжатие RocksDB будет влиять на одни контрольные точки больше, чем на другие, и с небольшим состоянием может происходить довольно редко.

Другие вопросы по теме