Comments 3
А что если просто kSQL заюзать?
Есть пара моментов:
По модели данных и примеру одному пользователю соответствует несколько доменов, а вот стейты в ProcessFunction сделаны ровно наоборот: по одному user_id предполагается несколько пользователей, но один домен. Скорее всего опечатка.
Второй момент методологический, как мне видится. У вас топики с пользователями и доменами будут всегда читаться разными тредами, поэтому в случае возникновения систематического запаздывания на одном из тредов (с топиком на кафке что-то страшное случилось, тред не успевает вычитывать из-за объема и т.п.) такой джоин будет отдавать состояния, которые никогда не существовали на источнике. Если надо, чтобы все было железно консистентно - писать надо CDC-события в один топик в порядке, в котором отдает СУБД-источник.
Не раскрыта тема применимости данного метода (и вообще любых джойнов в потоке) при условии несовпадения моментов появления данных в СИ. Понятно, что у флинка есть некое "окно", и он в памяти держит сколько-то недавно прочитанных записей - но во-первых, неплохо бы описать настройки этого "окна", а во-вторых как быть если его не хватило? - искать эти "не совпавшие по времени прилета" записи уже в СП? - окей, так можно, но для чего тогда вообще весь этот огород с флинком?
Join таблиц в реальном времени на Apache Flink