(это черновик описания, а не итоговый список всех сообщений и каналов, по которым они передаются)
- Executor --- компонента, которая общается с coordinator (координатором) и кластером (включая сервисный граф на каждом узле):
- получает от координатора execution graph
- отправляет service graph на кластер
- отправляет execution graph на кластер
- сообщает service graph на каждом узле сокет execution graph на том же узле (executor и service graph общаются посредством Flink)
- останавливает service graph и собирает номер текущего окна в начале переключения графов (см. ниже)
- отправляет максимальный номер окна в service graph
- собирает ватермарки со стоков старого execution graph, когда те прочитали все данные, относящиеся к старым окнам
- собрав все такие ватермарки, отправляет на кластер команду убить старый граф (flink умеет убить весь jobgraph, т.е. на каждом узле)
- User source (пользовательский источник) --- источник, который пользователь указал в запросе; у нас это генератор
- User sink (пользовательский сток) --- сток, который пользователь указал в запросе
- Service graph (сервисный граф) --- граф, который встраивается между user source и execution graph. Он читает элементы из user source, самостоятельно разбивает их на окна, передаёт в execution graph (пишет в его сокет). При переключении графов service graph придерживает элементы нового окна в буфере, отправляет элементы старых окон в сокет старого графа, элементы новых окон в сокет нового графа (здесь имеется в виду экземпляр service graph на каждом узле).
- Execution graph (граф исполнения запроса) --- граф, полученный из запроса.
- Execution graph source --- сокет, в который пишет service graph.
- Execution graph sink --- сток графа исполнения запроса, откуда элементы идут в service sink.
- Service sink --- наш сток, перехватывающий элементы из execution graph sink и отправляющий их дальше в user sink либо в случае сервисных сообщений (ватермарка о конце чтения старых окон) в executor (я так полагаю, максимальный номер окна service graph тоже отправляет сюда? а executor это читает из очереди)
Executor отправил на кластер service graph, затем изначальный execution graph.
Service graph перехватывает элементы из пользовательского истока и срау же передаёт их дальше в execution graph. Элементы проходят через execution graph в execution graph sink, оттуда в service sink, оттуда в user sink.
На каждом узле кластера есть экземпляр service graph и экземпляр execution graph. Когда executor отправил execution graph на кластер, ему нужно также "познакомить" между собой графы на каждом узле. Далее в тексте словами под service graph и execution graph будет подразумеваться один экземпляр графа на узле кластера. Service graph знает сокет, на котором расположен execution graph. Execution graph читает входные элементы из этого сокета, куда их пишет service graph.
Service graph при чтении элементов осуществляет собственное разбиение на окна. По event time элемента service graph может определить номер окна, к которому он принадлежит.
- Coordinator отправляет Executor новый execution graph
- Executor отправляет новый граф на кластер
- Executor сообщает каждому сервисному графу сокет нового графа
- Executor останавливает каждый сервисный граф на текущем окне (перестаём читать из источника либо начинаем класть данные в буфер) и спрашивает, какое окно сейчас выполняется
- Executor выбирает максимум max среди пришедших окон
- Все данные, относящиеся к окну max или раньше, отправляются в старый execution graph, как и раньше; все новые данные кладутся в буфер (если мы при этом буферизовали данные для окон старого графа, они тоже, соответственно, отправляются в старый граф)
- Service graph отправляет данные из буфера в сокет нового графа
- Когда данные из старого графа закончились (пользовательский источник прислал ватермарку), service graph отправляет в execution graph ватермарку
- Когда ватермарка доходит до execution graph sink, executor должен получить об этом сообщение (тут не очень понятно, кто следит за execution graph sink; мы обсуждали, что это будет service graph, но, может быть, это executor? execution graph sink -> service sink -> оттуда в очередь для executor'а, а не в user sink)
- Когда executor получает такие сообщения ото всех старых execution graphs, он убивает соответствующую job на кластере (job=jobgraph, этот граф разложился по узлам, нам нужно убить на каждом узле, Flink умеет убивать весь jobgraph)
- При этом новый граф продолжает получать элементы и остаётся, таким образом, единственным графом
- Новый граф становится текущим графом
Непонятный момент: не может ли быть такого, что события приходят в буфер быстрее, чем мы его очищаем?