Блог

В потоке данных Flink предположим, что вышестоящий оператор размещен на компьютере / диспетчере задач m , Откуда вышестоящий оператор знает компьютер (диспетчер задач), m’ на котором размещен нижестоящий оператор. Устанавливаются ли такие пути потока данных между нижестоящими / восходящими операторами во время первоначального планирования подзадач задания (операторов) JobManager, и такие пути потока данных фиксированы на время жизни приложения?

В более общем плане рассмотрим функции Flink с отслеживанием состояния, в которых поддерживается динамический обмен сообщениями, а поток данных не является фиксированным или предопределенным, и при наличии функции с ключом, k которой необходимо отправить сообщение / событие другой функции с ключом, k’ как функция k найдет адрес функции k’ для отправки сообщения об этом? Сохраняет ли среда выполнения Flink сопоставления между ключами и машинами в некоторой распределенной структуре данных (например, DHT, как в Microsoft Orleans), и каждый вызов функции включает доступ к такой структуре данных?

Обратите внимание, что я пришел из Spark background, где с учетом модели RDD / batch задачи графика заданий выполняются последовательно (разбиты на границы в случайном порядке), и для каждой подзадачи в случайном порядке машинам, содержащим подмножество ключей, которые должны быть извлечены / обработаны этой подзадачей ….

Спасибо.

Даже при использовании функций с отслеживанием состояния топология базового задания Flink фиксируется во время запуска задания. Каждое задание функций с отслеживанием состояния использует график заданий, более или менее подобный этому (входные данные различаются, но остальное всегда похоже на это):

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

Плоские карты, действующие как маршрутизаторы, преобразуют входные сообщения во внутренние конверты событий, которые, по сути, просто оборачивают полезную нагрузку сообщения его логическим адресом назначения. Конверты — это тип данных on-the-wire для всех сообщений, проходящих через график потоков. Среда выполнения функций с отслеживанием состояния сосредоточена на операторе диспетчера функций, который запускает экземпляры всех загруженных функций во всех модулях.

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

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

Как разные экземпляры диспетчера функций отправляют сообщения друг другу?

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

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

Канал обратной связи установлен на контрольную точку; сообщения никогда не теряются в случае сбоя.

Чтобы узнать больше об этом, я рекомендую этот доклад Цу-Ли (Гордон) Тай, посвященный Flink Forward: Функции с отслеживанием состояния: многоязычные функции, управляемые событиями, для распределенных приложений с отслеживанием состояния. Рисунок выше взят из его выступления.