Поток Flink присоединяется к таблице измерений, которая может возвращать большой набор результатов

Question

У меня есть поток событий, который необходимо дополнить информацией о подписке. Некоторые события являются вещательными событиями, это означает, что когда такие события получены, мне нужно go таблица базы данных, найти всех подписчиков события, в моем случае это может быть 10000 строк, а затем преобразовать одно вещательное событие до 10 000 уведомлений. Для обычного типа события есть дополнительный ключ user_id, который можно использовать для присоединения к таблице подписки, которая не имеет проблемы.

Задачи:

• , как подключить большой ResultSet, вернуть их в память, не похоже на масштабируемое решение. Есть ли способ разделить это на множество параллельных задач меньшего размера?
• как я могу организовать конвейер обработки таким образом, чтобы обычное событие и событие широковещания не мешали друг другу. Я не хочу, чтобы последовательные длительные широковещательные события блокировали конвейер обработки нормальных событий.

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

Answer 1

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

В качестве альтернативы вы можете использовать asyncIO, который, в частности, предназначен для взаимодействия с внешние системы. Недостатком asyncIO является то, что в настоящее время все результаты всех активных запросов должны помещаться в основную память. Но это должно быть жизнеспособно для 10_000 строк, особенно если учесть, что соответствующие события происходят довольно редко.