Проект по построению DWH с нуля был запущен по инициативе Заказчика в рамках крупной трансформации управленческой отчётности и аналитики. Подход к реализации выбрали классический: многоуровневая архитектура хранилища данных, обеспечивающая масштабируемость и прозрачность ETL-процессов.
Архитектура хранилища данных
Целевое аналитическое хранилище было реализовано с использованием четырёх ключевых слоёв: Staging Layer (STG), Data Warehouse (DWH), Detail Data Store (DDS) и Data Marts (витрины данных). Каждый из этих слоев выполняет свою роль в обработке, трансформации и подаче данных.
Staging Layer (STG)
STG — это слой предварительной загрузки, на который поступают данные из первичных источников в максимально приближенном к исходному виде. На данном этапе не происходит преобразования данных: они хранятся в «сыром» формате. Основной задачей этого слоя является обеспечение быстрой и надежной загрузки, сохранение целостности и временное хранение данных до их дальнейшей обработки.
STG особенно важен при работе с системами, которые предоставляют данные с различными задержками или нестабильной структурой. В случае необходимости можно повторно обработать данные без запроса к источнику.
Data Warehouse (DWH)
Следующим этапом является DWH — операционное хранилище данных. На этом слое данные из различных источников проходят первичную обработку: дубликаты устраняются, данные очищаются, выравниваются по структуре и бизнес-правилам. Результатом становится унифицированное, интегрированное представление данных (hash/хеш), пригодное для поддержки оперативной отчетности и процессов.
DWH служит своего рода «буфером» между сырыми данными и аналитической моделью, позволяя получать уточненные и согласованные данные без существенной задержки и использовать их для поддержки операционных решений.
В DWH закладываются принципы историзации данных, что позволяет регистрировать изменения данных с течением времени — это особенно актуально для анализа трендов, отклонений и оценки эффективности процессов во времени. Слой DWH хранит в себе всю историческую информацию не только по фактам (числовым показателям), но и по измерениям (таблицам, которые описывают контекст фактов). Чтобы обеспечить надёжное хранение этой информации, при проектировании структуры была использована вторая нормальная форма (2NF), которая помогает устранить избыточность данных и предотвращает ошибки при их обновлении, добавлении или удалении – это особенно критично при работе с историческими данными.
Detail Data Store (DDS)
DDS — это аналитическое хранилище в полном смысле этого слова. На этом уровне происходит агрегация данных, построение специальных схем и консолидация данных, которые теперь хранятся в структурированном виде, готовом для выполнения сложных запросов и аналитических сценариев.
Кроме того, в DDS реализуются механизмы построения тематических моделей, ориентированных на предметные области: добыча, транспортировка, логистика, финансы и др.
На этом этапе все таблицы фактов и измерений приводятся к единому формату: назначаются общие BI-ключи, данные очищаются и стандартизируются. Затем происходит объединение информации из разных источников в единую таблицу.
Data Marts (витрины данных)
Последний уровень архитектуры — Data Marts, или витрины данных. Это подмножества информации, ориентированные на конкретных пользователей или бизнес-функции. Витрины могут быть агрегированными представлениями данных из DDS или специально подготовленными наборами данных, обеспечивающими быстрый отклик и удобство анализа.
Витрины предоставляются через BI-систему и служат основой для создания аналитических панелей, дашбордов и отчетов. Они позволяют пользователям из разных подразделений — от производственных служб до топ-менеджмента — получать необходимую информацию без глубоких знаний в области данных и ИТ. Витрины данных могут быть построены как снимки хранилища данных или как отдельные, независимые структуры. В данном случае важно было сделать единую витрину для основного и дополнительного вида деятельности Заказчика. Данные можно просматривать как вместе, так и использовать фильтры для их распределения.
Особенности реализации
Во время реализации проекта Заказчик переходил с одной версии 1С на другую и параллельно рассматривал внедрение ещё одной (третьей) системы. Требовалась интеграции данных из разнородных источников, где одни и те же сущности могли называться по-разному или иметь разные идентификаторы.
Чтобы обеспечить единообразие этих данных, в рамках проекта была реализована система Master Data Management (MDM) — управления эталонными данными.
С помощью MDM внутри базы данных была создана специальная система мэппинга данных (data mapping) — процесса, позволяющего сопоставлять элементы из разных источников с целевой моделью данных, используемой в BI-системе. Это позволило устранить дублирование, повысить точность отчётов и обеспечить консистентность информации при анализе.
Так, на слое DWH мы загрузили измерения из двух систем и отдельно создали таблицу с мэппингом данных, где есть все уникальные ключи из разных систем, а на слое DDS и витрине использовали только один общий BI-ключ. Таким образом, в данных не было путаницы и не приходилось проделывать лишнюю работу по сверке одной и той же информации несколько раз.
Целевой сценарий использования при добавлении нового источника данных выглядит следующим образом:
Загружаем сырые данные на слой STG;
На слое DWH выполняем мэппинг объектов;
Последующие слои не потребуют дополнительной разработки.
Приведём пример:
Допустим, в компании появилась новая CRM-система, в которой торговые представители фиксируют данные о ценах на полке. Чтобы включить эту информацию в аналитическую базу и корректно сопоставить с фактическими продажами из 1С, необходимо объединить данные из двух источников. Однако в разных системах одни и те же товары могут иметь разные названия и идентификаторы.
Для решения этой задачи мы сначала загружаем измерения товаров из новой CRM на слой STG, далее на слое DWH проводим мэппинг между товарными позициями двух систем. После этого мы сможем проводить анализ добавленного показателя (например, «Цена на полке») с уже имеющимися (например «Продажи 1С»), при этом структура измерения не меняется — используется BI-ключ.
Слой DWH позволяет сохранять всю историю изменений (историчность) в измерениях. Это особенно важно, если для анализа требуется учитывать изменения атрибутов — например, изменение сегмента торговой точки. Такая архитектура упрощает анализ причин изменения ключевых показателей.
Кроме того, на слое DWH для каждого изменения объекта сохраняется история с датой начала и окончания действия версии. Это позволяет формировать как:
Актуальные витрины с последними данными (если, например, нас не интересует, как менялось название товара),
Так и исторические витрины, если требуется ретроспективный анализ.
Пример использования исторических измерений:
При анализе среднего объёма продаж по сегментам торговой точки важно использовать данные, актуальные на момент совершения продаж. Если бы мы использовали только текущие данные измерений (без истории), это бы исказило фактическую картину: показатели по сегментам были бы рассчитаны неправильно. Благодаря историческим справочникам на слое DWH мы сохраняем корректность аналитики.
Инкрементальная загрузка большого объёма данных
Перед разработчиком стояла задача настроить инкрементальную загрузку данных больших объёмов с помощью уникального представления данных (хеш), которое мы используем в архитектуре DWH.
Как это работает:
Определяем критерии, по которым будем формировать состав хеша. Например, для транзакций — это будет ID товара, дата и время, номер чека и ID торговой точки.
Получаем хеш-ключи для каждой записи.
Проводим сверку на слое DWH.
Определяем последние загруженные данные на слое STG по хешу и периоду.
Сравниваем данные со слоя STG и DWH за одинаковый период.
Если есть новая запись для хеша — заменяем ее на слое DWH.
Если появился полностью новый хеш — добавляем новую запись на слой DWH.
Плюсы такого подхода: мы не сравниваем весь массив данных, что помогает значительно сократить время обработки данных.
Итоги
BI-система, интегрированная с DWH, ежедневно подгружает актуальные данные по ключевым метрикам компании, формируя ту самую "единую точку правды", на которую могут опираться все участники процесса — от операционки до топ-менеджмента.
Чтобы всё работало стабильно и масштабируемо, при проектировании архитектуры DWH мы сразу заложили несколько ключевых требований:
Интеграция данных из разнородных источников, включая корпоративные ERP-системы, базы данных и Excel-отчеты.
Постоянное хранение данных с возможностью детализации до первичных событий или агрегации по нужным бизнес-группировкам.
Приведение данных к единому справочному пространству и базовым предметным объектам.
Поддержка временного хранения промежуточных этапов преобразований, позволяющая сохранять цепочку трансформации при каждой загрузке.
Настройка ежедневной актуализации данных с автоматическим контролем качества и логированием.
Помимо самого DWH, была выстроена промежуточная инфраструктура, включающая:
интеграцию BI-системы в инфраструктуру Заказчика;
разработку и настройку аналитических моделей и панелей;
доработку смежных информационных систем, необходимых для полноценной работы аналитики.
