Разработка реализации системы для Join таблиц в реальном времени на Apache Flink ( Часть 1 )

[ogregor]

А что если просто kSQL заюзать?

[Akhtem94]

kSQL возможен на простых задачах, но на задачах где надо делать CRUD на state и другие проблемы лучше выбирать более матерые инструменты.

[VasilyMelnik]

Есть пара моментов:

1. По модели данных и примеру одному пользователю соответствует несколько доменов, а вот стейты в ProcessFunction сделаны ровно наоборот: по одному user_id предполагается несколько пользователей, но один домен. Скорее всего опечатка.

2. Второй момент методологический, как мне видится. У вас топики с пользователями и доменами будут всегда читаться разными тредами, поэтому в случае возникновения систематического запаздывания на одном из тредов (с топиком на кафке что-то страшное случилось, тред не успевает вычитывать из-за объема и т.п.) такой джоин будет отдавать состояния, которые никогда не существовали на источнике. Если надо, чтобы все было железно консистентно - писать надо CDC-события в один топик в порядке, в котором отдает СУБД-источник.

[Akhtem94]

1. Да, вы правы. Поправил.

2. Проблем с чтением в разных тредах разные топики нет. Flink гарантирует синхронный вызов processElement1 в том порядке, в котором события доходят до этого оператора при условии, что данные партицируются через .keyBy и упорядочены на upstream операторах - то есть, если у меня события одинакового пользователя приходят в одну и ту же партицию, то эта партиция читается одним тредом и сохраняет порядок в контексте одной партиции, поэтому если в партиции уже упорядочены пользователи, то до потока они дойдут в том же порядке и на следующий оператор отправятся также при условии отсутствия доп. манипуляций.

[Lexi4]

Не раскрыта тема применимости данного метода (и вообще любых джойнов в потоке) при условии несовпадения моментов появления данных в СИ. Понятно, что у флинка есть некое "окно", и он в памяти держит сколько-то недавно прочитанных записей - но во-первых, неплохо бы описать настройки этого "окна", а во-вторых как быть если его не хватило? - искать эти "не совпавшие по времени прилета" записи уже в СП? - окей, так можно, но для чего тогда вообще весь этот огород с флинком?

[Akhtem94]

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