Я оцениваю Apache Flink для моего варианта использования.
Мой вопрос о том, как организовать код для «сложного» потока.
Вариант использования - это процесс IoT. Датчики производят события - это вход моего потока. Мое потоковое приложение выводит оповещения.
Первым шагом в моем потоке является обработка некоторых агрегированных функций на этих данных (среднее по окну, мин, макс и т. Д.). Второй шаг моего потока - запустить некоторый процесс «принятия решения» по входным и агрегированным данным. Этот второй шаг состоит из 2 параллельных процессов:
- Первый - это набор пользовательских правил (пример: если среднее значение датчика температуры> 50 °, а последнее - ниже 30 °, генерировать предупреждение)
- Второй - запуск некоторых моделей машинного обучения
График того, что я хочу сделать:
+-----------------+
+----------------+ | User rules |------> Alerts
| |-------->| (multiple) |
| Aggregates | +-----------------+
Sensors ------->| |
| (multiple) | +-----------------+
| |-------->| ML rules |-------> Alerts
+----------------+ | (multiple) |
+-----------------+
Как мне организовать мое приложение Flink?
Я имею в виду 3 способа сделать это:
1) Поместить весь мой код в один проект
Плюсы:
- Это поместит весь код в одно и то же место, не нужно переключаться на десятки приложений, чтобы понять, как он работает и что делает
- Мне не нужно было бы хранить промежуточные результаты в каких-либо других темах - я мог бы использовать их напрямую.
- Простое развертывание
Минусы:
- Основной файл приложения может быстро превратиться в беспорядок (не так ли?).
- Мне пришлось бы переустанавливать все каждый раз, когда я что-то обновляю (новое правило, новый агрегат и т. Д.)
2) Поместите часть обогащения в проект, поместите все пользовательские правила в другой, поместите часть машинного обучения в другой
Плюсы:
- Код, делающий то же самое, находится в том же месте
- Выглядит легко развернуть. Всего 3 приложения для развертывания
Минусы:
- Мне пришлось бы использовать брокера, чтобы производители и потребители могли общаться (агрегаты записываются в тему, а затем пользовательские правила читают их, чтобы использовать их), и мне приходилось бы объединять потоки
3) Каждый агрегат для обработки - это проект, каждое правило - это проект, каждая модель ML - это проект
Плюсы:
- Простое обновление. Будет хорошо масштабироваться с командой.
- Простой способ для новичков написать что-нибудь и не сломать все
- Похоже, что он будет хорошо масштабироваться - время, определяемое пользователем, не будет влиять на других
Минусы:
- Беспорядок, чтобы отслеживать, что развернуто и их версии
- Мне пришлось бы использовать брокера, чтобы производители и потребители могли общаться (агрегаты записываются в тему, а затем пользовательские правила читают их, чтобы использовать их), и мне приходилось бы объединять потоки
- много избыточного кода / может потребоваться создание библиотек
- Развертывание может стать беспорядком, если я найду сотни или тысячи агрегатов и правил
Мне не хватает опыта работы с Flink и Streaming в целом, чтобы узнать, как лучше всего подходит мой вариант использования. Я думаю начать со второго решения, которое кажется наилучшим компромиссом.