Как создать хранилище данных: пошаговое руководство от архитекторов данных Cronit
Конечной целью могут быть продвинутая аналитика и ИИ, однако путь к ним зачастую начинается с понимания того, как создать хранилище данных. Прежде чем данные превратятся в наглядные отчёты и визуализации, их необходимо собрать, структурировать и упорядочить. Современные панели мониторинга и инструменты бизнес-аналитики выглядят простыми и удобными в использовании, однако их эффективность основана на качественно подготовленных данных, объединённых в грамотно спроектированном хранилище данных.
Создание хранилища данных – сложная задача, требующая значительных инвестиций, глубоких архитектурных знаний и понимания как классических подходов, так и современных практик работы с данными. Кроме того, важно заранее учитывать типичные ошибки и риски, из-за которых подобные проекты нередко сталкиваются с задержками или не достигают поставленных целей.
Архитекторы данных Cronit подготовили практическое пошаговое руководство по проектированию хранилища данных. Оно поможет разобраться в ключевых этапах создания архитектуры, способной стать надёжной основой для аналитики любого уровня сложности.
Что такое хранилище данных?
Хранилище данных (Data Warehouse) – это централизованное предметно-ориентированное хранилище информации, предназначенное для аналитики и формирования отчётности. В отличие от транзакционных баз данных, оно объединяет данные из различных источников в единую структуру, подготовленную для выполнения аналитических запросов и поддержки бизнес-аналитики в масштабах всей организации. Иными словами, это единый, управляемый и согласованный источник достоверных данных, на который могут опираться аналитические системы и отчётность.
Может возникнуть вопрос: почему нельзя обращаться к исходным системам напрямую? Проблема заключается в том, что данные в них часто представлены по-разному. Форматы хранения, часовые пояса, правила именования и даже способы учёта одних и тех же объектов могут отличаться.
Перед загрузкой в хранилище данные очищаются от шума и дубликатов, приводятся к единому формату, дополняются метаданными и при необходимости агрегируются с различной степенью детализации. Например, отдельные операции продаж могут быть преобразованы в ежедневные показатели по магазинам или ежемесячную выручку по регионам для решения различных аналитических задач. После формирования единого представления корпоративных данных хранилище становится надёжной основой для систем бизнес-аналитики и решений на базе искусственного интеллекта.
Чтобы отчёты были не только наглядными, но и достоверными, правильно спроектированное хранилище данных должно включать несколько уровней контроля качества данных. Эти проверки позволяют убедиться в корректности загружаемой информации. Предположим, что в системе управления взаимоотношениями с клиентами (CRM) зарегистрировано десять заказов. При загрузке данных в хранилище необходимо получить все эти заказы, а также связанные с ними платежи из финансовой системы. Зрелое хранилище данных автоматически проверяет, что каждый заказ и соответствующий ему платёж были успешно загружены, а дублирование данных отсутствует. Если система обнаруживает несоответствия, они выявляются до того, как приведут к ошибкам в отчётности.
Хранилище данных, озеро данных, платформа Lakehouse, база данных и витрина данных: в чём разница?
Существует множество способов хранения данных, и выбор подходящего решения обычно зависит от одного вопроса: какую ценность бизнес планирует получить из этих данных? Различия в типах хранимой информации и подходах к её организации привели к появлению большого количества терминов, описывающих различные системы хранения данных. Разберёмся в них подробнее.
База данных – это структурированное хранилище информации, используемое для повседневных операций и обработки транзакций. Базы данных могут быть реляционными (структурированные таблицы со связями между ними) и нереляционными, предназначенными для работы с полуструктурированными и неструктурированными данными, например документами или файлами JSON.
Хранилище данных представляет собой специализированную реляционную базу данных, предназначенную для хранения предварительно обработанной информации из различных корпоративных систем и её последующего использования в аналитике и отчётности.
Озеро данных (Data Lake) можно рассматривать как централизованное хранилище необработанных данных, для которого не требуется строгая схема хранения или предварительная подготовка информации. В него можно быстро загружать структурированные, полуструктурированные и неструктурированные данные из большого количества источников, чтобы позже очистить, структурировать и использовать их для анализа.
Платформа Lakehouse объединяет преимущества хранилища данных и озера данных. Такой подход позволяет работать как с подготовленными аналитическими данными, так и с задачами машинного обучения и обработки больших объёмов информации в единой среде.
Витрина данных (Data Mart) – это специализированный раздел хранилища данных, предназначенный для решения задач конкретного подразделения компании, например отдела продаж, маркетинга или управления персоналом.
Существует также понятие «болото данных» (Data Swamp) – состояние, в которое может превратиться озеро данных при отсутствии должного управления. Если данные накапливаются без структуры, описаний и метаданных, озеро постепенно становится трудно использовать, а поиск и анализ информации превращаются в сложную задачу.
Зачем компаниям создавать хранилище данных?
Рано или поздно любая компания сталкивается с одной и той же проблемой: данные накапливаются в разных системах, остаются разрозненными и не позволяют получить целостное представление о работе бизнеса. Именно в этот момент руководство обычно принимает решение о создании единой аналитической среды. На практике именно тогда проекты по внедрению бизнес-аналитики и построению хранилища данных начинают получать поддержку и финансирование.
Хранилище данных обеспечивает быструю и надёжную передачу информации в системы бизнес-аналитики, открывая доступ к историческим данным, данным, обновляемым в режиме реального времени, прогнозной аналитике и другим видам анализа, необходимым для принятия решений.
Помимо более быстрого и обоснованного принятия решений, создание хранилища данных даёт бизнесу ряд дополнительных преимуществ:
Единый источник достоверных данных. Все подразделения работают с согласованной и проверенной информацией, поскольку качество, точность и непротиворечивость данных поддерживаются в хранилище и связанных отчётах.
Повышение операционной эффективности. Снижается объём ручной работы по сверке, объединению и очистке данных.
Упрощение управления данными и соблюдения нормативных требований.Проще отслеживать происхождение данных, применять политики управления данными и выполнять требования регуляторов.
Ускорение интеграции новых систем. Подключение корпоративных приложений, аналитических платформ и моделей ИИ становится проще и надёжнее.
Улучшение взаимодействия между подразделениями. Сотрудники получают доступ к единым наборам данных и могут уверенно использовать их в работе.
Подходы к проектированию хранилища данных
Прежде чем сравнивать различные подходы к проектированию, полезно понять, из каких компонентов состоит хранилище данных.
С функциональной точки зрения, то есть с позиции жизненного цикла данных внутри хранилища, его архитектура включает четыре уровня:
Уровень источников данных (Source Layer) – точка входа в архитектуру хранилища данных, откуда поступает информация из баз данных, корпоративных систем, внешних программных интерфейсов (API) и других источников.
Промежуточный уровень (Staging Layer) – временная область хранения данных при их перемещении из исходных систем в хранилище данных. На этом этапе выполняются проверки качества данных, выявление ошибок и контроль целостности, чтобы предотвратить попадание на уровень хранения дубликатов, пропущенных значений, несоответствий и других аномалий.
Уровень хранения данных (Storage Layer) – центральное хранилище, в котором обработанные, очищенные и структурированные данные сохраняются для долгосрочного использования.
Уровень представления данных (Presentation Layer) – конечный уровень архитектуры, на котором пользователи получают доступ к данным через инструменты бизнес-аналитики, платформы визуализации данных и другие пользовательские интерфейсы.
В зависимости от распределения уровней архитектура хранилища данных может быть следующей:
Одноуровневая архитектура. Все компоненты – от источников данных до пользовательского доступа – располагаются в едином контуре.
Двухуровневая архитектура. Уровень представления данных выделяется отдельно от остальных компонентов.
Трёхуровневая архитектура. Уровень источников данных, уровень хранения и уровень представления данных разделены и функционируют независимо друг от друга.
По мере роста числа источников данных, усложнения аналитических задач и увеличения количества пользователей возрастает потребность в разделении компонентов архитектуры. Если одноуровневая архитектура подходит для небольших хранилищ данных объёмом до 100 ГБ, то крупные и сложные системы обычно выигрывают от использования трёхуровневой архитектуры, которая обеспечивает лучшую масштабируемость, производительность и удобство сопровождения.
Теперь, когда мы рассмотрели основные уровни архитектуры хранилища данных, перейдём к трём наиболее распространённым подходам к его проектированию: Inmon, Kimball и Data Vault. Каждый из них определяет принципы построения архитектуры хранилища данных, организацию витрин данных и подходы к управлению изменениями в дальнейшем.
Подход Inmon (нисходящий подход)
Подход Inmon, разработанный Биллом Инмоном, предполагает сначала создание централизованного хранилища данных с высокой степенью нормализации, а затем построение на его основе специализированных витрин данных.
Подход Inmon основан на использовании нормализованных схем данных, соответствующих третьей нормальной форме (3NF). Данные организуются по предметным областям: клиенты, заказы, товары и другие сущности хранятся в отдельных таблицах, связанных между собой с помощью первичных и внешних ключей.
Хотя схемы, построенные в соответствии с третьей нормальной формой (3NF), обеспечивают высокую степень согласованности и интеграции данных, они не предназначены для непосредственного использования бизнес-пользователями. Получение аналитической информации из таких структур требует сложных запросов и большого количества соединений между таблицами, поэтому для пользовательской аналитики обычно необходимы дополнительные уровни преобразования данных.
Подход Kimball (подход «снизу вверх»)
В отличие от подхода Инмона, подход Кимбалла, также известный как подход «снизу вверх» при проектировании хранилищ данных, предполагает создание отдельных витрин данных для подразделений с последующим формированием корпоративного хранилища данных на их основе. В основе этого подхода лежит многомерное моделирование данных, предусматривающее использование схем типа «звезда» и «снежинка».
Такие многомерные схемы обеспечивают высокую скорость выполнения запросов и удобство аналитической работы благодаря следующим преимуществам:
- возможность гибко анализировать данные в различных разрезах;
- простота расширения модели при изменении бизнес-требований;
- высокая производительность при работе с реляционными базами данных.
Подход Data Vault
Сегодня многие организации отдают предпочтение третьему подходу к моделированию данных – Data Vault, предложенному Дэном Линстедтом. Этот подход считается гибридным, поскольку сочетает в себе элементы централизованной нормализованной архитектуры Инмона и многомерного моделирования, лежащего в основе подхода Кимбалла.
Модель Data Vault основана на модульной структуре, включающей три основных компонента:
Хабы – содержат ключевые бизнес-сущности, идентифицируемые с помощью бизнес-ключей и суррогатных ключей.
Связи – описывают отношения между бизнес-сущностями, представленными в хабах.
Сателлиты – содержат описательные атрибуты и исторические данные, сгруппированные по источникам информации или частоте изменений.
Такая структура позволяет подключать новые источники данных без перестройки существующей модели. Благодаря этому подход Data Vault сочетает производительность запросов с высокой гибкостью, масштабируемостью и способностью быстро адаптироваться к изменениям бизнес-процессов и появлению новых взаимосвязей между данными.
| Подход | Основная идея | Преимущества | Ограничения | Наиболее подходит для |
| Inmon (сверху вниз) | Сначала создаётся централизованное нормализованное корпоративное хранилище данных, затем на его основе формируются витрины данных. |
• Высокая степень интеграции и согласованности данных. • Чёткое управление данными. • Подходит для межфункциональной отчётности. |
• Менее удобен для самостоятельной работы пользователей с данными. • Более длительный срок получения первых результатов. • Сложные запросы для конечных пользователей. |
Крупных организаций, для которых приоритетны интеграция данных, их качество и централизованное управление данными. |
| Kimball (снизу вверх) | Сначала создаются многомерные витрины данных для отдельных подразделений, которые затем объединяются в единое корпоративное хранилище данных. |
• Быстрое получение аналитических результатов. • Удобство для аналитиков и бизнес-пользователей. • Высокая производительность на реляционных базах данных. |
• Риск появления большого количества разрозненных витрин данных при недостаточном управлении. • Сложнее обеспечить единообразие данных в масштабе всей организации. |
Компаний, которым важно быстро получить аналитические возможности и обеспечить удобную самостоятельную работу с данными в системах бизнес-аналитики. |
| Data Vault (DV) | Гибридный подход: интеграция данных выполняется по принципам Inmon, а аналитика строится через витрины данных по аналогии с Kimball. |
• Простое подключение новых источников данных без перестройки модели. • Полное сохранение истории изменений и высокая прослеживаемость данных. • Хорошая масштабируемость и гибкость развития модели. |
• Более сложное проектирование процессов загрузки и преобразования данных (ETL/ELT). • Для эффективной эксплуатации часто требуются средства автоматизации на основе метаданных. |
Организаций с большим количеством постоянно меняющихся источников данных, высокими требованиями к аудиту и соблюдению нормативных требований, а также необходимостью предоставления аналитики через витрины данных. |
Четыре этапа создания хранилища данных
Несмотря на то что каждый проект имеет свои особенности, при создании хранилища данных обычно используются одни и те же основные этапы.
Ниже приведён пошаговый процесс создания хранилища данных. Он одинаково применим как при построении нового хранилища данных с нуля, так и при расширении существующей аналитической платформы. В зависимости от количества источников данных, масштаба проекта и выбранного подхода к проектированию весь процесс обычно занимает от трёх до девяти месяцев.
1. Предпроектное обследование
На этапе предпроектного обследования закладывается фундамент будущего решения. Все последующие работы – от проектирования до внедрения – опираются на результаты этого этапа.
Прежде всего необходимо определить бизнес-цели, которых компания планирует достичь с помощью хранилища данных. Затем анализируются существующие проблемы, приоритеты и ожидания бизнеса, а также оцениваются текущие процессы и доступные источники данных.
Если в компании используются сотни источников данных, потребуется время, чтобы разобраться в их содержимом, структуре и роли в аналитических процессах. Попытка сразу приступить к созданию хранилища данных без такого анализа часто приводит к дорогостоящим ошибкам, связанным с неудачно спроектированными моделями данных или избыточными процессами извлечения, преобразования и загрузки данных (ETL/ELT).
После детального анализа всех источников данных определяется архитектура будущего хранилища: количество уровней, способы передачи данных между ними, а также место выполнения преобразований данных – с использованием процессов извлечения, преобразования и загрузки данных (ETL) либо извлечения, загрузки и преобразования данных (ELT).
На этом же этапе принимается решение о варианте размещения хранилища данных: в собственной инфраструктуре, в облачной среде или в гибридной инфраструктуре. Хотя размещение в собственной инфраструктуре сегодня встречается реже, оно остаётся оптимальным вариантом для организаций, которым необходим полный контроль над данными и инфраструктурой, например при выполнении жёстких требований по защите и хранению информации.
Для большинства компаний облачные и гибридные решения обеспечивают лучшую масштабируемость, сокращают сроки внедрения и снижают эксплуатационные затраты, сохраняя при этом возможность контролировать критически важные данные. Сегодня на рынке представлены такие платформы, как Snowflake, Amazon Redshift и Google BigQuery, которые позволяют быстро развернуть хранилище данных и эффективно обрабатывать разные виды аналитической нагрузки без необходимости сложного администрирования инфраструктуры.
2. Проектирование логической и физической модели данных
Сначала разрабатывается логическая модель данных. Инженеры данных анализируют документированные бизнес-процессы и определяют ключевые сущности, например клиента, заказ, устройство, поставку или обращение, а также взаимосвязи между ними. На этом этапе определяются бизнес-ключи и формулируются основные правила, которые должны соблюдаться в системе.
После согласования логической модели специалисты переходят к проектированию физической модели данных:
- каждая сущность преобразуется в одну или несколько таблиц;
- бизнес-ключи преобразуются в столбцы первичных ключей или составные хэш-идентификаторы;
- выбираются типы данных, которые обеспечивают нужную точность хранения и не приводят к избыточным затратам на хранение и обработку.
Именно на этом этапе принимаются решения о том, как будет храниться информация, чтобы обеспечить быстрый доступ к данным, сохранить их точность и поддерживать масштабирование системы без чрезмерного роста затрат. Здесь же определяются базовые правила безопасности и разграничения доступа к данным, включая права пользователей на просмотр отдельных полей и наборов данных.
3. Внедрение процессов обработки данных, тестирование и развёртывание хранилища данных
На этом этапе хранилище данных начинает работать как полноценная система: данные автоматически поступают из источников в хранилище. Чтобы этот поток был стабильным и надёжным, необходимо выполнить ряд задач:
- написать сценарии преобразования данных, например SQL-запросы или модели dbt;
- настроить управление последовательностью процессов, например направленные ациклические графы задач Airflow для ежедневных запусков;
- реализовать загрузку только новых или изменённых данных, при которой обрабатываются только новые или изменённые данные;
- настроить проверки качества данных: количество записей, пустые значения, ссылочную целостность;
- организовать ведение журналов и оповещения о сбоях.
Особое внимание следует уделить тестированию. Оно должно охватывать все ключевые аспекты качества данных:
точность данных: совпадает ли общая выручка в хранилище данных с показателями в исходных системах;
полнота данных: все ли записи загружаются ежедневно;
логика преобразований: правильно ли рассчитываются производные показатели, например средний чек;
производительность: достаточно ли быстро выполняются запросы для пользователей.
4. Сопровождение и поддержка после запуска
После ввода хранилища данных в эксплуатацию необходимо обеспечить его постоянный мониторинг и сопровождение. Работоспособность системы нужно непрерывно контролировать, а возникающие проблемы – своевременно выявляться и устраняться.
По мере появления новых источников данных, изменения бизнес-требований или необходимости доработки процессов извлечения, преобразования и загрузки данных (ETL) специалисты по сопровождению должны обеспечивать внесение всех необходимых изменений и поддерживать стабильную работу хранилища данных.
Практические рекомендации по созданию хранилища данных от архитекторов данных Cronit
Прежде чем приступать к созданию хранилища данных, стоит ознакомиться с рекомендациями, которые наши архитекторы данных выработали на практике. Эти советы помогут сократить объём доработок и быстрее получить отдачу от проекта независимо от того, создаёте ли вы хранилище данных с нуля или модернизируете существующее решение.
Привлекайте ключевых специалистов с самого начала. На ранних этапах проекта должны участвовать архитектор данных, архитектор решений, разработчики процессов извлечения, преобразования и загрузки данных (ETL), инженеры данных, системные аналитики и другие профильные специалисты.
Взаимодействуйте с представителями всех заинтересованных подразделений. Это позволит учесть требования и ожидания различных команд и создать решение, которое действительно решает бизнес-задачи.
Храните данные на максимально детализированном уровне. Сохраняйте данные в их исходной детализации, чтобы при необходимости можно было повторно обработать информацию без потери точности. Чтобы избежать роста затрат на хранение каждого события, транзакции или записи, используйте слой необработанных данных (Raw/Bronze) в таких хранилищах объектов, как Amazon S3, Google Cloud Storage или Azure Blob Storage.
Централизуйте бизнес-логику. Все показатели и правила расчёта метрик должны определяться в хранилище данных, а не на уровне отдельных аналитических панелей. Это обеспечивает единообразие результатов во всей организации.
Постоянно контролируйте качество данных. Проверки на наличие пропущенных, противоречивых или устаревших данных должны выполняться до передачи информации в системы бизнес-аналитики. Это позволяет выявлять проблемы до их появления в отчётах и аналитических панелях.
Проектируйте процессы извлечения, преобразования и загрузки данных (ETL), а также извлечения, загрузки и преобразования данных (ELT) с учётом обработки ошибок и восстановления данных. Необходимо обеспечить возможность исправления отсутствующих или повреждённых данных без нарушения работы отчётности и аналитических систем.
Выстраивайте надёжное управление данными. Трассируемость данных, назначение ответственных за данные, регулярные проверки качества и процессы непрерывного совершенствования должны стать неотъемлемой частью стратегии управления данными.
Где чаще всего возникают сложности при создании хранилища данных
По нашему опыту участия во множестве подобных проектов, около 80% сложностей связаны именно с качеством данных.
Когда начинается работа с данными, заказчик ожидает увидеть их интегрированными и готовыми для формирования отчётности. Однако на практике часто оказывается, что между данными отсутствуют необходимые связи. В результате приходится подключать дополнительные наборы данных, сопоставлять записи из разных источников и восстанавливать недостающую информацию.
Преобразование разрозненных и неполных данных в надёжную основу для аналитики – трудоёмкая и непростая задача. Тем не менее при наличии необходимой экспертизы и внимательной работы с данными её можно успешно решить.
К другим сложностям, которые часто возникают при внедрении хранилища данных, относятся:
определение способов получения данных из устаревших информационных систем и обеспечение надёжного доступа к ним;
поиск баланса между обработкой постоянно растущих объёмов данных и сохранением высокой производительности запросов;
поддержание соответствия проекта постоянно меняющимся бизнес-требованиям.
Надёжность аналитики и отчётности зависит от качества хранилища данных
Даже самые современные аналитические решения теряют ценность, если хранилище данных, на котором они основаны, организовано неправильно. В работе с данными действует простое правило: качество результата напрямую зависит от качества данных и архитектуры их хранения.
Создание масштабируемого хранилища данных редко бывает простой задачей. Оно требует выявления взаимосвязей между разрозненными данными, устранения несоответствий и преобразования сложной информационной среды в надёжную основу для аналитики. Попытка выполнить эту работу без необходимого опыта может привести к ошибкам в отчётности, постоянным доработкам и дополнительным затратам. При участии опытных специалистов данные становятся частью единой управляемой системы, а аналитические решения становятся надёжным инструментом для принятия решений.
Часто задаваемые вопросы
Что такое современное хранилище данных?
Как создаётся хранилище данных?
Какие технологии используются при проектировании хранилища данных?
Какие проекты по созданию хранилищ данных реализует Cronit?
Сколько времени занимает создание хранилища данных?
Какие этапы включает создание хранилища данных?
1) определение источников данных, целей проекта и заинтересованных сторон;
2) проектирование логической и физической модели данных с использованием подходов Inmon, Kimball или Data Vault;
внедрение процессов обработки данных, тестирование и развёртывание решения;
3) сопровождение, поддержка и развитие хранилища данных после запуска.