Собрали для вас подробный материал про DWH — корпоративное хранилище данных:
Что такое DWH и как работает Data Warehouse
Какие задачи решает корпоративное хранилище данных и как применяется в бизнесе
Архитектура, подходы к проектированию и компоненты стека DWH
Чем DWH отличается от базы данных и Data Lake
Как внедряется корпоративное хранилище данных
Какие ошибки при внедрении DWH бывает
Нужно ли вам корпоративное хранилище данных
Этот разбор DWH — от базовых понятий до архитектуры и стека — даст вам целостное понимание и поможет закрыть ключевые вопросы о хранилищах данных.
Что такое DWH простыми словами
DWH (Data Warehouse, корпоративное хранилище данных, КХД) – система, которая собирает, структурирует и обрабатывает данные из разных источников, а также готовит их для бизнес-аналитики и отчетности.
В большинстве компаний ведется учет всех данных, необходимых для принятия решений, но они хранятся в разных системах. При необходимости аналитики или отчетности возникают сложности:
Ручной сбор данных отнимает время и не исключает ошибок
Не все данные подходят для аналитики - их надо актуализировать, очистить, обогатить
Хранение исторических данных в операционных БД нецелесообразно, теряется часть важной информации
Готовые отчеты нужно ждать, и бизнес не может принимать своевременные решения на их основе
DWH решает проблемы сбора, хранения и быстрой доставки в BI как текущих, так и архивных данных компании.
Как работает Data Warehouse
1. Источниками данных для хранилища могут выступать:
CRM-системы
ERP-системы
Базы данных
Excel-файлы
Личные кабинеты маркетплейсов
И другие
2. С помощью ETL (Extract, Transform, Load) и ELT (Extract, Load, Transform)- процессов данные извлекаются из источников, очищаются, преобразуются и загружаются в DWH
3. В хранилище данные приводятся к единой структуре, связываются между собой и формируются в витрины данных (data marts) - срезы данных, ориентированные на конкретную задачу бизнеса
4. Подготовленные данные становятся доступными для BI-аналитики, отчетности, а также используются в ML, AI и других data-проектах
Какие задачи решает корпоративное хранилище данных
BI-аналитика в сочетании с единым корпоративным хранилищем данных помогает бизнесу в следующих задачах:
Централизация и обеспечение доступа к данным
DWH объединяет данные из разных систем, очищает и приводит их к единой структуре для удобной и эффективной аналитики
Повышение скорости аналитики
Если данные хранятся в сотнях тысяч строк, на выполнение стандартных запросов уходит много времени. DWH позволяет строить отчеты в BI значительно быстрее
Единая версия данных для бизнеса
После внедрения DWH все пользователи работают с едиными согласованными данными, доступными в BI в виде готовых дашбордов
Анализ исторических данных и трендов
DWH хранит как текущие, так и исторические данные, что позволяет анализировать динамику и строить прогнозы
Снижение нагрузки на информационные системы
Подготовка данных к анализу в пространстве КХД помогает снизить нагрузку на операционные ИС и улучшить их производительность
Создание персональных отчетов и дашбордов
Хранилище позволяет настраивать доступ к данным и формировать отчеты с учетом ролей и задач пользователей
Обеспечение безопасности данных
DWH обеспечивает контроль доступа, шифрование и мониторинг данных для защиты конфиденциальной информации (соблюдение 52-ФЗ или GDPR)
Примеры применения DWH в бизнесе
Корпоративные хранилища данных применяются в большинстве отраслей, где важно работать с большими объемами данных и строить аналитику по разным направлениям бизнеса
Компания с распределенной сетью продаж
Описание ситуации и результатов от внедрения DWH
Ситуация:
В компании аналитика строилась на данных из нескольких ключевых систем, сайта, мобильного приложения, CRM, выгрузок 1С и маркетинговых сервисов.
Данные для коммерческого отдела собирали из систем на уровне SQL-запросов и визуализировали в BI, финансовый отдел формировал отчеты вручную в Excel, скачивая данные из внутреннего портала отчетности, маркетинг запрашивал у ИТ-отдела выгрузки из нужных баз данных.
Руководство было лишено целостной картины бизнеса, а с ростом числа каналов продаж и новыми структурными изменениями проблема усугублялась.
Решение:
Проведено внедрение DWH на базе ClickHouse с построением централизованного контура интеграции данных.
В соответствии с требованием к отчетам настроена инкрементальная загрузка данных: крупные таблицы обновляются по дельте, часть данных загружается полностью по расписанию.
Отдельное внимание уделено качеству данных: внедрены дополнительные справочники и мэппинги для нормализации данных по городам, каналам и поставщикам.
Результат:
После проектирования DWH, интеграции источников и наведения порядка в данных следующим этапом проекта стало внедрение единой BI-аналитики по продажам.
DWH в сочетании с BI позволило руководителям за несколько минут получать единые отчеты, оценивать динамику продаж и сравнивать факт с запланированными показателями в разрезе регионов, каналов продаж, периодов.
Общий объем данных в хранилище на сегодняшний день превышает 1 млрд строк, данные хранятся с 2019 года. Компания получила единый источник данных, повысила точность аналитики и заложила основу для дальнейшего развития аналитики.
FMCG-сеть дискаунтеров с 400+ магазинами
Описание ситуации и результатов от внедрения DWH
Задача:
Для формирования отчетности по продажам, логистике, складскому учету компания использовала выгрузки из ERP и кассовой системы.
Данные были разрозненными, не всегда согласованными и требовали ручной обработки, из-за чего подготовка отчетов занимала значительное время. Производительность аналитических запросов напрямую к системам-источникам была низкой.
Динамический рост бизнеса и формат торговли усилили важность быстрой аналитики.
Решение:
Для решения задачи было внедрено DWH, которое объединило данные из всех источников и обеспечило их регулярную загрузку и обработку.
Стек DWH выбран в соответствии с требованиями бизнеса к real-time отчетности, данные на DDS появляются уже через 30–40 секунд после формирования в источнике. Реализована задача сохранения в DWH истории изменений справочников, включая удаленные записи.
Для реализации всех доработок в процессе проекта несколько раз был пересмотрен сайзинг и произведено расширение конфигурации узлов DWH на уровень, достаточный для текущего объема данных, полной нагрузки по репликации всех таблиц и дальнейшего масштабирования.
Результат:
Реализация DWH позволила достигнуть ключевые цели компании в области управления данными:
Построить модель данных, охватывающую все требования к формам отчетности и расчету ключевых показателей
Упростить доступ к информации для всех заинтересованных лиц компании, от топ-менеджмента до отделов продаж и закупок
Снизить нагрузку на операционные системы компании и повысить производительность аналитических запросов даже при большом объеме данных - более 15ТБ
Обеспечить ретроспективный анализ благодаря сохранению исторических данных за последние 5 лет
Повысить общее качество данных для более точных решений на их основе
Производитель и селлер детской одежды
Описание ситуации и результатов от внедрения DWH
Задача:
Компания сталкивались с болью каждого селлера, работающего на нескольких площадках — мониторингом показателей и подготовкой отчетов.
Данные о продажах, заказах, остатках и рекламе поступали из разных источников: личных кабинетов МП (WB, Ozon), 1С, MPStats и других учетных систем.
Данные отличались по структуре, обновлялись с разной периодичностью и не позволяли получить целостную картину бизнеса без ручной обработки.
Решение:
Внедрено DWH и настроены процессы регулярной загрузки, нормализации и объединения данных, сформированы витрины для анализа ключевых метрик: продаж, остатков, оборачиваемости, эффективности рекламы и логистики.
В связи с ручным заполнением карточек на маркетплейсах, идентичные позиции в 1C, OZON и Wildberries не совпадали. Для решения проблемы было проведено исследование данных и подготовлен единый справочник на 25 000 позиций.
Разработан регламент выгрузки данных из MPStats, где были зафиксированы периоды выгрузки по категориям, показателям и конкретным отчетам.
На базе витрин DWH реализованы BI-дашборды по основным бизнес-сценариям: Аналитика по товарам, ABC и XYZ анализ, Воронка, Управление запасами и движением остатков и т.д.
Результат:
В общей сложности в DWH хранятся порядка 230 млн строк данных по маркетплейсам (более 9Гб данных). Достигнутая глубина хранения данных позволяет проводить многомерный анализ продаж и совершенствовать процессы планирования, начиная от пошива товара и установки цен, заканчивая контентом для карточек на маркетплейсах.
Скорость подготовки отчетов экономит часы рабочего времени, ранее затрачиваемые на сбор таблиц и подсчеты метрик в Excel.
Получив наглядную картину процессов, компания устранила до 80% ошибок, которые ранее возникали при планировании отгрузок товаров на маркетплейсы.
Архитектура DWH
Архитектура DWH описывает, как устроено хранилище: какие уровни в нем есть, как данные движутся от источников к потребителям, и какие сервисы обеспечивают эти процессы.
Трехуровневая модель DWH
Концептуально DWH представляет собой трехуровневую структуру:
1. Нижний уровень (Bottom tier) — источники и инструменты интеграции. Здесь данные извлекаются из CRM, ERP, операционных БД, файлов и API
2. Средний уровень (Middle tier) — сервер хранилища, в котором данные приводятся к единой структуре и подготавливаются для анализа
3. Верхний уровень (Top tier) содержит потребители данных: BI, инструменты визуализации и отчетности, ML и AI, OLAP-кубы
Это базовая схема, которая показывает, как данные проходят путь от источников до бизнес-решений.
Для практической реализации ее детализируют — чаще всего через слоеную архитектуру LSA.
Layered Scalable Architecture (LSA) - принцип слоеного пирога
Многоуровневая (слоеная) архитектура LSA – Layered Scalable Architecture — это развитие классической трехуровневой модели до конкретных слоев данных.
LSA содержит в себе:
Стейджинг и слой первичных данных (Staging / Primary Data Layer)
На стейджинге данные временно приземляются из источников «как есть», в Primary Data Layer сохраняются уже с историей изменений. Структура повторяет источник — без преобразований.
Операционный слой (ODS, Operational Data Store)
Опциональный слой между источниками и ядром. Содержит очищенные и интегрированные оперативные данные. Используется, когда бизнесу нужна near-real-time отчетность по операционным процессам.
Ядро хранилища (Core Data Layer)
Центральный слой DWH, в котором данные приводятся к единой системе ключей и атрибутов, обогащаются и сохраняются с историей. Здесь обеспечивается целостность, полнота и качество данных. Основной подслой — DDS (Detail Data Store) с максимально детализированными данными в единой модели.
Слой витрин данных (Data Mart Layer)
Витрины данных - структурированные наборы данных, собранные под конкретные задачи бизнеса и подразделения. Именно этот слой используется для аналитики в BI.
Сервисный слой (Service Layer)
Обеспечивает управление всеми уровнями хранилища. Включает оркестрацию, мониторинг, алертинг, логирование, сквозной аудит данных (data lineage) и каталог данных (data catalog).
Главный принцип LSA: каждый слой получает данные только из соседнего и может быть полностью пересобран из него без обращения к источникам. Это дает хранилищу устойчивость к изменениям и возможность масштабирования.
DWH в общей инфраструктуре данных - подход a16z
Архитектура DWH не существует в вакууме — хранилище встраивается в более широкую инфраструктуру работы с данными компании.
Концепция Unified Data Infrastructure, предложенная фондом a16z, описывает эту инфраструктуру как единую платформу, в которой DWH играет роль слоя хранения (Storage) — единой версии правды для всех потребителей данных.
Подход рассматривает данные как стратегический актив: они перестают быть побочным результатом операций и становятся основой для принятия решений. Конкретные технологии для каждого слоя инфраструктуры подбираются под задачи компании.
Подходы к проектированию DWH
Подход к проектированию определяет, как именно смоделированы данные внутри хранилища. Выбор подхода к проектированию — это не только техническое, но бизнес-решение: от него зависят сроки реализации и стоимость дальнейшего развития DWH.
Хранилище по Кимбаллу – витрины под задачи бизнеса
DWH строится «снизу вверх»: сначала проектируются витрины данных под отдельные бизнес-направления (продажи, маркетинг, финансы), которые затем объединяются через общие измерения (conformed dimensions) в единое хранилище. В основе — денормализованные модели «Звезда» (star) и «Снежинка» (snowflake).
Когда подходит: нужно быстро получить результат по конкретным направлениям аналитики, бизнес готов идти итеративно
Централизованное хранилище по Инмону
Подход «сверху вниз»: сначала создаётся централизованное нормализованное хранилище на уровне всего предприятия (Enterprise Data Warehouse, EDW) в третьей нормальной форме (3NF), а уже из него формируются витрины под задачи подразделений.
Когда подходит: крупная компания с большим количеством доменов и высокими требованиями к согласованности данных, готовая инвестировать в долгий старт ради простой эволюции в будущем.
Data Vault
Гибридный подход, сочетающий нормализацию по Инмону с гибкостью к изменениям источников. Современный стандарт — Data Vault 2.0 — это не только модель данных, но и методология (хеш-ключи, бизнес-правила, вынесенные на уровень витрин, и встроенная аудируемость).
Модель строится вокруг трех сущностей:
Hub — бизнес-объекты (клиенты, заказы)
Link — связи между объектами (например, факт оформления заказа клиентом)
Satellite — атрибуты и история изменений
Когда подходит: Много источников, схемы которых регулярно меняются; высокие требования к историчности и аудируемости (банки, телеком, госсектор).
Основные компоненты стека DWH
DWH как централизованная система состоит из программных компонентов, каждый из которых отвечает за процессы обработки данных: загрузку из источников, трансформацию, хранение, подготовку к аналитике и т. д.
Обычно DWH строится на open-source стеке, так как такие инструменты дают необходимую для сложной системы гибкость, масштабируемость и сокращение затрат.
ETL и ELT: как данные попадают в хранилище
Данные не появляются в DWH сами по себе — за наполнение корпоративного хранилища отвечают ETL и ELT-процессы. Они позволяют автоматизировать поток данных и исключить их ручной сбор и обработку.
ETL (Extract → Transform → Load)
При таком подходе данные сначала извлекаются, затем трансформируются и только после этого загружаются в хранилище. Подход характерен для классических DWH, где важно контролировать качество данных до загрузки.
ELT (Extract → Load → Transform)
Данные сначала загружаются в хранилище, а затем обрабатываются внутри него. Подход используется в облачных платформах и хранилищах Data Lake, где есть мощные вычислительные ресурсы.
Выбор подхода и инструментов ETL и ELT зависит от требований проекта, объема данных, сложности трансформаций и доступных ресурсов.
Чем DWH отличается от базы данных
От обычной базы данных корпоративное хранилище отличается следующими критериями:
Типы хранимых данных
Обычные базы хранят данные строго для определенных подсистем, DWH - данные, преобразованные для разных задач бизнеса.
Объемы данных
Стандартная БД содержит ограниченный объем данных, необходимые в данный момент для функционирования системы. КХД сохраняет как текущие, так и исторические данные в агрегированном виде.
Место в рабочих процессах
Информация обычно сразу попадает в рабочие базы данных, а уже оттуда выборочно в DWH. DWH отражает состояние других баз данных и процессов в компании уже после того, как вносятся изменения в рабочих базах.
Чем DWH отличается от Data Lake
Data Lake (озеро данных) — это хранилище, куда в исходном виде поступают разные типы данных: структурированные, полуструктурированные и неструктурированные (например, тексты, изображения, логи, данные датчиков).
В отличие от DWH, данные в Data Lake не приводятся к единой структуре сразу, а сохраняются «как есть», что позволяет использовать их не только для BI-аналитики, но и для задач машинного обучения, AI и работы с Big Data.
Data Warehouse | Data Lake | |
|---|---|---|
Типы данных | Структурированные, подготовленные к аналитике данные | Данные в необработанном, полуструктурированном или неструктурированном виде и в любых форматах |
Актуальность данных | Только необходимые под конкретные бизнес-задачи данные | Все данные компании, часть из которых может не пригодиться никогда |
Цели | Визуализация, отчетность, BI | Предиктивная аналитика, машинное обучение, ИИ, BI, аналитика больших данных |
Обработка | ETL - данные извлекаются из источника, очищаются, структурируются, на финальном этапе готовы к анализу | ELT - данные извлекаются из источника, хранятся в озере данных и затем трансформируются при необходимости |
Как внедряется корпоративное хранилище данных
Типовой проект внедрения DWH проходит следующие этапы:
Предпроектное обследование
Сбор бизнес-требований к DWH и будущей отчетности
Анализ существующих источников данных и текущих отчетов
Выявление проблем аналитики и узких мест в работе с данными
Определение ключевых пользователей и их потребностей
Формирование целей создания аналитической системы
Развертывание и подготовка инфраструктуры
Развертывание СУБД для хранилища данных
Настройка инструментов интеграции и обработки данных (ETL / ELT)
Установка и конфигурация сервера BI-платформы
Проектирование архитектуры
Разработка архитектуры системы и принципов построения
Определение компонентов аналитической платформы
Проектирование семантической модели данных - модели бизнес-данных на логическом и физическом уровнях
Формализация бизнес-сущностей и их взаимосвязей
Описание правил трансформации и хранения данных
Построение DWH и разработка витрин данных для BI
Подключение и интеграция источников данных
Загрузка сырых данных в хранилище
Создание детализированных слоев данных с очисткой и нормализацией
Настройка историчности данных
Формирование витрин данных для аналитики
Проверка корректности загрузки данных и их соответствия бизнес-требованиям
Подключение BI-инструментов и отчетности
Подключение BI к витринам данных
Формирование аналитической модели данных
Настройка обновления данных
Создание ролевой модели доступа к дашбордам
Разработка и публикация отчетов и дашбордов согласно задачам бизнеса
Тестирование и запуск в промышленную эксплуатацию
Проверка стабильности работы хранилища данных
Тестирование сценариев использования BI-отчетов
Устранение выявленных замечаний
Финальная приемка системы клиентом
Для отдельных проектов - разработка плана аварийного восстановления DWH (DRP)
Документация и обучение пользователей
Подготовка документации администраторов DWH и BI-системы
Разработка пользовательских инструкций по работе с отчетами
Проведение обучения ключевых пользователей
Частые ошибки внедрения DWH
Внедрение хранилища данных — сложный проект, и ошибки на старте могут привести к значительным затратам на следующих этапах проекта.
На практике чаще всего встречаются следующие проблемы:
Отсутствие бизнес-целей | Чтобы корпоративное хранилище не превратилось в «свалку данных» (data dump), при его построении важно отталкиваться от задач бизнеса и потребностей в аналитике, а не от объемов данных |
Ошибки в выборе архитектуры | Если архитектура DWH не учитывает задачи и ограничения конкретной компании, дальнейшее масштабирование и поддержка решения усложняется |
Низкое качество данных | Ошибочные, неактуальные, неполные данные, попадающие в хранилище, неизбежно приведут к снижению качества аналитики, а пользователи перестанут доверять BI |
Отсутствие Data Governance | Когда в компании нет правил управления данными, распределения ответственности и контроля качества, DWH становится дополнительной нагрузкой для ИТ-команды |
Нужно ли вам корпоративное хранилище данных?
Необходимость внедрения DWH должна рассматриваться индивидуально для каждой компании и зависит от объема обрабатываемых данных, количества интеграций и источников данных, имеющейся инфраструктуры, требований к производительности и аналитике.
Вам нужен DWH, если
Вы анализируете разноформатные данные из разрозненных источников
Для анализа вам важно сохранить исторические данные в большом объеме
Вы работаете с высоконагруженными системами или критически важными данными, вам важно изолировать аналитику от систем-источников
Не все ваши BI-инструменты стабильно работают с имеющимися источниками
Вы хотите ускорить обработку аналитических запросов
Вам нужны узкоспециализированные дашборды и отчеты для конкретных пользователей или подразделений со строгим разграничением доступа