От Лямбда до Data Mesh: 7 архитектур данных для Big Data систем

Что такое архитектура данных, какие модели чаще всего используются в современных Big Data системах, почему традиционные BI-системы не справляются со всем разнообразием текущих бизнес-сценариев, чем Лямбда отличается от Каппа, а Data Fabric от Data Mesh и зачем внедрять MLOps-инструменты в аналитическую платформу.

Немного истории: почему архитектуры данных до сих пор активно развиваются

Прежде всего дадим определение термину архитектура данных. Согласно профессиональному своду знаний DMBoK, это модель, которая включает методы, правила и способы описания текущего состояния данных, нужные для формирования требований к данным, их интеграции и контроля использования в соответствии с общей стратегией управления. Архитектура данных является одним из доменов архитектуры предприятия, соединяя бизнес-стратегию и техническую реализацию, т.е. деятельность компании в виде системы бизнес-процессов и ИТ-инфраструктуру ее поддержки в виде приложений и информационных систем. Например, в методологии ARIS (Architecture of Integrated Information System), используемой для моделирования корпоративной архитектуры, есть данным выделено отдельное представление в виде информационных моделей (моделей данных), которые отражают структуру информации для реализации всех функций предприятия как системы.

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

Первопроходцами на арене архитектурных моделей данных стали системы класса Business Intelligence (BI), которые впервые появились в 80-хх гг. XX века. Именно BI-системы популяризовали понятие OLAP-куба как абстракции бизнес-модели, откуда с помощью SQL-подобного запроса MDX можно получить нужную информацию. Хотя BI-решения по-прежнему очень востребованы (рынок BI в 2027 оценивается в $60,5 млрд.), сегодня эти системы не могут охватить все текущие бизнес-сценарии работы с данными по следующим причинам:

• BI-системы больше ориентированы на анализ структурированных бизнес-данных с высокой плотностью, но не очень поддерживают обработку неструктурированных и полу-структурированных данных типа изображений, текста и аудио;
• хранилище данных является центральным элементом BI и для загрузки данных в него из других систем нужны соответствующие ETL-конвейеры с поддержкой дата-инженеров, которые решают, как выполнить очистку и преобразование данных. Рост количества разнородных источников и форматов данных усложняет ETL-конвейеры.
• При увеличении объема обрабатываемых данных порядка ТБ/ПБ производительность BI-систем снижается;
• Реляционная парадигма решает проблему избыточности данных для обеспечения их согласованности, но для хранилищ данных часто это не требуется. Данные используются только для чтения, поэтому эти ограничения снижают производительность аналитических систем.
• Хранилища данных не очень подходят для исследований и ML, поскольку не всегда можно четко определить данные признаков, которые необходимо извлечь для моделирования.

Чтобы решить эти проблемы в начале 2000-х гг. начали развиваться технологии Big Data, в частности, Apache Hadoop. Системы хранения и аналитики больших данных на основе Hadoop устранили узкие места традиционных BI-систем и реляционных хранилищ данных, но принесли свои трудности:

• переход от хранилища данных к озеру данных не имеет плавной эволюции, что на практике часто превращается в мега-проекты по радикальному реинжинирингу ИТ-инфраструктуры;
• распределенное хранилище Big Data подчеркивает характер данных только для чтения, методы хранения HDFS не поддерживают обновление, а операции записи – параллелизм, что приводит к определенным ограничениям и почти нивелирует саму идею распределенной системы.

Современные аналитические платформы направлены ​​на устранение узких мест, с которыми сталкиваются традиционные хранилища данных:

• распределенные вычисления, когда разные узлы в кластере могут параллельно обрабатывать данные с учетом их физического расположения (data locality), чтобы максимально сократить накладные расходы на передачу по сети и ускорить выполнение программы. В частности, на низком уровне Apache Spark использует распределенную коллекцию данных RDD, а Kafka позволяет настроить размер пакета (batch size), о чем мы писали здесь.
• распределенное хранение, когда один большой файл реплицируется на N копий, каждая из которых независимо размещается на отдельном узле кластера;
• разделение извлечения и хранения: ранее в Big Data технологиях хранение данных и выполнение вычислений не разделялись, но сегодня это стало стандартом де-факто. Ориентированные на быстрое выполнение вычислительных операций и чтение данных аналитические движки и форматы не очень хорошо поддерживают эффективное хранение данных. И наоборот, хранилище данных отвечает не только за удобство записи сообщений и сохранность их содержимого, но и добавляет много метаинформации, включая индексы и пр., еще больше увеличивая информационный объем.

Как эти тенденции реализуются в современных архитектурах данных, рассмотрим далее.

Традиционная архитектура больших данных

Эта архитектурная модель называется традиционной, т.к. позиционируется на решение проблем традиционных BI-систем, связанных с ростом объема данных и падением производительности. Этот тип архитектуры по-прежнему сильно связан с ETL-процессами, которые обеспечивают попадание данных в реляционное хранилище. Достоинством такой модели является относительная простота и легкость реализации, поскольку основы BI-подхода не изменились. Новым является только выбор технологии реализации, где исторические компоненты BI-систем заменены на инструменты Big Data. Например, Apache Kylin – механизм распределенной аналитики с открытым исходным кодом для обеспечения SQL-интерфейса и многомерного анализа Hadoop и Alluxio, поддерживающего очень большие наборы данных.

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

Архитектура потоковой передачи данных

По сравнению с традиционной архитектурой, Streaming-модель ориентирована на потоковую обработку, а пакетная часть удалена. Данные обрабатываются в виде потоков на протяжении всего процесса: на стороне доступа к данным нет ETL-конвейера, он заменяется каналом поступления данных. Данные, обработанные потоковой обработкой, напрямую передаются потребителям в виде сообщений, которые хранятся не в озере данных, а в периферийной системе. Плюсом этого подхода является отсутствие сложных ETL-процессов, а эффективность потоковой обработки данных очень высока.

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

Лямбда и Каппа

Лямбда-архитектура является ключевой архитектурой в системах Big Data, о чем мы подробно писали здесь. Канал данных Lambda разделена потоковую передачу в реальном времени и историческую (автономную), где используется пакетная обработка для обеспечения конечной согласованности. Этот подход позволяет реализовать большинство сценариев применения, однако в большинстве случаев пакетный и потоковый уровни работают с разными кейсами, тогда как их внутренняя логика обработки данных почти одинакова. Поэтому возникает дублирование данных и кода, что становится источником ошибок.

Поэтому в 2014 году в дополнение к Лямбда-модели была предложена Каппа-архитектура, которая потребляет меньше ресурсов, но отлично подходит для обработки событий в режиме реального времени. Kappa основана на Lambda и объединяет части потоковой передачи с пакетным уровнем, заменяя его очередью сообщений. В Каппа-архитектуре используется потоковая обработка, но данные хранятся в озере данных. Когда нужна масштабная автономная аналитика и различные другие множественные вычисления, данные из озера передаются через очередь сообщений. Так Rfggf-архитектура устраняет избыточность Lambda. Но, хотя идея Kappa-модели выглядит просто, ее относительно сложно реализовать, особенно для части воспроизведения данных.

Unifield-архитектура

Все вышеперечисленные архитектуры в основном ориентированы на массовую обработку данных, а архитектура Unifield фокусируется на машинном обучении. В основе Unifield по-прежнему лежит Lambda, но преобразованная на потоковую обработку. Отдельно вынесен слой Machine Learning. В центрах обработки данных и Data Lake через канал данных добавляется новая обучающая часть модели, которая используется на уровне потоковой передачи. Этот потоковый уровень использует ML-модель и постоянно обучает ее.

Unifield предоставляет целый набор архитектурных решений, сочетающих анализ данных и машинное обучение, что позволяет объединить ML с платформами хранения и аналитики больших данных. Однако, архитектуру Unifield очень сложно реализовать из-за проблем разработки и развертывания ML-систем, с которыми борется MLOps-концепция. Тем не менее, такая архитектура подойдет для проектов, где необходимо проанализировать большой объем данных с помощью алгоритмов машинного обучения.

Data Fabric и Data Mesh

В заключение отметим архитектурные модели управления данными (Data Governance). Одной из них является Data Fabric, которую аналитическое агентство Gartner внесло в ТОП-10 главных трендов 2020 года в области Data Analytics.  Data Fabric – это согласованная архитектура управления данными, которая обеспечивает беспрепятственный доступ к данным и их обработку. Сюда входит целая экосистема, которая объединяет повторно используемые сервисы производства данных, конвейеры их передачи и обработки, а также API-интерфейсы и другие подходы к интеграции данных между различными системами и хранилищами для беспроблемного доступа и обмена данными в распределенной среде. Можно сказать, что Data Fabric затрагивает не только технические вопросы реализации архитектуры Big Data систем, но и организационную сторону, включая DataOps-практики.

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

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

А Data Mesh как сетка данных пропагандирует децентрализованный подход, когда различные наборы данных должны полностью управляться отдельными командами в разных бизнес-областях. При этом продукты данных каждой доменной команды должны быть обнаруживаемыми, совместимыми, безопасными, надежными и обладать самоописываемой семантикой и синтаксисом. О том, как сетка данных дала старт новой дата-архитектуре под названием Мю, читайте в нашей новой статье.

Таким образом, Data Fabric и Data Mesh – это архитектуры управления данными, а не модели их хранения и обработки с инструментальной точки зрения, в отличие от Лямбда, Каппа и прочих рассмотренных подходов. Однако, в любом случае, выбор технологий реализации и организации работы с данными зависит от их объема, приоритетных бизнес-сценариев, особенностей архитектуры предприятия, масштаба команды, а также множества других внешних и внутренних факторов.

Как научиться выбирать наиболее подходящую архитектуру для своего проекта хранения и аналитики больших данных, вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

• Архитектура Данных
• Аналитика больших данных для руководителей
• Потоковая обработка в Apache Spark
• Потоковая обработка данных с помощью Apache Flink

Источники

1. https://www.emergenresearch.com/industry-report/business-intelligence-and-analytics-market
2. https://medium.com/dataprophet/4-big-data-architectures-data-streaming-lambda-architecture-kappa-architecture-and-unifield-d9bcbf711eb9
3. https://towardsdatascience.com/modern-unified-data-architecture-38182304afcc
4. https://www.itweek.ru/bigdata/article/detail.php?ID=221837