Прошлое, настоящее и будущее архитектуры данных
Зачем нам нужна архитектура данных?
Переход на управление данными в организации остается одной из главных стратегических целей многих компаний. Управление данными означает, что данные становятся центром всех решений и процессов, принимаемых в организации.
Руководители понимают, что переход на управление данными - это единственный способ улучшить качество обслуживания клиентов за счет гиперперсонализации и перепроектирования маршрута клиента, снизить операционные расходы за счет автоматизации и машинного обучения, а также понять бизнес-тенденции, которые важны для разработки стратегии высокого уровня и позиционирования на рынке. Платформа данных создает благоприятную среду для развития данных.
Платформа данных - это хранилище и центр обработки всех данных организации. Она занимается сбором, очисткой, преобразованием и применением данных для получения бизнес-информации. Иногда ее называют “современным стеком данных“, поскольку платформа данных часто состоит из множества интегрированных инструментов, поддерживаемых различными поставщиками (Dbt, Snowflake, Kafka и другими).
Одним из основных элементов вашей платформы данных является архитектура данных. Архитектура данных - это процесс проектирования, построения структуры информационных ресурсов организации и управления ею. Это своего рода платформа для интеграции данных из разных источников и приложений.
Основная цель хорошо спроектированной архитектуры данных - сократить объем разрозненных данных, свести к минимуму их дублирование и повысить общую эффективность процесса управления данными.
По мере того, как за последние десятилетия менялся ландшафт данных, менялась и архитектура данных. Давайте рассмотрим эту эволюцию более подробно.
Аналитические данные претерпели эволюционные изменения, вызванные новыми моделями потребления, начиная от традиционной аналитики для поддержки бизнес-решений и заканчивая интеллектуальными продуктами, дополненными ML
Первое поколение: Архитектура хранилища данных
Архитектура хранилища данных определяется перемещением данных из операционных систем (SAP, Salesforce) и сторонних баз данных (MySQL, SQL Server) в системы бизнес-аналитики. Хранилище данных - это центральная точка, в которой определяется схема (схема "снежинка", схема "звезда") и где данные будут храниться в измерениях и таблицах фактов, позволяя компаниям отслеживать изменения в своей деятельности и взаимодействии с клиентами. Данные:
- Преобразованы в универсальную схему, представленную в многомерном табличном формате с возможностью изменения во времени
- Извлекаются из множества операционных баз данных и источников
- Загружены в таблицы хранилища с помощью процесса CDC (change data capture)
- Доступ осуществляется с помощью SQL-запросов
- В основном используются аналитиками данных для составления отчетов и аналитической визуализации.
В этом архитектурном стиле также используются витрины данных. Они представляют собой дополнительный уровень (состоящий из одной или нескольких таблиц) поверх хранилища данных, предназначенный для решения бизнес-задач конкретного подразделения с использованием определенного формата схемы. Без витрин данных этим подразделениям пришлось бы изучать и создавать множество запросов в хранилище, чтобы получить данные с нужным им содержанием и форматом.
Основные проблемы этого подхода:
- Современные инженерные методы, такие как CI/CD, не применяются.
- Со временем создаются тысячи заданий, таблиц и отчетов ETL, которые может понять и поддерживать только специализированная группа.
- Модель данных и схема для хранилищ данных слишком жесткие, чтобы обрабатывать огромный объем структурированных и неструктурированных данных из нескольких источников.
Это приводит нас к следующему поколению архитектуры данных.
Второе поколение: Архитектура озера данных
Архитектура Data lake была представлена в 2010 году в ответ на вызовы, связанные с архитектурой хранилищ данных, для удовлетворения новых потребностей в использовании данных: доступ к данным для специалистов по обработке данных в процессе обучения модели машинного обучения.
Специалистам по обработке данных нужны данные в их первоначальном виде для процесса обучения модели машинного обучения (ML). Модели ML также требуют больших объемов данных, которые может быть сложно сохранить в хранилище данных.
Первые построенные озера данных включали хранение данных в распределенной файловой системе Hadoop (HDFS) на множестве кластеризованных вычислительных узлов. Данные извлекались и обрабатывались с помощью MapReduce, Spark и других платформ обработки данных.
Архитектура Data lake работает в рамках процесса ELT, а не ETL. Данные извлекаются (E) из операционных систем и загружаются (L) в центральное хранилище данных. Однако, в отличие от хранилищ данных, озеро данных предполагает очень незначительное преобразование и моделирование данных или их полное отсутствие. Цель состоит в том, чтобы сохранить данные в их первоначальном виде. Как только данные попадают в lake, архитектура расширяется за счет конвейеров преобразования данных (T), которые моделируют исходные данные и сохраняют их в хранилище данных или хранилищах функций.
Команды разработчиков данных, чтобы лучше организовать lake, создают различные “зоны”. Цель состоит в том, чтобы хранить данные в соответствии со степенью очистки и преобразования, начиная с самых простых данных и заканчивая этапами обогащения данных и заканчивая наиболее чистыми и доступными данными.
Эта архитектура данных направлена на снижение неэффективности и трудностей при масштабном предварительном моделировании, которое требуется для создания хранилищ данных. Предварительное преобразование является препятствием и приводит к более медленным итерациям доступа к данным и обучению модели.
Основные проблемы этого подхода:
- Сложные конвейеры пакетных или потоковых заданий, выполняемые централизованной командой высокоспециализированных инженеров по обработке данных.
- Архитектура Data lake отличается сложностью и ухудшением качества, что приводит к снижению качества и надежности данных.
- Это создает неуправляемые наборы данных, которые часто не заслуживают доверия и недоступны, что приводит к снижению ценности
- Происхождение данных и их зависимости трудно отследить
Отсутствие всестороннего предварительного моделирования данных создает трудности при построении семантического сопоставления между различными источниками данных, что приводит к возникновению "болот данных".
Третье поколение: архитектура облачных озер данных
Самыми значительными изменениями при переходе от архитектуры данных второго поколения к архитектуре данных третьего поколения стали переход к облаку, доступность данных в режиме реального времени и конвергенция между хранилищем данных и озером данных. Подробнее:
- Попытайтесь объединить пакетную и потоковую обработку для преобразования данных с помощью таких платформ, как Apache Beam.
- Поддержка потоковой передачи данных для обеспечения доступности данных практически в режиме реального времени с помощью таких архитектур, как Kappa.
- Полностью внедрите облачные управляемые сервисы и используйте современные облачные реализации с изолированными вычислениями и хранилищем. Хранение данных становится намного дешевле.
- Объедините хранилище и lake в единую технологию, либо расширив хранилище данных, включив в него встроенное обучение ML, либо, в качестве альтернативы, создав системы обеспечения целостности хранилища данных, транзакционности и запросов в решениях data lake. Databricks Lakehouse - это пример традиционного решения для хранения данных на озере с транзакциями, подобными складским, и поддержкой запросов.
Cloud data lake устраняет некоторые недостатки предыдущих поколений. Тем не менее, некоторые проблемы остаются.:
- Разработка архитектуры остается централизованной, что требует привлечения команды высокоспециализированных инженеров по обработке данных.
- Архитектура Data lake остается очень сложной в управлении, что влияет на качество и надежность данных.
- Для анализа требуется много времени. Потребители данных продолжают ждать несколько месяцев, чтобы получить набор данных для анализа или машинного обучения.
- Хранилища данных больше не являются копией реального мира с помощью данных, что влияет на восприятие пользователями данных при их изучении.
Все эти проблемы привели нас к созданию архитектуры данных четвертого поколения, которая на момент публикации этой статьи все еще находится в стадии разработки.
Четвертое поколение: архитектура Data Mesh
Архитектура Data mesh - это относительно новый подход к архитектуре данных, который направлен на решение некоторых проблем, которые были выявлены в предыдущих централизованных архитектурах.
Data mesh привносит в архитектуру данных то, что микросервисы привнесли в монолитные приложения.
В data mesh данные децентрализованы, а права собственности на них распределены по доменам. Каждый домен отвечает за данные в пределах своей области, включая моделирование, хранение и управление данными, и архитектура должна обеспечивать набор практик, позволяющих каждому домену независимо управлять своими данными.
Вот ключевые компоненты архитектуры data mesh:
- Продукты данных — Продукт данных является конечным результатом того, что создается в домене и становится доступным для использования в других доменах или приложениях. Каждый продукт данных имеет четкую бизнес-цель. Один домен может обрабатывать несколько продуктов данных. Не все информационные ресурсы будут рассматриваться как информационный продукт или должны рассматриваться как информационный продукт (хотя в идеальном случае это было бы именно так). Информационные продукты - это информационные ресурсы, которые играют ключевую роль в организации.
- Домены — это автономная бизнес-единица, которая владеет собственными данными и управляет ими. Каждый домен имеет четкое бизнес-назначение и отвечает за определение моделей данных, сущностей, схем и политик для управления данными. Эта концепция отличается от витрин данных в архитектуре хранилищ данных, разработанных для различных команд, таких как отдел маркетинга или продаж. В архитектуре data mesh продажи могут иметь несколько доменов, в зависимости от того, на чем сосредоточена команда.
- Инфраструктура данных — Инфраструктура данных включает в себя инструменты и технологии, необходимые для управления данными в рамках домена, аналогично контейнерному микросервису для программного приложения. Сюда входят средства хранения, обработки и анализа данных.
- Управление данными — управление данными осуществляется в каждом домене. Это относится к набору процедур, регулирующих качество, конфиденциальность и безопасность данных.
- Mesh API — Точно так же, как микросервис предоставляет доступ ко всему через HTTP REST API, домен data mesh предоставляет доступ ко всему через четко определенный интерфейс, который может использоваться другими доменами и продуктами обработки данных.
Каждая бизнес-область, состоящая из одного или нескольких микросервисов, будет иметь свою собственную базу данных OLAP и распределенную систему хранения файлов, точно так же, как любая часть микросервиса упакована в контейнер для независимой работы.
- Команды обработки данных становятся кросс-функциональными командами, специализирующимися в одной или нескольких областях бизнеса (не в технологиях), точно так же, как команды разработки программного обеспечения очень ориентированы на обслуживание.
- Вы можете рассматривать data mesh как смену парадигмы в разработке архитектуры данных и организации групп обработки данных в наши дни:
- Продукт данных A будет использоваться продуктом данных B, и оба они будут взаимодействовать с другими продуктами данных через потоковое вещание или REST API, точно так же, как микросервисы приложений взаимодействуют друг с другом.
- За API-интерфейсами продуктов данных последует традиционная документация по REST API, а сами продукты данных можно будет найти в каталоге данных mesh.
Что еще меняется в data mesh, кроме архитектуры?
Наиболее значимым изменением по сравнению с data mesh является архитектура. Но переход от централизованного хранилища данных к децентрализованной сети данных - это социально-технический феномен, который предполагает ряд дополнительных изменений.
Если вы помните, переход от монолитных приложений к микросервисным приложениям заставил команды разработчиков программного обеспечения изменить свой жизненный цикл разработки, организационную структуру, мотивацию, навыки и управление. Именно тогда появилась должность менеджера по продукту, призванная обеспечить, чтобы приложения решали реальные проблемы пользователей.
То же самое должно происходить и при применении архитектуры data mesh.
