УДК 004

Механизм обработки потоковых данных

Яблонский Дмитрий Анатольевич – бакалавр Московского государственного технологического университета «СТАНКИН».

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

Ключевые слова: брокер сообщений, продюсер, инстанс приложения.

Обработка данных от брокера сообщений

Брокер сообщений (Kafka, Rabbit, Nats и др.) часто служит центральным компонентом в общей архитектуре данных, в которую другие системы закачивают данные. Но данные от брокера полезны только тогда, когда они используются другими приложениями или попадают в другие системы.

В данной статье представлено небольшое архитектурное решение, которое позволяет обрабатывать данные от брокера сообщений, с которыми необходимо работать в дальнейшем, без использования алгоритма LRU кэширования и базы данных.

1

Рисунок 1. Количество сообщений секунду.

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

До новой реализации приложение представляло такой механизм: сервис - XServise в фоновом режиме прослушивал необходимую тему, собирал чанк равный 100 уникальных структур и записывал через транзакцию в базу данных postgres. Этот же сервис во время своей работы запрашивал периодически из базы всю информацию, которой располагает таблица по необходимому уникальному идентификатору. Проблема заключалась в том, что при таком потоке данных инициализировалось очень большое количество транзакций (групп последовательных операций). По этой причине память на сервере, где расположен XServise, быстро заканчивалась, как видно на рисунке ниже. Проблема, упирающаяся в память решилась при помощи известного алгоритма LRU (Least Recently Used). Это алгоритм, при котором вытесняются значения, которые дольше всего не запрашивались. Но проблема осталась и XService до сих пор не может стабильно выполнять в срок заданную ему работу из-за блокировки записей в таблице.

2

Рисунок 2. Память при использовании LRU кеширования.

Когда объем данных от продюсера в единицу времени достаточно велик, с учётом того, что каждое сообщение должно быть агрегировано, отфильтровано и сохранено в каком-нибудь хранилище, можно использовать более простой и доступный механизм. Конфигурирование базы данных, к примеру PostgreSQL, может занять гораздо больше времени и иметь определенные проблемы, связанные с различными условиями ее использования. Поэтому можно рассмотреть использование «key-value» хранилищ и файлов формата csv.

3

Рисунок 3. Схема сервиса для агрегации данных от брокера.

На схеме выше представлена схема сервиса для агрегации данных от брокера (в данном случае kafka) и предоставления к ним доступа. Он разделен на две составляющие: Dumper и Service. Dumper (kafka consumer) – записывает собранные структурированные данные в gzip файлы (с ротацией). Service – периодически индексирует gzip файлы, созданные dumper, записывает в любое key-value хранилище и предоставляет к ним доступ по http протоколу.  Также здесь легко распределяется нагрузка на сервис путем увеличения инстансов (в данной схеме их 2) и все необходимые данные будут сохранены и по необходимости предоставлены.

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

  1. Apache Kafka. Потоковая обработка и анализ данных Нархид Ния, Шапира Гвен | Нархид Ния, Шапира Гвен
  2. Pattern: Microservice Architecture [Электронный ресурс]. – Режим доступа: https://microservices.io/patterns/microservices.html.

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

Внимание, откроется в новом окне. PDFПечатьE-mail