ОБРАБОТКА БОЛЬШИХ ДАННЫХ В РЕЖИМЕ РЕАЛЬНОГО ВРЕМЕНИ

ОБРАБОТКА БОЛЬШИХ ДАННЫХ В РЕЖИМЕ РЕАЛЬНОГО ВРЕМЕНИ

Смолов Денис Александрович

студент, Московский технический университет связи и информатики,

РФ, г. Москва

BIG DATA PROCESSING IN REAL TIME

Denis Smolov

student, Moscow Technical University of Communication and Informatics,

Russia, Moscow

АННОТАЦИЯ

В работе мы раскрываем вопросы обработки и хранения больших данных, даем определение системы реального времени, раскрываем понятие "озеро данных", разбираем подходы к построению Big Data систем.

ABSTRACT

We reveal the issues of processing and storing big data in our work, give a definition of a real-time system, reveal the concept of a "data lake", and analyze approaches to building Big Data systems.

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

Keywords: big data, real-time system, data lake, lambda architecture, kappa architecture, data warehouse.

Большие данные рассматриваются в области анализа и извлечения информации из наборов данных, которые обладают слишком большим объемом для того, чтобы быть обработанными традиционными программными средствами [1]. Проблемы анализа больших данных включают в себя получение, обработку и анализ информации.

Volume (объем) – это количество получаемых и сохраняемых данных. В данном случае размер данных определяет их ценность, а также то, можно ли их отнести к категории big data [2].

Variety (разнообразие), в свою очередь, характеризует тип и характеристику данных. Технологии big data развивались с целью обработки неструктурированных данных, которые поступают с большим объемом и скоростью.

Velocity (скорость) - это скорость, с которой данные поступают и подвергаются обработке. Данные можно получить в режиме реального времени [3].

Рисунок 1. Характеристика больших данных

Системы реального времени

В системе реального времени главную роль имеет время генерации выходного сигнала [4].

Real Time System, или RTS - это система, в которой обработка данных происходит настолько быстро, что ее промежуточные результаты могут применяться для управления этим циклом. RTS решают задачи, в которых важны не только корректность принимаемых решений, но и сроки их принятия. RTS характеризуются свойством предсказуемости, или детерминированности.

Приведем пример времени реакции на события в системе RTS:

• Математическое моделирование – несколько микросекунд

• Радиолокация – несколько миллисекунд

• Торговые операции – несколько минут

• Управление производством – несколько минут

Характеристики систем реального времени [5]:

• дедлайн (deadline) — крайний срок, к которому должно быть выполнено действие;

• латентность (latency) — время отклика, или задержка, реакции системы на события;

• джиттер (jitter) — разброс значений времени отклика. Джиттер часто появляется при одновременном выполнении других задач.

Системы реального времени можно разделить на системы жесткого реального времени (hard real time system, HRTS) и системы мягкого реального времени (soft real time system, SRTS). В системах жесткого реального времени предъявляемые временные характеристики обработки событий должны строго исполняться. Недопустимы никакие задержки в работе системы, потому как подобные лаги могут привести к аварии или иным негативным последствиям в случае несвоевременной обработки, или же результаты могут оказаться не востребованы в случае возникновения задержки. Примеры HRTS: системы обеспечения безопасности, системы управления на борту, системы защиты от аварий.

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

Большинство систем реального времени решают задачи жесткого и мягкого реального времени, а также задачи без критического срока обслуживания. Задача может поменять статус задачи SRTS при пропуске некоторого срока обслуживания в статус задачи HRTS назначением критического срока обслуживания.

Озера данных

Озеро данных — это хранилища данных, которые складируются в необработанном виде, например, в формате двоичных данных или файлов [6].

Озеро данных может включать в себя структурированные данные (строки и столбцы реляционных баз данных), полуструктурированные данные (XML, JSON, CSV, записи логов), неструктурированные данные (файлы, документы, электронные письма) и двоичные данные (аудио, видео, фото) [7]. Жизненный цикл озера данных представлен на рисунке 2. После получения данные могут быть преобразованы к другому способу представления, но оригинальные данные при этом не подвергаются  изменениям.

Рисунок 2. Жизненный цикл data lake

Критерии определения понятия «озеро данных» [8]:

1. Объем и стоимость. Озера данных характеризуются большим объемом и низкой стоимостью. Data lakes обходятся дешевле в пересчете на единицу объема памяти, чем традиционные хранилища данных.

2. Корректность данных: озера данных хранят данные в исходной формате. Если бы данные были переработаны, то восстановить, в каком формате пришли исходные данные, будет невыполнимой задачей.

3. Удобство доступа. Доступ к данным в озере осуществляется очень легко, и это представляется одним из основных преимуществ хранения данных в необработанном виде.

Лямбда-архитектура

Часто при реализации задач возникает необходимость провести анализ исторических данных. Например, нам нужно создавать рекламные объявления, опираясь на историю перемещений человека по городу. Нам известны интересы человека (это исторические данные), и мы должны отслеживать его местоположение в реальном времени, то есть мы осуществляем анализ непрерывного потока географических данных. Мы предполагаем, что big data имеют высокую скорость  обработки. Однако, на практике некоторые операции, например, MapReduce на Hadoop, могут выполняться относительно медленно. Нередки ситуации, при которых информация устаревает, и, значит, наши данные теряют актуальность. Для решения данной задачи необходимо соединить потоковую обработку данных в real-time с результатами пакетной аналитики. Так мы переходим к работе на Лямбда-архитектуре [9].

Рисунок 3. Лямбда-архитектура

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

Лямбда-архитектура представляет собой систему из трех уровней: уровень пакетной обработки, уровень ускорения и уровень обслуживания.

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

На уровне ускорения производится анализ данных в режиме реального времени, что позволяет получить небольшую задержку обработки с некоторыми потерями точности. Уровень организован как совокупность хранилищ данных, где в отдельные представления реального времени поступают данные с коротким жизненным циклом, чтобы исключить дублирование данных. Обычно на уровне ускорения применяют следующие технологии потоковой обработки: Apache Storm, SQLstream, Apache Samza, Apache Spark, Flink, Azure Stream Analytics. Выходные данные можно переливать в базы данных NoSQL [10].

На уровне обслуживания происходит индексация пакетного представления, то есть обрабатываются результаты функционирования уровня пакетной обработки для оптимального выполнения запросов. По причине необходимости индексации и переработки поступающей информации результаты имеют задержку по времени. На данном уровне принято использовать хранилища Cassandra, HBase, MongoDB, Elasticsearch для работы на уровне ускорения и Hive для работы на уровне пакетной обработки.

Достоинства данного вида архитектуры:

- высокий уровень сохранности исторических данных благодаря использованию Hadoop или другого отказоустойчивого распределенного хранилища;

- соотношение надежности  и скорости;

- масштабируемость.

Недостатки Лямбда-архитектуры:

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

- отсутствие инструментов бизнес-аналитики – многие программные средства, работающие в рамках Лямбда-архитектуры, не поддерживают язык запросов SQL, т.к. относятся к области Big Data, например, NoSQL;

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

Для быстрой обработки событий в режиме реального времени без пакетного представления был создан другой подход – Каппа-архитектура.

Каппа-архитектура

В отличие от Лямбда-архитектуры, у которой логика обработки данных дублируется в холодном и горячем путях, в Каппа-архитектуре потоковые данные имеют только один путь. Данные принимаются в виде потока событий в распределенном и отказоустойчивом едином журнале логирования событий. События выстраиваются по порядку, и текущее состояние события может измениться только при появлении нового события. Как и на уровне ускорения Лямбда-архитектуры, обработка событий происходит во входящем потоке и сохраняется как представление в режиме реального времени. Если нужно повторно вычислить весь набор данных, как на пакетном уровне в Лямбда-архитектуре, поток воспроизводится заново.

Каппа-архитектура – это упрощение Лямбда-подхода к проектированию систем больших данных, в котором отсутствует уровень пакетной обработки. При этом каноническое хранилище данных является неизменяемым журналом только для добавления информации. Из журнала данные сразу передаются в систему потоковых вычислений, при необходимости обогащаясь информацией из неканонического хранилища на сервисном уровне. Целью работы сервисного уровня является предоставление оптимизированных ответов на запросы. Однако эти хранилища не являются неизменяемыми: при необходимости их можно удалить и восстановить из канонического DataStore [12].

Для функционирования систем на базе Каппа-архитектуры существуют следующие программные средства Big Data:

- канонические хранилища для постоянного логирования событий (Kafka и проч.);

- системы потоковых вычислений, (Spark и прочие streaming-системы);

- практически любая база данных может функционировать на сервисном уровне.

Каппа-архитектура может пригодиться в случае, когда:

- несколько запросов  или событий данных попадают в очередь для обработки в распределенном хранилище файловой системы или в истории;

- порядок запросов и событий неизвестен заранее – средства потоковой обработки могут работать с базой данных в любое время;

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

Рисунок 4. Каппа-архитектура

Достоинства Каппа-архитектуры:

- повторная обработка данных необходима только при внесении изменений в код;

- необходимо меньше ресурсов из-за того, что работа происходит только с одним путем обработки поступающей информации;

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

Рисунок 5. Сравнение Лямбда и Каппа-архитектуры

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

Заключение

Для работы с большими объемами данных за последнее время были разработаны разные методы и программные средства, самыми важными из которых является понятие хранилища на основе озера данных.

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

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

1.  Breur, Tom. "Statistical Power Analysis and the contemporary "crisis" in social sciences". Journal of Marketing Analytics. 4 (2–3): 61–65. doi:10.1057/s41270-016-0001-3. ISSN 2050–3318
2.  Sagiroglu, Seref (2013). "Big data: A review". 2013 International Conference on Collaboration Technologies and Systems (CTS): 42–47. doi:10.1109/CTS.2013.6567202. ISBN 978-1-4673-6404-1. S2CID 5724608
3.  Kitchin, Rob; McArdle, Gavin (17 February 2016). "What makes Big Data, Big Data? Exploring the ontological characteristics of 26 datasets". Big Data & Society. 3 (1): 205395171663113. doi:10.1177/2053951716631130
4.  Толковый словарь по вычислительным системам/Под ред. В.Илленгуорта и др.: пер. С англ.,: - М.: Машиностроение, 1989. С. 399.
5.  Huss, S.A. Advances in Design and Specification Languages for Embedded Systems: Selected Contributions from FDL’06. — Springer, 2007. — P. 345. — 368 p. — ISBN 9781402061493.
6.  "The growing importance of big data quality". The Data Roundtable. Retrieved 1 June 2020
7.  Campbell, Chris. "Top Five Differences between DataWarehouses and Data Lakes". Blue-Granite.com. Retrieved 19 May 2017
8.  https://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/assets/pdf/pwc-technology-forecast-data-lakes.pdf
9.  Schuster, Werner. "Nathan Marz on Storm, Immutability in the Lambda Architecture, Clojure". www.infoq.com. Interview with Nathan Marz, 6 April 2014
10. Kinley, James. "The Lambda architecture: principles for architecting realtime Big Data systems", retrieved 26 August 2014
11. https://www.machinelearningmastery.ru/a-brief-introduction-to-two-data-processing-architectures-lambda-and-kappa-for-big-data-4f35c28005bb/
12. http://milinda.pathirage.org/kappa-architecture.com