УДК 004.042

Анализ предметной области высоконагруженных приложений обработки потоков данных в режиме реального времени

Арбатов Денис Кириллович – магистрант Московского технического университета связи и информатики.

Аннотация: В статье приведены результаты анализа предметной области высоконагруженных приложений обработки потоков данных в режиме реального времени. Раскрыта предметная область, содержащая определенные компоненты, которые предоставляют функциональность для высоконагруженного приложения. Сформулировано определение поток данных – это непрерывный событийно-последовательный в неограниченном временном отрезке поток, отражающий перечень отсортированных по времени изменений данных.

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

Выполнено исследование и анализ имеющихся решений и технологий: событийно-потокового фреймворка Apache Kafka, потоковых сервисов Amazon Kinesis, вычислительной платформы Apache Flink, аналитической платформы Apache Spark. Итогами анализа представлены преимущества и недостатки всех вышеуказанных решений и технологий разработки высоконагруженных приложений обработки потоков данных в режиме реального времени.

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

Высоконагруженные приложения или DIA – «Data-Intensive Application» собираются из специальных компонентов, которые предоставляют требуемую функциональность.

Системы реального времени подразделяются «три типа систем реального времени: жесткого реального времени, мягкого реального времени и почти реального времени» [2, c. 20].

Поток данных – это непрерывный событийно-последовательный в неограниченном временном отрезке поток, отражающий перечень отсортированных по времени изменений данных.

1

Рис. 1. Схема жизненного цикла системы потоковой обработки.

Жизненный цикл системы потоковой обработки данных в режиме реального времени содержит в себе пять основных этапов:

  • первый этап сбора данных;
  • второй этап передачи данных в очередь сообщений;
  • третий этап анализа собранных данных;
  • четвертый этап сохранения полученных данных;
  • пятый этап получения доступа к данным анализа снаружи.

Сбор данных — это первый этап жизненного цикла системы потоковой обработки данных в режиме реального времени, который происходит по следующим архитектурным сценариям:

  • «сообщения от клиентов» сценарий предусматривает отправку клиентами сообщений службе в одностороннем порядке, но в данном сценарии возможны потери данных;
  • «запросы от клиентов – подтверждение запросов» по отправленному запросу клиента поступает подтверждение (уникальный идентификатор) получения запроса, который в будущем может использоваться при отправке повторных запросов от клиентов, а также для указания статуса отправленных запросов;
  • «запросы от клиентов – ответы от службы» в этом сценарии в адрес службы поступают запросы от клиентов, далее служба обрабатывает полученные запросы и отправляет ответы клиентам;
  • «запрос от службы – потоковый источник» сценарий учитывает, что ответом на запрос службы будет поток данных, соответственно это способствует установлению подключения самой службы к потоковому источнику. 

Передача собранных данных в очередь сообщений — это второй этап жизненного цикла системы потоковой обработки данных в режиме реального времени. На данном этапе распространенным сценарием будет «производитель – брокер сообщений – потребитель». Производитель формирует сообщения и отправляет брокеру сообщений, который помещает их в очередь. Далее потребитель по определенной необходимости запрашивает сообщения у брокера сообщений. Семантика времени оперирует несколькими понятиями: время события, время приема, время обработки. Соответственно «существует несколько понятий времени, и выбор правильной семантики имеет большое значение для операций, основанных на времени, включая оконные соединения и агрегирование» [3, c. 172];

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

2

Рис. 2. Архитектурная схема потокового анализа.

Сохранение полученных данных — это четвертый этап жизненного цикла системы потоковой обработки данных в режиме реального времени. Сценарии сохранения итоговых результатов анализа полученных потоковых данных с использованием хранилища: «единичные сообщения» запись со скоростью потока новых сообщений; «пакет сообщений» запись всего пакет сразу; «буферизация сообщений» запись пакетным загрузчиком из очереди сообщений накопительного буфера. Также существуют сценарии сохранения результатов анализа в оперативной памяти, используются виртуальные сервера с DRAM – 1 Тб.

Получения доступа к данным анализа снаружи — это пятый этап жизненного цикла системы потоковой обработки данных в режиме реального времени. Присутствуют реализации начиная от обмена сообщениями с API потокового доступа до подписки на событие, которые могут объединяться в один поток.

Во время анализа действующих решений и технологий были рассмотрены: событийно-потоковый фреймворк Apache Kafka, потоковые сервисы Amazon Kinesis, вычислительная платформа Apache Flink, аналитическая платформа Apache Spark.

Фреймворк Apache Kafka имеет следующие преимущества: производительность с обработкой сообщений с частотой от 1 000 и более 1 000 000 сообщений в секунду; долговечность обеспечивается наличием распределенного журнала фиксации; «Apache Kafka очень гибка в том, что касается надежной доставки данных» [1, c. 209]; масштабируемость «рабочей нагрузки в кластере Kafka; надежность и отказоустойчивость обеспечивается за счет репликации всех разделов главного брокера; доступность, так как при выходе из строя одного потребителя осуществляет перенаправление его потоков на другого потребителя; асинхронная связь обеспечивает надежную доставку данных; независимость и простота в обслуживании; предотвращение перегрузки потребителей, за счет буферизации необработанные данные; стандартизация для потребителей коммуникационных протоколов TCP; уменьшение вычислительных ресурсов за счет возможности сжатия отправляемых и сохраняемых сообщений; система воспроизводимая, так как восстановление системы в предыдущее состояние возможно.

Фреймворк Apache Kafka имеет следующие недостатки: при работе с темами нет поддержки регулярных выражений; отсутствуют изменения записей в журнале фиксации; архитектура оставляет желать лучшего при использовании Apache ZooKeeper; нет возможности перенаправления сообщений; брокеры сообщений не поддерживают долговременное хранение данных; снижена пропускная способность при передачи больших сообщений; сложная конфигурация компонентов для получения оптимальной производительности.

Потоковые сервисы Amazon Kinesis имеют следующие преимущества: простое администрирование; гибкость решений в реальном времени; надежность и безопасное хранение данных; автоматическое масштабирование; доступность; непрерывное преобразование данных в потоке; шифрование данных; отсутствие инфраструктуры, то есть нет серверов; индексирование, постоянное сохранение метаданных; интерактивная среда разработки; непрерывные метрики для отслеживания и анализа данных; аналитика в реальном времени; интерактивный анализ; нет верхней квоты на число потоков; нет верхнего предела на пропускную способность; скорость чтения данных 2 МБ/сек.

Потоковые сервисы Amazon Kinesis имеют следующие недостатки: при увеличении числа потребителей падает объем обращений к сегменту; неотправленные (ядовитые) сообщения при обрыве соединения; при сериализации вызовов замедляется обработка данных; сбой «Kinesis Lambda» функции приводит к потере данных; масштабирование сегментов не больше 10-ти раз за сутки для каждого потока; задержка при создании нового потока до 10 минут.

Платформа Apache Flink имеет следующие преимущества: аналитика в режиме реального времени; автоматическая оптимизация программ; высокая производительность обработки потоков данных; эффективное управление выполнением задач; отказоустойчивость c согласованным состоянием при сбое; наличие простых API-интерфейсов; поддержка вычислений на основе машинного обучения; библиотека для машинного обучения, построения графиков, обработки данных; масштабирование приложения по мере увеличения нагрузки; настройка шага выравнивания; процесс асинхронной контрольной точки уменьшает задержку.

Платформа Apache Flink имеет следующие недостатки: трудности при развертывании и настройки производительности; усложненная архитектура тормозит эксплуатацию и отладку; отсутствие своей распределенной системы хранения данных; ограниченные возможности долгосрочного хранения данных; входные данные из очередей сообщений Apache Kafka; сложная интеграция с сторонними системами и инструментами; водяные знаки и буферизация увеличивают задержку, так как «водяные знаки плывут в потоке обычных записей с аннотированными отметками времени» [4, c. 67]; большое количество задач приводит к снижению быстродействия.

Платформа Apache Spark имеет следующие преимущества: упрощенное развертывание и управление кластером; удобный API на Scala / Java; аналитика данных в реальном времени с машинным обучением «Spark ML», предоставляется «пользователю API для всего, начиная от подготовки данных и заканчивая обучением модели» [5, c. 246]; масштабируемая обработка графовых данных; непрерывная обработка с гибкими потоковыми окнами; упрощенная разработка приложений из-за сокращения количества зависимостей; гарантии отказоустойчивости с использованием контрольных точек и журналов опережающей записи; поддержка text/json/csv из коробки; распределенная архитектура и хорошая интеграция с Hadoop; чтение потоков как бесконечной таблицы; наличие потоковых агрегатов, временных окон, соединений потоков с пакетам; поддержка Jupyter Notebook; поддержка языков разработки Scala, Java, Python и R; программное обеспечение с открытым исходным кодом.

Платформа Apache Spark имеет следующие недостатки: сложная архитектура для настройки оптимальной производительности; наличие возможных уязвимостей, таких как SQL-инъекций; сложное управление и добавление уровня оркестровки при работе с распределенными разделами; затруднительное управление окнами; стабильность зависит от качества кластера.

Список литературы

  1. Гвен Шапира, Тодд Палино, Раджини Сиварам, Крит Петти Apache Kafka. Потоковая обработка и анализ данных.2-е изд.- СПб.: Питер, 2023.- 512 с.
  2. Пселтис Эндрю Дж. Потоковая обработка данных. Конвейер реального времени / пер. с англ. А. А. Слинкин - М.: ДМК Пресс, 2018. - 218 с.
  3. Сеймур Митч Kafka Streams и ksqlDB: данные в реальном времени. - СПб.: Питер, 2023. - 432 с.
  4. Уэске Ф., Калаври В. Потоковая обработка данных с Apache Flink. Основы разработки потоковых приложений. / пер. с англ. В. С. Яценкова. - М.: ДМК Пресс, 2021. - 298 с.
  5. Холден Карау, Рейчел Уоррен Эффективный Spark. Масштабирование и оптимизация. - СПб.: Питер, 2018. - 352 с.

Интересная статья? Поделись ей с другими: