Под капотом Flink разделяет процесс чтения файла на две подзадачи, а именно мониторинг каталога и чтение данных. Каждая из этих подзадач реализуется отдельным объектом. ... Роль единственной задачи мониторинга состоит в том, чтобы сканировать каталог (периодически или только один раз в зависимости от watchType), находить файлы, которые нужно обработать, делить их на разбиения и назначать эти разбиения для последующих считывателей. Считыватели - те, кто будет читать фактические данные.
Функция мониторинга находится в ContinuousFileMonitoringFunction
, и она записывает в моментальные снимки максимальное время модификации файла, замеченное до сих пор для файла или каталога. это мониторинг. И каждое из CheckpointableInputFormat
для читаемых разделений файлов записывает их смещения.
Не знаю, почему это не работает так, как вы ожидаете, но, как заметил @YuvalItzchakov, есть полезная регистрация, когда это состояние восстанавливается - и даже больше, если вы включаете ведение журнала уровня DEBUG. Просмотр этих журналов диспетчера задач может показать, что происходит.
Если вы застряли и хотите изучить альтернативные способы начальной загрузки своего состояния перед переходом на кинезис, вы можете использовать API процессора состояний для создания точки сохранения из данных. в этих файлах. Или вы можете использовать API обработчика состояний для проверки состояния уже имеющихся точек сохранения.