Организация Хранилища Данных

В значительной мере работа над Хранилищем Данных заключается в Моделировании данных (Data Modeling), или построении логической модели. Формально это означает преобразование, обогащение, сведение разрозненных наборов данных с целью получить интересующий набор показателей (метрик) с соблюдением бизнес-правил и логики расчетов.

Концептуально DWH можно разделить на ряд областей:

• (1) Источники данных - исходные наборы из рекламных кабинетов, счетчиков посещаемости, CRM
• (2) Детальные данные - очищенные и унифицированные таблицы атомарной детализации (например, клик); имеют общую структуру для каждого Клиента
• (3) Витрины данных - ключевые бизнес-метрики, которые мы отслеживаем; индивидуальная структура для каждого Клиента

Для формирования логической модели я воспользовался dbt. В моем случае Хранилище Данных представляет из себя git-репозиторий, состоящий из набора файлов .sql (код витрин) и .yaml (конфигурация). На Хабре есть хороший обзор dbt на русском языке: Data Build Tool или что общего между Хранилищем Данных и Смузи.

В роли движка-СУБД может выступать любая из популярных сегодня аналитических баз данных: BigQuery, Redshift, Snowflake, Postgres, Spark, Presto. В моем случае это Azure SQL Database (managed SQL Server). По сути для меня не имеет значения, на какой инфраструктуре строить Хранилище; важна смысловая составляющая проекта, бизнес-логика, алгоритмы (читай код).

Для последовательности и структурированности я делю DWH на ряд слоев:

1. Источники (Sources)

По сути это ссылки-указатели на таблицы, которые регулярно обновляются сервисом myBI Connect. Для моего решения это исходные данные.

2. Стейдж (Staging)

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

• Выполняю очистку полей, парсинг UTM-меток и значений
• Привожу типы данных и форматы: текст в числа, таймстемпы и т.д.
• Унифицирую наименования полей (при необходимости)

3. Вспомогательный (Auxiliary)

Модели слоя Aux предназначены для формирования срезов по отдельным предметным областям. Здесь появляются первые денормализованные (широкие) аналитические таблицы:

• Объединение фактов и измерений - клики, конверсии, продажи обретают контекст (алгоритмически это джоин таблиц)
• Формирование суррогатных ключей для соединения таблиц
• Применение коэффициентов: НДС, комиссии агентства и т.д.

4. Витрины (Marts)

Витрины данных - это то, на что смотрит конечный пользователь. Это семантический слой доступа, прослойка между бизнес-атрибутами и алгоритмами их формирования. Здесь я расположил максимально прилизанные и корректные данные. Именно здесь фокусируется внимание и интерес пользователей:

• Агрегация и объединение данных, например, суточные показатели из всех рекламных кабинетов
• Расчет бизнес-метрик: абсолютные и относительные показатели, их динамика
• Формирование Сквозной Аналитики: как раз тот самый кейс для full join, когда ни одна из составляющих уравнения не должна быть потеряна