контрольная точка flink для больших исходных данных

Я использую приложение потоковой передачи flink с источником ввода в качестве файловой системы nfs и приемником в качестве производителя kafka.

Я использую функцию непрерывного мониторинга, которая пересылает разделение файлов, которое не поддерживает терминологию, и ContinousFileOperator с терминологией.

Исходные данные, которые у нас есть, это 4 ТБ данных. для начальной передачи функции Continousmonitor требуется много времени, чтобы подготовить состояние, что нормально, но контрольные точки продолжают истекать до их завершения. Я изменил checkpointingTimeout на 3 часа, но все равно не работает.

Могу ли я узнать, что состоит из состояния контрольной точки, имеет ли значение размер данных?

Могу я узнать, как я могу определить размер штата?

Есть ли лучший способ для первоначального запуска с большими данными?


person VSK    schedule 13.04.2020    source источник
comment
Сколько там файлов? Я думаю, что это гораздо более узкое место.   -  person David Anderson    schedule 14.04.2020
comment
Сейчас я работаю с 3 миллионами файлов в своей тестовой среде, в prod их больше. Есть ли способ принудительно создать моментальный снимок, когда файлы до времени модификации не будут перенаправлены в continuousfileoperator?   -  person VSK    schedule 14.04.2020


Ответы (1)


Я сильно подозреваю, что причиной низкой производительности является большое количество файлов, обрабатываемых одним экземпляром функции непрерывного мониторинга.

Вместо того, чтобы пытаться справиться со всем этим с помощью одного экземпляра вашего конвейера, я бы попытался создать несколько независимых конвейеров, каждый с источником, который обрабатывает часть файлов. Это может быть выполнено в виде отдельных заданий, но это не обязательно: у вас может быть одно задание, содержащее множество источников и приемников.

person David Anderson    schedule 16.04.2020