Потоки Кафки - объединение потоков, когда события могут происходить далеко друг от друга во времени - PullRequest
0 голосов
/ 04 апреля 2020

Я хотел бы попросить вашего совета о том, как я мог бы составить решение для следующей проблемы с Kafka Streams.

Приложение имеет предметы и уроки, и оно запускает следующие события:

LessonCreated      SubjectCreated     LessonAddedToSubject   LessonRemovedFromSubject
 +----------+     +--------------+     ---------------+         +--------------+
 | Id  Hours|     |      Id      |     |Lesson|Subject|         |Lesson|Subject|
 | ---+---- |     +--------------+     +--------------+         +--------------+
 | 25 | 20  |     |      1       |     |  25  |   1   |         |  25  |   1   |
 | 26 | 40  |     |      2       |     |  26  |   1   |         |  26  |   2   |
 | 27 | 10  |     |      3       |     |  26  |   2   |         +------+-------+
 +----+-----+     +--------------+     |  26  |   3   |         
                                       |  27  |   3   |         
                                       |  27  |   1   |         
                                       +------+-------+

Я хотел бы реализовать поток, который будет принимать эти потоки и объединять их в следующую структуру:

   LessonSubjectHours
 ---------------------+
 |Lesson|Subject|Hours|
 +--------------------+
 |  26  |  1    | 40  |
 |  26  |  3    | 40  |
 |  27  |  3    | 10  |
 |  27  |  1    | 10  |
 +--------------------+

Я думал о создании некоторой логики c с операциями соединения, но я полагаю, что это может не помочь, поскольку соединения KStream-KStream, по-видимому, принудительно ограничены по времени (если я правильно понял). Это связано с тем, что события lessonCreated, lessonAdded и lessonRemoved могут происходить бесконечно далеко друг от друга во времени. Таким образом, я боюсь, что оконные объединения могут привести к неверным результатам, когда одно из этих событий происходит слишком долго после того, как было выпущено последнее событие, содержащее тот же ключ.

Выполнение полного поиска объединения не должно быть проблемой производительности, поскольку эти события не должны происходить слишком часто. Но, тем не менее, я не имею ни малейшего понятия о том, как действовать дальше, предполагая, что в Кафка-Стримс можно правильно решить эту проблему. Так что любые советы будут оценены.

Заранее спасибо.

PS: Все еще можно изменить события и содержащиеся в них данные, если это поможет.

Ответы [ 2 ]

2 голосов
/ 04 апреля 2020

Кажется, ваши данные в основном табличные. Следовательно, мне интересно, если чтение тем как KStream на самом деле правильный подход, и если вы должны обрабатывать данные как KTable? Для этого случая вы можете просто присоединиться к таблице.

1 голос
/ 04 апреля 2020

KTable с локальным состоянием (RockDb работает быстро) будет правильным выбором.

...