Apache Flink: упорядоченные временные метки с параллелизмом - PullRequest
0 голосов
/ 05 ноября 2018

У меня есть поток данных, в котором важен порядок событий. Временной признак установлен на EventTime, поскольку входящие записи имеют временную метку.

Чтобы гарантировать порядок, я установил параллелизм для программы на 1. Может ли это стать проблемой с точки зрения производительности, когда моя программа станет более сложной?

Если я правильно понимаю, мне нужно назначить водяные знаки моим событиям, если я хочу сохранить поток, упорядоченный по метке времени. Это довольно просто. Но я читаю, что даже это не гарантирует порядок? Позже я хочу выполнить вычисления с учетом состояния этого потока. Итак, для этого я использую функцию FlatMap, которая нуждается в ключе для потока. Но если я наберу поток, порядок снова будет потерян. AFAIK это из-за различных потоковых разделов, которые «вызваны» параллелизмом.

У меня два вопроса:

  • Мне нужен параллелизм? Какие факторы мне нужно учитывать здесь?
  • Как бы я достиг "упорядоченного параллелизма" с тем, что я описал выше?

1 Ответ

0 голосов
/ 06 ноября 2018

Несколько моментов для рассмотрения:

Установка параллелизма на 1 для всей работы предотвратит масштабирование вашего приложения, что повлияет на производительность. Вопрос о том, имеет ли это значение, зависит от требований вашего приложения, но это, безусловно, будет ограничением и может стать проблемой.

Если указанные вами агрегаты предназначены для глобального вычисления по всем записям событий, то для параллельной работы потребуется выполнить некоторую предварительную агрегацию параллельно. Но в этом случае вам придется уменьшить параллелизм до 1 на более поздних этапах графика работы, чтобы получить окончательные (глобальные) результаты.

Если, с другой стороны, эти агрегаты должны вычисляться независимо для каждого значения некоторого ключа, то имеет смысл рассмотреть возможность создания ключа потока и использовать это разделение в качестве основы для параллельной работы.

Все операции, о которых вы упоминаете, требуют определенного состояния, будь то вычисление максимума, минимума, среднего значения или времени безотказной работы. Например, вы не можете вычислить максимум, не помня максимум, который встречался до сих пор.

Если я правильно понимаю, как работает соединитель источника NiFi от Flink, то, если источник работает параллельно, нажатие клавиши приведет к потере событий.

Однако ни одна из упомянутых вами операций не требует, чтобы данные доставлялись по порядку. Вычисление времени безотказной работы (и времени простоя) для потока вне очереди потребует некоторой буферизации - эти операции должны будут ожидать поступления данных вне очереди, прежде чем они смогут дать результаты - но это, безусловно, выполнимо. Это именно то, что водяные знаки для; они определяют, как долго ждать неупорядоченных данных. Вы можете использовать таймер времени события в ProcessFunction, чтобы организовать обратный вызов onTimer, который будет вызван после обработки всех более ранних событий.

Вы всегда можете отсортировать поток с ключами. Вот пример .

Расчет времени работы / простоя должен легко выполняться с помощью библиотеки CEP Флинка (которая сортирует входные данные, кстати).

UPDATE:

Это правда, что после применения ProcessFunction к потоку с ключами поток больше не является ключом. Но в этом случае вы могли бы безопасно использовать reinterpretAsKeyedStream , чтобы сообщить Flink, что поток все еще имеет ключ.

Что касается CEP, эта библиотека использует состояние от вашего имени, что упрощает разработку приложений, которые должны реагировать на шаблоны.

...