Modern capabilities of humanity in the fields of hardware and software have reached a level where real-time decision-making has become possible with an instant response to new events entering the system. One of the key features of such systems is their ability to JOIN stream events in real-time and conveniently utilize this capability through the SQL, integrating it with other stages of event processing using this query language. This presentation will immerse the viewer in the journey of developing such a non-trivial feature.

1. STREAM TO STREAM JOIN
in distributed stream processing platform
1

2. STREAM TO STREAM JOIN
in distributed stream processing platform
Sasha Syrotenko
Kyiv, September 2023
2

3. 3

4. Мої вітання, колеги!
Перед вами Сашко
Працюю більше 2.5 років у Hazelcast
Крафчу ПЗ професійно більше шести років
Полюбляю бавитися із складними речами ...
... і розроблювати ще більш складні проекти професійно
Взагалі, I am fallen in love with compilers, you know
•
•
•
•
•
•
4

5. 5

6. ДОФАМІН
6

7. Що очікувати у цій доповіді...
Опис і архітектура двигуна потокової обробки ...
... на деякому рівні абстракції
Детальний опис процесу вирішення складної задачі
Мєми (не точно)
•
•
•
•
7

8. Hazelcast
Доступна і розподілена обчислювальна п-ма реального часу
Fast Data Store (a.k.a IMDG) : розподілений кеш
Streaming Data Engine (a.k.a Jet) : двигун обробки подій
SQL двигун
Купа інтерфейсів до зовнішніх систем : Kafka, elastic, hadoop
Механізми гео-реплікації, split-brain healing, RAFT, etc
•
•
•
•
•
•
8

9. 9

10. JET
Двигун потокової та партійної обробки даних
Виконує заданий направлений ациклічний граф
Кожен вузол - обсчислювальна одиниця - процесор
Ребра графа - направлення потоків даних
Утилізує ооперативну багатозадачність
Доступ через SQL, Java, C# & Python API
•
•
•
•
•
•
10

11. Jet - масштабування
ProcessorMetaSupplier (рівень кластера)
ProcessorSupplier (рівень вузла)
Processor
•
•
•
11

12. Приклад
private static final String BOOK_LINES = "bookLines";
private static final String COUNTS = "counts";
Pipeline p = Pipeline.create();
p.readFrom(BOOK_LINES)
.flatMap(e -> traverseArray.(toLowerCase(e.getValue())))
.filter(word -> !word.isEmpty())
.groupingKey(wholeItem())
.aggregate(counting()))
.writeTo(Sinks.map(COUNTS));
01.
02.
03.
04.
05.
06.
07.
08.
09.
10.
12

13. ProcessorMetaSupplier
Source Transform Aggregate Collect
broadcast
local local
13

14. ProcessorSupplier
NODE - 1
Source Transform Aggregate Collect
NODE - 2
Source Transform Aggregate Collect
14

15. Processor
NODE - 1
Source Transform Aggregate
Collect
NODE - 2
Source Transform Aggregate
Source Transform Aggregate
Collect
Source Transform Aggregate
15

16. REAL-TIME
16

17. З'єднання потоків: use case
SELECT * FROM orders_stream AS o
JOIN deliveries_stream AS d
ON o.id = d.order_id
AND d.delivery_time
BETWEEN o.order_time AND o.order_time + INTERVAL '1' HOUR
01.
02.
03.
04.
05.
17

18. З'єднання потоків : первісна ідея
Два буфера для лівого і правого входу.
Потоки обов'язково марковані часовими мітками (watermark).
Дані обов'язково містять відмічені поля.
Часові рамки задаються синтаксисом SQL.
Одразу оптимізуємо : куча замість масива (буфер)
•
•
•
•
•
18

19. З'єднання потоків : ідея (1)
Коли надходять дані :
Якщо подія спізнилася - ігноруємо
З'єднуємо з подіями з протилежного боку
Зберігаємо в буфері
•
•
•
19

20. З'єднання потоків : ідея (2)
Коли приходить часова мітка :
Оновлюємо останню бачену відмітку для входу
Видаляємо з буферів "прострочені" події
Синхронізуємо часову відмітку і також відправляємо далі
•
•
•
20

21. Приклад запиту
SELECT * FROM input1 AS i1 JOIN input2 AS i2
ON i2.time BETWEEN i1.time - 1 AND i1.time + 4
01.
02.
21

22. З'єднання потоків : виклики
З'єднувати два чи більше потоки?
А пам'ять?
Порядок івентів при з'єднанні?
Синтаксис?
Який вигляд має мати API?
•
•
•
•
•
22

23. З'єднання потоків : виклики
З'єднувати два чи більше потоки?
А пам'ять?
Порядок івентів при з'єднанні?
Синтаксис?
Який вигляд має мати API?
•
•
•
•
•
23

24. А шо якщо так?
SELECT * FROM input1 AS i1
JOIN input2 AS i2
ON i2.time BETWEEN i1.time - 1 AND i1.time + 4
JOIN input3 AS i3
ON i3.time BETWEEN i2.time AND i2.time + 10
01.
02.
03.
04.
05.
24

25. Часові мітки
25

26. Часові мітки (1)
Відповідає на питання "подія А відбулась пізніше події Б?"
Повідомляє про час у потоці даних
Рівнозначне поняттю "зараз" з урахуванням затримки
Допомагає виявляти події, що запізнились
•
•
•
•
26

27. Приклад
27

28. Часові мітки (2)
Дуже важливо - часові мітки розподілені
На кожній машині : N процесорів = N потоків даних
Потрібно звіряти годинники
Перед посилкою наступному оператору мітки "зливаються"
•
•
•
•
28

29. 29

30. Часові мітки з ключем (1)
Винайшли часові мітки з ключем
Ключ - позначник потока, з якого прийшла подія
•
•
30

31. Приклад
SELECT * FROM input1 AS i1
JOIN input2 AS i2
ON i2.time BETWEEN i1.time - 1 AND i1.time + 4
JOIN input3 AS i3
ON i3.time BETWEEN i2.time AND i2.time + 10
01.
02.
03.
04.
05.
31

32. i1_time i1_data i2_time i2_data i3.time i3.data
Вже з'єднана подія
ключ 0 ключ 1 ключ 2
32

33. Часові мітки з ключем (2)
Винайшли часові мітки з ключем
Ключ - позначник потока, з якого прийшла подія
Переписали повністю уніфікацію (coalescing) міток
Та і алгоритм з'єднання дещо ускладнився
•
•
•
•
33

34. 34

35. Алгоритм з'єднання *
Два буфера для лівого і правого входу.
Потоки обов'язково марковані часовими мітками (watermark).
Дані обов'язково містять відмічені поля.
Часові рамки задаються синтаксисом SQL.
Мапа для обліку часових міток по ключам [state].
Мапа для затримки часових міток по ключам [PTM].
•
•
•
•
•
•
35

36. Алгоритм з'єднання * : часова мітка
Оновити ті самі ключі міток у [state], відкладені [PTM]
Обчислити новий максимум для кожної вихідної мітки у [state].
Видалити всі прострочені події в лівому та правому буферах.
З решти ел-тів буфера знайти мінімальне значення часу для кожної мітки часу.
Для кожного ключа мітки сворити нову мітку із значенням, обчисленому на
попередньому кроці.
•
•
•
•
•
36

37. Алгоритм з'єднання * : дані
Якщо подія спізнилася - ігнор
Якщо подія виходить за межі [state] - ігнор
Зберігаємо в буфері
З'єднуємо з подіями з іншого буфера і відправляємо
•
•
•
•
37

38. LEFT
RIGHT
STREAM
JOINER
broadcast
local
RIGHT JOIN
LEFT
RIGHT
STREAM
JOINER
partitioned
partitioned
EQUI JOIN
JOIN
LEFT
RIGHT
STREAM JOINER
broadcast
local
38

39. Дякую.
Питання?
39