Я реализую потоковое приложение, и один из операторов с отслеживанием состояния пытается зафиксировать отношение «владелец имеет элементы». Состояние с ключом для каждого владельца состоит из сведений о владельце и каждом из элементов. Право собственности на элемент может измениться, и я хотел бы иметь возможность связать каждый элемент с его правильным владельцем. Поскольку состояние оператора для разных владельцев может находиться в разных подзадачах, и эти подзадачи предназначены для работы независимо, я хочу знать, как лучше всего делиться состоянием. Одно из решений, которое я смог придумать, заключалось в том, чтобы создать поток данных с ключами из побочного вывода подзадачи и отправить его правильному владельцу и очистить состояние от исходного владельца. По сути:
- Подзадача1 с состоянием о OldOwner, имеющем Item1, Item2,…, ItemN
- Подзадача1 записывает сообщение в побочный вывод (OldOwner, NewOwner, List [ItemsToTransfer])
- (Необязательно) Очистить состояние о List [ItemsToTransfer] из состояния о OldOwner.
- Создайте поток данных из побочного вывода и отправьте его обратно тому же оператору, но потенциально другой подзадаче, которая имеет состояние о NewOwner.
- Обновите состояние NewOwner, добавив новый набор элементов
Поскольку побочные выходы предназначены для совсем другой цели (ведение журнала и т. Д.), Я хочу знать, сработает ли это. Применяются ли к побочным выводам те же гарантии отказоустойчивости, что и к обычным потокам данных? Есть ли ограничение на количество побочных выходных сообщений, которые можно буферизовать в подзадаче?
Альтернативный подход может заключаться в том, чтобы взять результат первой подзадачи и передать его тому же оператору. Оба этих подхода теоретически нарушают свойство, заключающееся в том, что задание flink является DAG, хотя для моего случая использования циклической передачи данных никогда не было бы.
