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

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

Чтобы справиться с этим, компании переходят на более гибкие подходы к управлению данными. В этой статье разберем четыре наиболее популярные архитектуры: Data Warehouse, Data Lake, Data Lakehouse и Data Mesh. Обсудим, чем они отличаются и какую выбрать под конкретные задачи.

---

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

• Хранилища данных (Data Warehouse) работают со структурированной информацией.

• Озёра данных (Data Lake) предлагают гибкость для больших объемов разнородных данных.

• Лейкхаусы (Data Lakehouse) объединяют лучшее из двух предыдущих подходов, создавая оптимальную среду для аналитики.

• Сетки данных (Data Mesh) идут ещё дальше — децентрализуют управление через микросервисную архитектуру, что особенно актуально для крупных организаций с их сложным распределением ответственности.

Есть одно важное «но»: фундамент успешной архитектуры данных нужно закладывать с самого начала проектирования. И дело тут не только в технической реализации — архитектура должна работать на цели организации и вписываться в общую стратегию управления данными. Давайте разберем теоретические основы этих процессов и посмотрим на примере реального проекта, как всё это работает на практике.

Анализ требований: краеугольный камень успешной архитектуры данных

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

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

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

В нашем тестовом проекте цель — создать современное хранилище данных для консолидации информации о продажах и проведения аналитики. Платформа может быть любой — MS SQL, PostgreSQL и так далее. Главная задача: усилить механизмы принятия решений на основе данных, упростить отчетность и выдавать бизнесу по-настоящему ценные инсайты.

В нашем примере предполагается, что данные поступают из двух основных источников — ERP и CRM. 

ERP (планирование ресурсов предприятия) — это система, которая объединяет все бизнес-процессы и ресурсы компании под одной крышей. Она управляет финансами, кадрами, производством, логистикой, продажами и маркетингом — одним словом, всем хозяйством. Цель ERP — навести порядок в процессах и сделать их более прозрачными, эффективно используя ресурсы компании (время, людей, материалы, капитал).

В свою очередь, CRM (управление взаимоотношениями с клиентами) — это система для управления отношениями компании с существующими и потенциальными клиентами. CRM собирает и анализирует клиентские данные, помогая выстраивать более персонализированные и эффективные стратегии в продажах, маркетинге и поддержке.

Когда данные поступают из ERP и CRM в формате CSV, работа с файловыми источниками требует тщательного планирования и всестороннего контроля на всех этапах ETL-процесса (извлечение, преобразование, загрузка). Сырые данные часто бывают неполными, поврежденными или противоречивыми — а значит, перед анализом их придется почистить и привести в порядок.

Но одной очистки недостаточно — данные нужно ещё и интегрировать в понятную для пользователей структуру. Модель данных должна быть простой, логичной и спроектированной под проведение анализа. В нашем примере мы решили не отслеживать историческую информацию — это значит, что при загрузке учитываются только самые свежие записи. Мы выбрали этот путь, чтобы не усложнять объяснение и упростить модель.

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

Итак, в нашем проекте: 

• Будет использоваться SQL. 

• Данные поступают из ERP и CRM в CSV-файлах.

• Данные будут очищены и преобразованы в удобную для пользователей модель.

• Будут использоваться только самые свежие данные. 

• Итоговым результатом станет подробная документация.

Теперь, когда нам понятны все вводные, можно переходить к следующему этапу — проектированию архитектуры данных. 

Выбор архитектуры данных

На этом этапе решается, как будет устроено хранилище и каким образом будут обрабатываться данные. От архитектуры зависит удобство работы с данными, так что подходить к выбору нужно с умом. 

1. Хранилище данных (Data Warehouse)

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

Что обычно отличает хранилища данных:

• Строгая структура. Используются реляционные базы, где данные организованы по фиксированной схеме — строки, столбцы, типы.

• Фокус на отчетности и анализе. Хранилища оптимизированы так, чтобы аналитики данных могли легко строить отчеты. 

• ETL на входе. Данные проходят через этапы очистки и преобразования, чтобы попасть в хранилище в едином формате — чистыми, согласованными и готовыми к работе.

Преимущества хранилищ: 

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

• Простота доступа. Данные хорошо организованы, к ним легко обращаться с запросами. Аналитики могут быстро извлекать нужную информацию.

Минусы:

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

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

Платформы, на которых разворачивают хранилища данных:

1. Google BigQuery — предлагает бессерверную и высокомасштабируемую архитектуру. Отлично подходит для быстрого развертывания и обработки больших объемов данных без необходимости управлять инфраструктурой.

2. Amazon Redshift — быстрое и масштабируемое решение для хранилища данных на AWS. Идеально для проектов, уже интегрированных в экосистему AWS.

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

4. Microsoft Azure Synapse Analytics (ранее SQL DW) — объединяет хранилище данных с интеграцией больших данных. Универсальный вариант для организаций, использующих экосистему Microsoft Azure.

5. Teradata — одно из устоявшихся решений для больших данных. Часто используется в крупномасштабных локальных средах, требующих сложных решений для хранилищ данных.

6. IBM Db2 Warehouse — корпоративное решение от IBM. Подходит организациям, которым нужно надежное локальное решение с высокой безопасностью и надежностью.

Выбор платформы зависит от масштаба проекта, бюджета, технических требований и экспертизы команды. Для небольших и средних проектов могут подойти бессерверные решения вроде Google BigQuery или Snowflake — они быстро настраиваются и требуют минимального обслуживания. 

Если нужно обрабатывать информацию в реальном времени или работать с большими массивами, которые часто обновляются, лучше выбрать Snowflake — у него хорошие возможности для работы с версиями данных и высокая производительность. Для случаев, когда критична безопасность и полный контроль над данными, стоит рассмотреть on-premise решения вроде Teradata или IBM Db2 Warehouse.

2. Озеро данных (Data Lake)

Озеро данных — это гибкая архитектура, предназначенная для хранения большого объема данных в их исходном (сыром) или слабо обработанном виде. В одном хранилище могут находиться как структурированные, так и полу- и неструктурированные данные — от таблиц и логов до изображений и JSON-файлов. 

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

Преимущества: 

• Хранение разных типов данных. Озеро данных может хранить самые разные типы данных — от баз данных до текстовых файлов, изображений и прочего — в их сыром виде. Данные обычно хранятся в файловых форматах (к примеру, CSV, JSON, Parquet). Это позволяет включать как структурированные, так и неструктурированные данные, обеспечивая бОльшую гибкость в хранении.

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

• Масштабируемость. Озёра данных позволяют легко наращивать объемы и добавлять новые источники данных без предварительного планирования структуры. 

Минусы:

• Сложное управление данными. Управление данными в озере может быть непростой задачей. Без правильной организации данные могут стать сложными для обработки, что приводит к проблеме «болота данных» (data swamp) — когда данные превращаются в неорганизованную кашу, с которой трудно работать.

• Безопасность данных и контроль доступа. По сравнению с хранилищами данных, управление безопасностью и контролем доступа в озёрах данных может быть более затруднительным из-за разнообразия типов и форматов данных.

Платформы для создания архитектуры озера данных:

• Amazon S3 — самая популярная инфраструктура для создания озёр данных, обеспечивающая масштабируемое и экономически эффективное хранение огромных объемов данных.

• Azure Data Lake Storage (ADLS Gen2) — высокопроизводительное решение для озера данных на Microsoft Azure, разработанное для крупномасштабной аналитики.

• Google Cloud Storage (GCS) — решение Google Cloud для озёр данных, предлагающее масштабируемое хранение и интеграцию с другими сервисами Google Cloud.

• Apache Hadoop HDFS — предпочтительный вариант для локальных систем, обеспечивающий распределенную файловую систему для хранения и обработки больших наборов данных.

• MinIO — открытая платформа, совместимая с S3, для создания озёр данных. Предоставляет объектное хранилище, которое масштабируется и гибко настраивается.

3. Лейкхаус (Data Lakehouse) — микс озера данных и хранилища

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

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

Преимущества:

• Сочетает производительность хранилища данных с гибкостью озера данных. Объединяет плюсы обоих подходов и делает удобной работу с данными разных форматов.

• В лейкхаусе можно выполнять и SQL-запросы, и операции машинного обучения для удовлетворения аналитических потребностей и отчетности. Благодаря этому организации могут использовать на одной платформе как традиционную бизнес-аналитику, так и продвинутые методы data science.

Минусы:

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

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

Платформы для построения архитектуры лейкхауса:

• Databricks + Delta Lake — решение представляет собой классический пример архитектуры Lakehouse, обеспечивая унифицированную обработку как пакетных, так и потоковых данных с акцентом на надежность и производительность.

• Apache Iceberg — open-source решение для лейкхауса от команды Netflix, которое предлагает такие возможности, как поддержка масштабных озёр данных и ACID-транзакции.

• Apache Hudi — ещё одно решение с открытым кодом, которое поддерживает версионирование данных и потоковую обработку. Часто его используют для работы с большими объемами входящих данных, когда нужно отслеживать изменения во времени.

• Azure Synapse Analytics — платформа, которая удачно объединяет возможности хранилища данных и озера данных. Отлично подходит для организаций на Microsoft Azure благодаря бесшовной интеграции обеих архитектур.

• Snowflake (с последними обновлениями) — с недавних пор платформа начала предоставлять функциональность лейкхауса. Объединяет лучшие качества озёр данных и хранилищ — производительность и функциональность.

• Google BigLake — решение Google Cloud для лейкхауса, интегрирующее хранение и аналитику в нескольких облаках, обеспечивая гибкую и масштабируемую обработку данных.

При выборе платформы важно учитывать два фактора: гибкость big data-решений и ожидания по производительности аналитики. Если важны версионирование данных, ACID-совместимость и оптимизация затрат, обратите внимание на решения вроде Apache Hudi или Apache Iceberg. Если есть потребность централизованно управлять данными из разных доменов, Unity Catalog, интегрированный с Databricks, может стать отличным вариантом.

Подытожим различия в уже рассмотренных архитектурах: 

4. Сетка данных (Data Mesh)

Data Mesh предлагает не централизованную, а распределенную архитектуру данных. В этой модели каждое подразделение компании создает свой собственный «продукт данных» (data product) и делится им с другими. Это позволяет не сваливать все данные в одну кучу, обеспечивая гораздо большую гибкость. 

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

Преимущества: 

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

• Команды получают полную свободу в управлении своими данными и могут организовать доступ как им удобно.

• Владение данными распределяется по отделам — каждый отдел становится хозяином своего собственного «продукта данных».

Минусы:

• Без централизованного управления поддерживать порядок и целостность данных становится непросто.

• Интеграция данных и рабочие процессы обработки рискуют стать задачей со звездочкой.

Платформы для построения архитектуры Data Mesh:

• AWS Lake Formation + Glue + S3 — трио сервисов обеспечивает доступ к данным и управление ими на уровне доменов.

• Databricks Unity Catalog — отвечает за централизованное управление данными (data governance).

• Starburst / Trino — позволяют выполнять кросс-доменные запросы и объединять данные из разных источников.

• Snowflake — упрощает обмен данными между доменами через функцию Secure Data Sharing.

• Kafka / Event Streaming (Confluent, Redpanda) — удобные решения для передачи потоков данных между доменами.

• DataHub / Amundsen / OpenMetadata — платформы для работы с метаданными и каталогизацией.

Выбор платформы зависит от того, насколько организация готова перейти к модели владения данными на уровне доменов, отказавшись от централизованного подхода. Если команды способны самостоятельно разрабатывать и поддерживать data products, лучше подойдут решения с поддержкой централизованного управления — такие как Databricks Unity Catalog или Snowflake Secure Data Sharing. Для управления метаданными и удобного поиска данных подойдут DataHub, Amundsen или OpenMetadata. А если нужен обмен данными на основе событий в реальном времени — выручат Kafka или Confluent.

Всё это работает только в тех организациях, где уже есть чётко определенные правила доступа и владения данными внутри. Тогда эти инструменты складываются в полноценную Data Mesh‑инфраструктуру.

---

Как видите, у каждой архитектуры свои сильные и слабые стороны. Хранилище данных — это про порядок и быструю отчетность, но только для структурированной информации. Озеро данных — про гибкость и разнообразие, но можно утонуть в хаосе управления данными. Лейкхаус совмещает в себе лучшие черты от каждой из этих концепций. Сетка данных, в свою очередь, предлагает более гибкую и децентрализованную модель управления информацией. Правильный выбор определяется задачами проекта и планами на будущее.

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

Как устроены современные хранилища данных

От выбора подхода к проектированию хранилища данных зависит многое — насколько гибкой получится система, как быстро она будет работать и сколько нервов потратят разработчики на её поддержку. Разберем несколько популярных методологий: подход Инмона, подход Кимбалла, Data Vault и архитектуру медальона.

Подход Инмона: централизованное проектирование хранилища данных

Методология Инмона — один из наиболее ранних подходов к проектированию хранилищ данных. Согласно этой модели, создается единое корпоративное хранилище (EDW), где все данные собираются в централизованном виде. Инмон предлагает сначала нормализовать данные и только потом загружать их в хранилище, опираясь на заранее продуманную сложную модель данных.

Особенности подхода:

• Данные обычно хранятся в третьей нормальной форме (3НФ). 

• Подходит для крупных организаций: создается единое хранилище данных для всей компании.

• Интеграция данных сложная, но зато точность на высшем уровне.

Преимущества:

• Данные согласованы и хорошо организованы.

• Подходит для крупных проектов и интеграции данных на уровне всей компании.

Минусы:

• Разработка тянется долго — всё приходится перестраивать с нуля.

• Моделирование данных превращается в сложную и трудоемкую задачу.

Подход Кимбалла: хранилище данных, удобное для пользователя

Кимбалл предлагает более дружелюбный и гибкий подход по сравнению с методологией Инмона. Вместо одного большого централизованного хранилища используется набор небольших специализированных витрин данных (data marts). Информация организуется через простые схемы типа «звезды» или «снежинки».

Особенности подхода:

• Данные обычно денормализованы и оптимизированы для легкого выполнения запросов.

• Каждая витрина данных решает конкретные задачи отчетности и аналитики для своей области бизнеса.

Преимущества:

• Быстрый доступ к данным и высокая скорость запросов.

• Отлично подходит для небольших проектов или точечных аналитических задач.

Минусы:

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

• Поддерживать согласованность данных становится сложнее.

Data Vault: гибкая и модульная модель данных

Подход Data Vault предлагает свежий взгляд на проектирование хранилищ, делая ставку на гибкость и модульность. Здесь данные сохраняются в «сыром» виде, а бизнес-правила накладываются уже на этапе обработки. Такой подход особенно популярен в крупных и сложных проектах, где важна масштабируемость.

Особенности подхода:

• Обеспечивает быструю адаптацию и гибкость.

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

• Данные разделяются на три основных компонента: Hub, Link и Satellite.

Преимущества:

• Позволяет быстро интегрироваться с различными источниками данных.

• Легко адаптируется к изменяющимся требованиям бизнеса.

Минусы:

• Сложная модель данных может затруднить управление.

• Структура с множеством вспомогательных таблиц (Hub, Link, Satellite) требует больше ресурсов на хранение и увеличивает нагрузку при обработке.

Архитектура медальона: современный и упрощенный подход к проектированию хранилищ данных

Архитектура медальона — один из самых свежих подходов к созданию хранилищ. В этой модели обработка данных делится на три слоя: бронза (сырые данные), серебро (очищенные данные) и золото (данные, готовые для бизнеса).

Ключевые слои архитектуры:

• Бронзовый слой (сырые данные). Здесь данные впервые попадают в систему и хранятся в первозданном виде — никаких преобразований, никакой обработки. Цель проста: сохранить информацию именно в том виде, в каком она была получена изначально. Инженеры данных хранят сырые данные в этом слое для отладки ошибок и отслеживания происхождения данных.

• Серебряный слой (очищенные данные). На этом этапе сырые данные очищаются, нормализуются и организуются. Этот слой полностью отвечает за преобразования и процессы очистки, которые подготавливают данные к анализу. Любые пропуски или ошибки в данных исправляются, информация становится более согласованной.

• Золотой слой (готовые для бизнеса данные). На этом этапе данные приводятся в соответствие с потребностями бизнес-пользователей. Их выравнивают под инструменты бизнес-аналитики (Power BI, Tableau и другие) и оптимизируют для процессов отчетности.

Требования каждого слоя

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

Преимущества:

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

• Отслеживаемость. На каждом этапе можно точно проследить, откуда пришли данные и что с ними происходило.

• Гибкость и производительность. Слои можно обрабатывать независимо — это дает гибкость в управлении и высокую скорость обработки и запросов. 

Где применяется архитектура:

• Big Data-проекты — отлично подходит для задач, где нужно собирать и обрабатывать большие объемы данных.

• Продвинутая аналитика и ML — можно проводить сложный анализ как на сырых данных в бронзовом и серебряном слоях, так и на подготовленных данных золотого слоя.

• Потребности хранилищ данных и бизнес-аналитики — решение прекрасно подходит как для проектов хранилищ данных, так и для бизнес-аналитики.

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

Визуализация архитектуры хранилища данных

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

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

Заключение

Архитектура данных — это не просто набор технических решений. Это стратегический и организационный выбор, который формирует будущее работы с информацией в компании. Мы прошлись по основным подходам — от классических хранилищ данных до современных озёр, лейкхаусов и сеток данных, разобрали их сильные и слабые стороны, выяснили, где какой подход работает лучше всего, и познакомились с платформами для их реализации. На живом примере проекта показали, как происходят анализ требований, работа с источниками данных, ETL-процессы, моделирование и документирование, и как в этом всём применяются современные архитектуры типа медальона.

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