Собрали для вас подробный материал про DWH — корпоративное хранилище данных:

1. Что такое DWH и как работает Data Warehouse

2. Какие задачи решает корпоративное хранилище данных и как применяется в бизнесе

3. Архитектура, подходы к проектированию и компоненты стека DWH

4. Чем DWH отличается от базы данных и Data Lake

5. Как внедряется корпоративное хранилище данных

6. Какие ошибки при внедрении DWH бывает

7. Нужно ли вам корпоративное хранилище данных

Этот разбор 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-проектах

Какие задачи решает корпоративное хранилище данных

• Централизация и обеспечение доступа к данным

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

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

Для практической реализации ее детализируют — чаще всего через слоеную архитектуру LSA.

Layered Scalable Architecture (LSA) - принцип слоеного пирога

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.

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

Типовой проект внедрения DWH проходит следующие этапы:

Предпроектное обследование

• Сбор бизнес-требований к DWH и будущей отчетности

• Анализ существующих источников данных и текущих отчетов

• Выявление проблем аналитики и узких мест в работе с данными

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

• Формирование целей создания аналитической системы

Развертывание и подготовка инфраструктуры

• Развертывание СУБД для хранилища данных

• Настройка инструментов интеграции и обработки данных (ETL / ELT)

• Установка и конфигурация сервера BI-платформы

Проектирование архитектуры

• Разработка архитектуры системы и принципов построения

• Определение компонентов аналитической платформы

• Проектирование семантической модели данных - модели бизнес-данных на логическом и физическом уровнях

• Формализация бизнес-сущностей и их взаимосвязей

• Описание правил трансформации и хранения данных

Построение DWH и разработка витрин данных для BI

• Подключение и интеграция источников данных

• Загрузка сырых данных в хранилище

• Создание детализированных слоев данных с очисткой и нормализацией

• Настройка историчности данных

• Формирование витрин данных для аналитики

• Проверка корректности загрузки данных и их соответствия бизнес-требованиям

Подключение BI-инструментов и отчетности

• Подключение BI к витринам данных

• Формирование аналитической модели данных

• Настройка обновления данных

• Создание ролевой модели доступа к дашбордам

• Разработка и публикация отчетов и дашбордов согласно задачам бизнеса

Тестирование и запуск в промышленную эксплуатацию

• Проверка стабильности работы хранилища данных

• Тестирование сценариев использования BI-отчетов

• Устранение выявленных замечаний

• Финальная приемка системы клиентом

• Для отдельных проектов - разработка плана аварийного восстановления DWH (DRP)

Документация и обучение пользователей

• Подготовка документации администраторов DWH и BI-системы

• Разработка пользовательских инструкций по работе с отчетами

• Проведение обучения ключевых пользователей

Частые ошибки внедрения DWH

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

На практике чаще всего встречаются следующие проблемы:

Нужно ли вам корпоративное хранилище данных?

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

Вам нужен DWH, если

• Вы анализируете разноформатные данные из разрозненных источников

• Для анализа вам важно сохранить исторические данные в большом объеме

• Вы работаете с высоконагруженными системами или критически важными данными, вам важно изолировать аналитику от систем-источников

• Не все ваши BI-инструменты стабильно работают с имеющимися источниками

• Вы хотите ускорить обработку аналитических запросов

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