Stream объединяет большие окна с Flink

Question

Мне нужно объединить два источника событий на основе ключа. Разрыв между событиями может составлять до 1 года (т. Е. Событие1 с идентификатором1 может прибыть сегодня, а соответствующее событие2 с идентификатором1 из второго источника события может прибыть через год). Предположим, я хочу просто вывести поток объединенного события.

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

Вопросы:

1. Существуют ли какие-либо очевидные ограничения / ловушки при использовании Flink для такого типа соединений в длинном окне? ?

2. Любые рекомендации по обработке такого рода длинных оконных объединений

Связанный: я также изучаю использование Lambda с DynamoDB в качестве состояния для выполненияприсоединения к потоку ( Смежный вопрос ). Я буду использовать управляемые сервисы AWS, если эта информация актуальна.

Answer 1

Очевидная проблема этого варианта использования - большой размер окна соединения в один год и высокая скорость приема, что может привести к огромному размеру состояния.

Основной вопрос здесьявляется ли это объединением 1: 1, т. е. объединяется ли запись из потока A точно (или не более) один раз с записью из потока B. Это важно, потому что, если у вас есть соединение 1: 1, вы можете удалитьзапись из штата, как только она была присоединена к другой записи, и вам не нужно хранить ее в течение всего года. Следовательно, в вашем штате хранятся только записи, которые еще не были объединены. Предполагая, что большинство записей быстро объединяются, ваше состояние может оставаться достаточно маленьким.

Если у вас есть соединение 1: 1, объединение временного окна Flink Table API (и SQL) и интервальное соединениеAPI DataStream не , что вы хотите. Они реализованы как объединения m: n, потому что каждая запись может объединяться с более чем одной записью другого ввода. Следовательно, они хранят все записей за полный интервал окна, т. Е. В течение одного года в вашем случае использования. Если у вас есть соединение 1: 1, вы должны реализовать это соединение как KeyedCoProcessFunction.

Если каждая запись может объединяться несколько раз в течение одного года, буферизация этих записей невозможна. В этом случае вы можете использовать временные объединения API таблиц Флинка (и SQL) и интервальные объединения API DataStream.