#apache-flink #real-time #flink-streaming
#apache-flink #в режиме реального времени #мерцающий поток #flink-потоковая передача
Вопрос:
Контекст: проект, над которым я работаю, обрабатывает файлы с метками времени, которые создаются периодически (1 минута), и они поступают в режиме реального времени в серию каскадных оконных операторов. Временная метка файла указывает время события, поэтому мне не нужно полагаться на время создания файла. Результат обработки каждого окна отправляется в приемник, который хранит данные в нескольких таблицах.
input -> 1 min -> 5 min -> 15 min -> ...
-> SQL -> SQL -> SQL
Я пытаюсь найти решение для устранения возможного простоя процесса реального времени. Входные файлы генерируются независимо, поэтому в случае серьезного простоя решения Flink я хочу принять и обработать пропущенные файлы, как если бы они были получены одним и тем же процессом.
Моя первая мысль — настроить режим работы одного и того же потока, который считывает только пропущенные файлы и имеет допустимую задержку, которая охватывает самый ранний файл, подлежащий обработке. Однако, как только файл был обработан, гарантируется, что более поздние файлы не будут загружены, поэтому мне не обязательно поддерживать самое раннее окно открытым на протяжении всего процесса, тем более, что может быть много файлов для обработки таким образом. Можно ли что-то сделать с закрытием windows, даже с установленной допустимой задержкой, или, может быть, мне следует вместо этого прочитать все это как пакетную операцию и разделить по метке времени?
Комментарии:
1. Два вопроса: Используете ли вы обработку времени события с водяными знаками? Вы принимаете входные файлы по порядку?
2. Да для обоих: я использую время события, генерируя водяные знаки каждый раз, когда загружается файл, и в текущей схеме можно предположить, что файлы загружаются по порядку, поскольку они генерируются и обнаруживаются по порядку, но если мне нужно реализовать пакетное чтение, я бы загружал их по порядку, да.
Ответ №1:
Поскольку вы принимаете входные файлы по порядку, используя обработку времени события, я не понимаю, почему возникает проблема. Когда задание Flink восстанавливается, кажется, что оно должно быть в состоянии возобновить работу с того места, где оно было прервано.
Если я неправильно понял ситуацию, и вам иногда нужно вернуться и обработать (или повторно обработать) файл с какого-то момента в прошлом, одним из способов сделать это было бы развернуть другой экземпляр того же задания, настроенный только на прием файлов, которые необходимо (повторно) использовать. Не должно быть необходимости переписывать это как пакетное задание — большинство потоковых заданий можно запускать на ограниченных входных данных. И с обработкой времени события это задание обратной засыпки даст те же результаты, как если бы оно выполнялось в (почти) реальном времени.