Сегодня данные являются одним из самых ценных активов организаций. Они играют ключевую роль в принятии стратегических решений, оптимизации бизнес-процессов и создании конкурентных преимуществ. В этом контексте инженерия данных представляет собой важнейшую дисциплину, которая охватывает весь процесс: от сбора и преобразования данных до хранения и обеспечения их доступности.
В эпоху «больших данных» компаниям необходимо не только владеть данными, но и интерпретировать их, обеспечивать их доступность и интегрировать в системы поддержки принятия решений. Это требует создания новых более гибких решений для обработки и управления данными. По мере того как объем, разнообразие и варианты использования данных продолжают увеличиваться, организациям приходится искать архитектуры, которые могут адаптироваться к различным потребностям.
В этом контексте особую роль играют такие стратегии управления данными, как Data Warehouse, Data Lake, Data Lakehouse, и Data Mesh. Каждый из этих подходов предлагает уникальные решения, которые различаются по типу данных, модели доступа, требованиям к производительности, организационной структуре и политикам управления. Data Warehouse ориентированы на структурированные данные, в то время как Data Lake обеспечивают более гибкую структуру для хранения больших объемов неструктурированных данных. Data Lakehouse, с другой стороны, сочетает в себе преимущества обоих подходов, создавая оптимизированную среду для анализа данных. В свою очередь, Data Mesh направлена на децентрализацию управления данными с помощью микросервисных архитектур, что позволяет более эффективно распределять ответственность за данные в крупных организациях.
Для создания успешной архитектуры данных необходимо закладывать ее основы с самого начала процесса проектирования. И речь идет не только о технической структуре, но и о том, чтобы она соответствовала стратегиям управления данными и целям организации. В этой статье мы рассмотрим теоретические аспекты этих процессов и реальный проект, на примере которого я продемонстрирую, как построить такую систему.
Анализ требований: краеугольный камень успешной архитектуры данных
Крайне важно с самого начала иметь правильный подход к проектированию архитектуры данных — это поможет избежать возможных проблем на более поздних этапах. Поэтому первым и самым важным шагом является тщательный анализ требований. Если требования не будут четко определены, запуск проекта с неподходящей архитектурой приведет к потере ресурсов и времени.
Прежде чем приступить к проектированию архитектуры данных, необходимо четко понимать, что именно мы создаем. Далеко не каждый проект архитектуры данных укладывается в стандартные шаблоны. Структура данных каждой организации, бизнес‑цели, ожидания и потребности пользователей уникальны. Поэтому команда инженеров, отвечающая за разработку архитектуры данных, должна тесно сотрудничать с бизнес‑подразделениями и стейкхолдерами, чтобы четко определить сферу применения.
Попутно в этой статье мы рассмотрим пример рабочего процесса реального проекта. На основе заранее сформулированных требований будет выбрана определенная архитектура, которая должна быть интегрирована в этот процесс. Для полноты картины мы также обсудим и другие возможные альтернативы.
Нашей целью в этом примере является создание современного хранилища для консолидации данных о продажах с последующим выполнением их анализа. Для реализации может быть использована любая СУБД, например, MS SQL или PostgreSQL. Основная задача — улучшить процессы принятия решений на основе данных, упростить отчетность и улучшить понимание бизнеса.
Какова цель анализа требований?
Анализ требований выполняется для того, чтобы:
Понять потребности бизнеса,
Определить ожидания стейкхолдеров,
Очертить область применения системы и
Выбрать оптимальную технологическую инфраструктуру.
В нашем гипотетическом проекте предполагается, что данные поступают из двух основных систем‑источников: ERP и CRM. ERP (Enterprise Resource Planning) — это программная система, предназначенная для интеграции всех бизнес‑процессов и ресурсов компании. Она одновременно управляет целым рядом бизнес‑функций, таких как финансы, человеческие ресурсы, производство, логистика, продажи и маркетинг. Задача ERP‑систем — сделать процессы более организованными и прозрачнымиза счет эффективного использования ресурсов компании (времени, рабочей силы, материалов, капитала и т. д.). CRM (Customer Relationship Management) — это другая важная программная система, которая используется для управления и улучшения отношений компании как с существующими, так и с потенциальными клиентами. CRM собирает и анализирует данные о клиентах, что позволяет разрабатывать более персонализированные и эффективные стратегии в области продаж, маркетинга и поддержки пользователей.
Данные из ERP и CRM систем будут поступать в формате CSV. Использование файловых источников данных требует тщательного планирования и надежного контроля данных на протяжении всего процесса ETL (извлечения, преобразования, загрузки). Исходные данные часто оказываются неполными, поврежденными или противоречивыми, что требует их очистки и устранения проблем с качеством перед проведением какого‑либо анализа.
Однако одной лишь очистки данных недостаточно — они также должны быть интегрированы в удобную и понятную для пользователя структуру. Модель данных должна быть простой, логичной и спроектированной таким образом, чтобы поддерживать аналитические задачи. В рассматриваемом примере проекта отслеживание исторических данных не требуется. Это означает, что при загрузке данных будут учитываться только самые последние записи, что значительно упростит и ускорит работу системы. Я выбрал такой подход, чтобы сделать модель проще и понятнее.
Еще одним важным требованием является четкая и понятная документация для модели данных, которая будет сгенерирована в конце работы системы. Эта документация будет доступна как техническим специалистам, так и бизнес‑пользователям, что значительно упростит их адаптацию к новой системе. Она будет объяснять, как использовать хранилище данных, назначение каждой таблицы и отношения между ними, что напрямую влияет на устойчивость проекта.
В итоге в этом проекте:
Будет использоваться SQL,
Источниками данных, предоставляемых в формате CSV‑файлов, служат ERP‑ и CRM‑системы,
Данные будут очищены и преобразованы в удобную для пользователя модель,
Будут использоваться только самые последние данные,
В конце будет подготовлена подробная документация.
По завершению анализа требований у нас должна вырисовываться структура проекта, и можно будет приступить к следующему этапу — проектированию архитектуры данных. Тщательный анализ требований — это основа всех проектов, связанных с обработкой данных.
Проектирование архитектуры данных: работа над правильной структурой
Проектирование архитектуры данных — это важнейший этап, который напрямую влияет на успех проекта хранилища данных. На этом этапе определяется структура хранилища и способы обработки данных. Хорошо продуманная архитектура данных облегчает поток, интеграцию, хранение и доступ к данным. Однако существует несколько подходов к проектированию архитектуры данных, и выбор правильного метода должен соответствовать требованиям и целям проекта.
Варианты архитектур данных
Выбор подхода к проектированию архитектуры данных зависит от целей проекта, типов данных и предполагаемого способа их использования. Каждый подход имеет свои сильные и слабые стороны. Поэтому очень важно тщательно изучить ключевые особенности каждого из них и понять, в каких условиях они будут наиболее эффективны.
1. Data Warehouse
Data Warehouse обычно представляет собой упорядоченную структуру, в которую поступает большое количество структурированных данных, оптимизированных для анализа и составления отчетов. В SQL‑системах эти данные организованы в определенном формате, предназначенном для облегчения работы приложений бизнес‑аналитики. Data Warehouse обычно обладают несколькими важными особенностями:
Хранилище структурированных данных: Data Warehouse обрабатывает только структурированные данные. Эти данные хранятся в реляционных базах данных, организованных в стандартизированных в структурированные таблицы. Это позволяет хранить данные в четко определенных структурах данных, таких как столбцы и строки.
Ориентированность на анализ и отчетность: Data Warehouse разработаны с учетом потребностей дата‑аналитиков и команд бизнес‑аналитики, что подразумевает простоту создания отчетов. Это также упрощает выполнение быстрых запросов и обширный анализ данных.
Очистка и интеграция данных: В очистке и объединении информации из различных источников в Data Warehouse важную роль играют ETL‑процессы (извлечение, преобразование, загрузка). Этот процесс гарантирует, что данные загружаются в систему хранилища в согласованном формате, являются чистыми и пригодными для использования.
Преимущества:
Высокопроизводительная отчетность: Data Warehouse оптимизированы для генерации отчетов и способны эффективно обрабатывать сложные запросы, что позволяет быстро анализировать информацию и облегчает процесс высокопроизводительной отчетности.
Безопасность и согласованность данных: Data Warehouse обеспечивают высокий уровень безопасности данных и гарантируют их согласованность, что создает надежную среду для принятия решений и анализа.
Простота запросов и доступность: Данные хорошо организованы, что упрощает запрос и доступ к ним. Это позволяет дата‑аналитикам быстро извлекать необходимую информацию и эффективно работать с ней.
Недостатки:
Подходит только для структурированных данных: Data Warehouse предназначено исключительно для структурированных данных, что делает его непригодным для работы с полуструктурированными или неструктурированными данными, такими как текстовые файлы, изображения или видео.
Высокая стоимость: Обработка и хранение больших наборов данных могут быть дорогостоящими, особенно при работе с огромными объемами данных. Поддержание такой системы требует значительных инвестиций как в инфраструктуру, так и в эксплуатационные расходы.
Платформы, используемые для реализации архитектуры Data Warehouse:
Google BigQuery: Предлагает бессерверную масштабируемую архитектуру, что делает его идеальным выбором для быстрого развертывания и обработки больших объемов данных без необходимости управления инфраструктурой.
Amazon Redshift: быстрое масштабируемое решение в AWS, идеально подходящее для проектов, которые уже интегрированы в экосистему AWS.
Snowflake: Облачная платформа, которая позволяет развертывать хранилища в нескольких облаках, что обеспечивает беспрецедентную гибкость и масштабируемость.
Microsoft Azure Synapse Analytics (ранее SQL DW): Объединяя функции хранилища данных с возможностями интеграции больших объемов информации, Microsoft Azure Synapse Analytics представляет из себя универсальный вариант для организаций, которые используют экосистему Microsoft Azure.
Teradata: Классическое решение для обработки «больших данных», часто используемое в крупномасштабных локальных средах, где требуются сложные системы хранения.
IBM Db2 Warehouse: Корпоративное хранилище данных IBM, подходящее для организаций, нуждающихся в надежном локальном решении с высоким уровнем безопасности.
Выбор платформы для реализации архитектуры данных зависит от нескольких факторов: масштаба проекта, бюджета, технических требований и опыта команды. Для проектов небольшого и среднего масштаба предпочтительнее бессерверные решения, такие как Google BigQuery или Snowflake, так как они быстры в настройке и имеют низкие затраты на обслуживание. Если проект интегрирован в экосистему AWS, то рекомендуется рассмотреть Amazon Redshift. Для предприятий, использующих Azure, подойдет Microsoft Azure Synapse. Этот инструмент объединяет функции Data Lake и Data Warehouse, что делает его привлекательным выбором. Когда речь заходит о обработке данных в реальном времени или о больших наборах данных, требующих частых обновлений, возможности и производительность Snowflake становятся особенно важными. Для юзкейсов, в которых особо важны высокая безопасность и целостность данных, идеально подходят локальные решения, такие как Teradata или IBM Db2 Warehouse.
Хотите создавать архитектуру, которая решает реальные бизнес‑задачи? Курс Enterprise Architect — это глубокое погружение в лучшие практики проектирования корпоративных систем.
2. Data Lake
Data Lake — это хранилище с гибкой структурой, в котором вместе хранятся структурированные, полуструктурированные и неструктурированные данные. Этот тип архитектуры часто используется для хранения необработанных данных и служит основой для расширенной аналитики. Data Lake обычно применяются в крупномасштабных проектах обработки данных, особенно в области data science и машинного обучения, где возможность обрабатывать различные типы данных становится критически важной.
Data Lake позволяют организациям хранить огромные объемы данных в их исходном формате, что значительно упрощает интеграцию и анализ данных из различных источников без необходимости предварительного структурирования. Эта гибкость делает Data Lake особенно подходящими для проектов, работающих с «большими данными», требующих серьезных возможностей хранения и обработки.
Хранение различных типов данных:
Data Lake может хранить различные типы данных (от баз данных до текстовых файлов, изображений и многого другого) в необработанном виде. Обычно данные хранятся в файловом формате, таком как CSV, JSON или Parquet, что обеспечивает гибкость в хранении как структурированных, так и неструктурированных данных.
Гибкость в обработке данных:
Эта архитектура предоставляет дата‑инженерам и дата‑аналитикам широкие возможности для обработки данных любым способом, который они считают нужным. Это делает ее идеальным выбором для задач углубленной аналитики и машинного обучения, поскольку необработанные данные могут быть обработаны и преобразованы по мере необходимости.
Обновления данных:
Data Lake идеально подходит для обработки постоянно меняющихся и растущих наборов данных, поддерживая обработку данных в режиме реального или близком к реальному времени. Это делает эту архитектуру особенно полезной для проектов, которым требуется актуальная информация для анализа.
Преимущества:
Хранение как структурированных, так и неструктурированных данных: Data Lake позволяют хранить разнообразные типы данных, обеспечивая гибкость при их хранении.
Гибкость данных: Data Lake обладают высокой гибкостью, позволяя легко добавлять новые типы данных без необходимости в строгой структуре.
Подходит для машинного обучения и расширенной аналитики: Благодаря способности хранить необработанные данные Data Lake идеально подходят для сложных задач машинного обучения и углубленных аналитических процессов.
Недостатки:
Сложное управление данными: Управление данными в Data Lake может быть сложной задачей. Без должной организации данные могут стать труднообрабатываемыми, что приводит к традиционной проблеме «болота данных» (Data Swamp), когда данные становятся неорганизованными и с ними становится трудно работать.
Безопасность данных и контроль доступа: По сравнению с Data Warehouse, управление безопасностью данных и контролем доступа в Data Lake может быть более сложным из‑за разнообразия типов и форматов данных, хранящихся в системе.
Платформы, используемые для реализации архитектуры Data Lake:
Amazon S3: Наиболее часто используемая инфраструктура для создания Data Lake, обеспечивающая масштабируемое и экономичное хранилище для огромных объемов данных.
Azure Data Lake Storage (ADLS Gen2): Высокопроизводительное Data Lake решение, созданное на базе Microsoft Azure и предназначенное для крупномасштабной аналитики.
Google Cloud Storage (GCS): Решение Google Cloud для реализации Data Lake архитектуры, предлагающее масштабируемое хранилище и интеграцию с другими облачными сервисами Google.
Apache Hadoop HDFS: Предпочтительный выбор для локальных систем. Он представляет собой распределенную файловую систему, которая позволяет хранить и обрабатывать большие объемы данных.
MinIO: Платформа с открытым исходным кодом, совместимая с S3, предназначенная для создания Data Lake, обеспечивающая масштабируемое и гибкое хранилище объектов.
3. Data Lakehouse (сочетание Data Lake и Data Warehouse)
Data Lakehouse служит мостом между Data Lake и Data Warehouse, объединяя гибкость обработки первого с возможностями структурированного управления данными второго. Такой подход позволяет обрабатывать как структурированные, так и неструктурированные данные, обеспечивая гибкость в использовании информации. По сути, Data Lakehouse сочетает в себе возможности Data Lake по работе с необработанными данными с оптимизированной производительностью запросов к структурированным данным, которые свойственны Data Warehouse. Это делает его идеальным решением для организаций, которым требуется лучшее из обоих миров: возможность легко интегрировать различные типы данных и эффективная производительность запросов для аналитических целей.
Гибкость и структура:
Data Lakehouse сочетает в себе гибкость Data Lake со структурой и производительностью Data Warehouse. Хотя данные могут храниться в структурированном виде, полуструктурированные и неструктурированные данные также могут быть обработаны и интегрированы в единую систему. Этот гибридный подход позволяет организациям эффективно работать с разнообразными типами данных, сохраняя при этом четкую структуру для аналитических целей.
Расширенная аналитика и отчетность:
В Data Lakehouse могут выполняться как SQL‑запросы, так и операции машинного обучения, что обеспечивает расширенные возможности для анализа и составления отчетов. Это позволяет организациям использовать как традиционные методы бизнес‑аналитики, так и передовые технологии обработки данных в рамках одной платформы.
Преимущества:
Сочетает высокую производительность Data Warehouse с гибкостью Data Lake.
Объединяет преимущества обоих подходов, обеспечивает благоприятную среду для работы с различными типами данных.
Недостатки:
Сложность настройки и управления: Эти архитектуры могут быть довольно сложными в настройке и управлении, поскольку они объединяют структурированные и неструктурированные данные.
Повышенные требования к управлению данными и оптимизации производительности: Для поддержания высокой производительности и эффективности требуется тщательное управление данными и их оптимизация. Это делает обслуживание таких систем более ресурсозатратным.
Платформы, используемые для реализации архитектуры Data Lakehouse:
Databricks + Delta Lake: Часто ассоциируется с архитектурой Lakehouse. Эта платформа предлагает единый подход к пакетной и потоковой обработке данных, уделяя особое внимание надежности и производительности.
Apache Iceberg: Lakehouse‑решение с открытым исходным кодом, разработанное Netflix, предлагающее такие возможности, как поддержка крупномасштабных Data Lake и ACID‑транзакций.
Apache Hudi: Решение с открытым исходным кодом, поддерживающее управление версиями данных и потоковую обработку, часто используемое для обработки больших объемов входящих данных с возможностью отслеживания изменений с течением времени.
Azure Synapse Analytics: Платформа, сочетающая возможности Data Warehouse и Data Lake, идеально подходящая для организаций, использующих Microsoft Azure, и обеспечивающая бесшовную интеграцию между обеими архитектурами.
Snowflake (с последними обновлениями): Snowflake начала предоставлять функционал Lakehouse, сочетающую производительность и возможности Data Lake и Data Warehouse.
Google BigLake: Lakehouse‑решение от Google Cloud, которое интегрирует хранение и аналитику в нескольких облаках, обеспечивая гибкую и масштабируемую обработку данных.
Выбор платформы для реализации Data Lakehouse архитектуры должен основываться как на гибкости работы с «большими данными», так и на ожидаемой производительности аналитики. Если вам необходимо сочетание потоковой передачи и пакетной обработки, а также вы ищете решения с открытым исходным кодом, то Databricks + Delta Lake — отличный вариант. Для корпоративных сред Azure рекомендуется использовать Azure Synapse Analytics, которая сочетает в себе возможности как Data Lake, так и Data Warehouse архитектуры. Интеграция BigQuery + BigLake подойдет пользователям Google Cloud, предлагая возможность комбинировать lake‑данные с аналитическими запросами. Если для вас важен контроль версий данных, соответствие требованиям ACID и оптимизация затрат, стоит рассмотреть такие решения, как Apache Hudi или Apache Iceberg. Кроме того, если вам необходимо централизованно управлять данными из разных доменов, хорошим вариантом может стать Unity Catalog, интегрированный с Databricks.
Ниже представлена таблица, которая сравнивает три описанные выше архитектуры:
4. Data Mesh
Data Mesh предлагает альтернативный подход к архитектуре, основанный на децентрализации данных. В рамках этого подхода каждый отдел в организации создает свой собственный продукт обработки данных и предоставляет другими подразделениями к нему доступ. Data Mesh делает архитектуру данных модульной и децентрализованной, что особенно актуально для крупных и сложных организаций.
Распределенное управление данными: Каждый отдел создает и обслуживает свой собственный продукт обработки/хранения данных. Это позволяет избежать централизации данных в одном месте, обеспечивая большую гибкость.
Профилактика узких мест: Благодаря отсутствию централизованной структуры управления данными, Data Mesh устраняет узкие места, которые часто возникают в традиционных централизованных системах.
Преимущества:
Распределенная структура обеспечивает более гибкое управление данными и доступ к ним.
Управление данными распределяется между различными подразделениями компании, каждое из которых отвечает за свой собственный продукт обработки данных.
Недостатки:
Отсутствие централизованного управления данными может создавать проблемы с поддержанием согласованности и целостности данных.
Рабочие процессы интеграции и обработки данных могут быть более сложными.
Платформы, используемые для реализации архитектуры Data Mesh:
AWS Lake Formation + Glue + S3: Обеспечивает доступ к данным и управление ими на основе доменов.
Databricks Unity Catalog: Поддерживает подход управления данными Data Mesh.
Starburst / Trino: Эти платформы поддерживают междоменные запросы и виртуальные базы данных (federation).
Snowflake: Этот продукт облегчает обмен данными между доменами благодаря безопасному обмену информацией.
Kafka / Event Streaming (Confluent, Redpanda): Используется для потоковой передачи данных между доменами.
DataHub / Amundsen / OpenMetadata: Специализируется на управлении метаданными и каталогизации.
Выбор платформы для реализации Data Mesh архитектуры зависит от готовности организации перейти к модели управления данными на основе доменов, которая исключает централизацию. Если подразделения вашей организации структурированы таким образом, что они независимо друг от друга разрабатывают продукты обработки данных, рекомендуется рассмотреть решения, поддерживающие централизованное управление, такие как Databricks Unity Catalog или Snowflake Secure Data Sharing. Если же необходимо объединять данные и создавать унифицированные запросы из разных источников, то следует обратить внимание на распределенные механизмы запросов, такие как Starburst или Trino. Для управления метаданными и обеспечения прозрачного обнаружения данных идеально подходят такие инструменты, как DataHub, Amundsen или OpenMetadata. Для событийно‑ориентированных сценариев, где требуется совместное использование данных, инфраструктуры Kafka и Confluent могут обеспечить передачу данных между доменами в режиме реального времени. При правильном сочетании этих инструментов и наличии четких внутренних политик владения и доступа к данным у вас есть все шансы создать успешную сетевую инфраструктуру обмена данными.
В следующей части мы детальнее остановимся на вариантах реализации архитектуры, которую мы выбрали для нашего проекта.
Недавно в Otus прошел открытый урок на тему «Корпоративный архитектор в цифровую эпоху: проводник изменений или хранитель традиций?» На нём разобрали:
Как архитектура соединяет стратегию и технологии
Роль архитектора в Agile и продуктовых командах
Кейсы успешных трансформаций и типичные ошибки
Must-have инструменты для современного корпоративного архитектора
Если эти вопросы для вас актуальны, предлагаем посмотреть урок в записи.
А чтобы получить доступ ко всем записям прошедших мероприятий, оставьте заявку на странице курса "Enterprise Architect".