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

Архитектура данных Лямбда Каппа Data fabric Data Mesh курсы примеры обучение, архитектор 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 в Москве:

Я даю свое согласие на обработку персональных данных и соглашаюсь с политикой конфиденциальности.

Источники

  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

Поиск по сайту