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