Что такое витрина данных и зачем она бизнесу

Витрина данных, или Data Mart, — это подготовленный набор таблиц для ответа на конкретные бизнес-вопросы: продажи по каналам, маржа, Retention, запасы, дефицит товаров, эффективность рекламы или выполнение KPI. Витрина не хранит “всё обо всём”, а дает пользователям удобный и быстрый слой данных для аналитики, отчетов и BI-дашбордов.

Обычно витрины строятся поверх источников, Data Lake или DWH: сырые данные очищаются, объединяются, обогащаются справочниками и превращаются в понятные бизнес-показатели. В статье разберем, что такое витрина данных, чем она отличается от хранилища данных, как выглядит архитектура, какие требования предъявляют к витринам и почему без них BI-отчеты быстро становятся медленными, спорными и неудобными.

Что внутри:

что такое витрина данных простыми словами;
зачем бизнесу Data Mart;
чем витрина данных отличается от DWH;
как витрины ускоряют отчеты и дашборды;
почему витрины помогают создать “одну правду” по метрикам;
как устроена архитектура: источники, DWH, serving-слой, BI;
где могут жить витрины: ClickHouse, PostgreSQL, облачные DWH;
что такое BI-витрина данных;
какие требования важны: свежесть, качество, документация, доступы;
как витрины данных связаны с безопасностью и Data Quality.

Витрина данных — это специально подготовленная таблица (или набор таблиц) для быстрого и понятного ответа на конкретные бизнес-вопросы: «сколько мы продали по дням и каналам», «как меняется маржа», «какой Retention у пользователей», «какие товары в дефиците». Витрина — это не «всё обо всём», а сфокусированный слой над источниками и хранилищами, где уже собраны нужные признаки, расчёты и справочники.

В идеале у компании есть система витрина данных: это подсистема витрина данных внутри общей платформы, где витрины создаются по единому шаблону, живут по SLO (свежесть/латентность), документированы и доступны инструментам BI. Говоря формально: витрина данных информационной системы — это часть вашей ИТ-архитектуры, которая «поднимает» данные для пользователей (аналитиков, продуктов, руководителей), а не для транзакций.

Зачем это нужно:

Скорость: отчёты и дашборды не «жуют» сырые факты, а читают уже посчитанные поля — всё открывается за секунды.
Одна правда: у метрик есть единые формулы; исчезают споры «у меня другое число».
Предсказуемость: есть правила обновления, требования к витринам данных и мониторинг качества (DQ).
Безопасность: доступ к чувствительным полям регулируется на уровне витрин.

Как выглядит архитектура (высокоуровнево)

В современном контуре «данные → решения» обычно есть четыре слоя:

Источники: ERP/CRM/1С, веб-события, платежи, рекламные платформы.
Хранилище (CORE/Lake/DWH): туда приземляются и очищаются данные. Здесь обычно живут историзированные таблицы, медленнее, но богаче по деталям. Это «dwh витрины данных» — точнее, их фундамент.
Serving/Витрины: быстрый слой для чтения — как раз наша витрина базы данных. Его можно делать на ClickHouse, PostgreSQL (витрины данных PostgreSQL), в облаках и т. п.
BI и продукты: Power BI/Tableau/DataLens/bi витрина данных для внешних партнёров и внутренних приложений.

Когда говорят «хранилища данных витрины данных», имеют в виду связку: «CORE-слой (DWH) держит «правду», а витрины обеспечивают скорость и удобство». В крупной компании часто стремятся к единой витрине данных — не как к одной таблице, а как к единому стандарту и каталогу: витрины разных доменов выглядят одинаково, описаны одинаково, интегрируются одинаково.

Какие бывают витрины (виды и типы)

Скажу просто, без перегруза: витрины данных типы витрин данных можно разложить по четырём осям.

1) По назначению:

Операционные/ежедневные: KPI по дням/часам, остатки, продажи, CR/AOV.
Аналитические: когортный анализ, LTV, атрибуция — это аналитическая витрина данных.
Продуктовые/API: отдача агрегатов наружу (партнёрам/приложениям).

2) По форме:

Широкие таблицы (денормализованные) — всё нужное в одной записи; BI-запросы летят.
«Звезда» (факт + измерения) — гибче для сложных срезов.
Агрегатные — предрасчитанные суммы/квантили/униики по периодам.

3) По обновлению:

Пакетные (дневные/часовые).
NRT/стриминговые (минутная свежесть).

4) По домену:
Retail/FinTech/SaaS/AdTech/Healthcare. Например, аналитическая витрина данных по мониторингу лекарственных препаратов помогает ежедневно отслеживать запасы, поступления, отгрузки, цены и аномалии (подделки/перебои), показывая регулятору и сетям аптек общую картину.

Из чего состоит витрина (объекты и модель)

Любая витрина — это модель витрины данных:

Зерно (grain): минимальная единица — например, «день × магазин × категория».
Факты: показатели (выручка, чеков, пользователей).
Измерения: кто/что/где/когда (магазин, товар, канал, дата).
Правила расчётов: формулы метрик, валюта/календарь.
Требования: свежесть (например, p95 ≤ 5 минут), «без SELECT *», обязательный фильтр по дате.

В документации полезна схема витрины данных: рисуете, как таблицы связаны, какое зерно у факта, какие справочники подключены. Это и есть наглядное описание витрины данных.

Путь от источника к витрине: конвейер

Под капотом почти всегда один и тот же конвейер данных для построения витрин:

Источники → Стейдж → CORE/DWH → Витрина → BI/API

Стейдж — «как пришло», быстро и грязно.
CORE/DWH — чистим, объединяем, историзируем; тут живут «таблицы и витрина данных» будущего.
Витрина — финальная укладка под задачу.

Тут уместны два термина: витрина данных ETL и технология витрина данных. ETL/ELT — это способ загрузки/преобразований; технология — выбранная СУБД, оркестратор, тесты, мониторинг. В реальной жизни это и есть реализация витрины данных.

Как создать витрину данных: пошагово и по-простому

Давайте без страшных слов. Как создать витрину данных так, чтобы она жила долго и радовала BI?

Шаг 1. Сформулировать вопрос и зерно
Что нужно видеть пользователю? Например: «выручка и количество чеков по дням и магазинам». Значит зерно: день × магазин.

Шаг 2. Описать поля
Какие факты (выручка, чеки, средний чек), какие измерения (магазин, регион), какая валюта/календарь. Это и есть формирование витрин данных на бумаге (в Wiki/Notion/YAML).

Шаг 3. Взять источники
Продажи, справочник магазинов, курс валют, календарь (праздники). Тут важна витрина данных интеграция — как «подвезти» в одно место: через CDC/реплики/файлы.

Шаг 4. Спроектировать ключи
Чтобы запросы были быстрыми, нужна хорошая укладка по времени и фильтрам. Это проектирование витрины данных: какой PRIMARY KEY/ORDER BY, как делить по партициям.

Шаг 5. Написать SQL
Собираем расчёт. Это и есть создание витрин данных SQL или проще — «витрины данных SQL». Ниже мини-пример с пояснениями.

Шаг 6. Проверить и автоматизировать
Настроить обновления, мониторинг свежести и «баланс» с источниками, сделать тестирование витрин данных (простые проверки «здравого смысла»), задокументировать.

Шаг 7. Отдать BI
Подключить к дашбордам только через представления (VIEW) — так безопаснее и стабильнее. Это и есть работа с витринами данных в ежедневном режиме.

Примеры SQL (понятные и короткие)

Простой пример: витрина на PostgreSQL

Иногда витрина вполне уместна в Postgres (если объёмы и SLA невысокие). Это и есть витрины данных PostgreSQL.

-- 1) Ежедневная витрина продаж: день × магазин
CREATE MATERIALIZED VIEW dm_sales_daily AS
SELECT
  date_trunc('day', s.sale_dt)::date AS day,
  s.shop_id,
  sum(s.amount)       AS revenue,
  count(*)            AS orders,
  avg(s.amount)       AS aov
FROM sales s
GROUP BY 1,2;
-- 2) Индексы для скорости (витрина базы данных → быстрые фильтры)
CREATE INDEX ON dm_sales_daily(day, shop_id);

Обновление можно повесить на расписание. Для больших объёмов уже берут ClickHouse — там быстрее и дешевле по агрегатам.

Простой пример: витрина на ClickHouse

-- 1) Агрегируем «состояния» (дешёвая запись, быстрое чтение)
CREATE TABLE agg_sales_day_state
(
  day Date,
  shop_id UInt32,
  revenue_state AggregateFunction(sum, Decimal(18,2)),
  orders_state  AggregateFunction(sum, UInt64)
)
ENGINE=AggregatingMergeTree
PARTITION BY toYYYYMM(day)
ORDER BY (day, shop_id);
-- 2) Читаем «как готовую витрину» (…Merge)
CREATE OR REPLACE VIEW vw_sales_daily AS
SELECT
  day, shop_id,
  sumMerge(revenue_state) AS revenue,
  sumMerge(orders_state)  AS orders,
  revenue / nullIf(orders,0) AS aov
FROM agg_sales_day_state
GROUP BY day, shop_id;

Смысл прост: мы храним не «сырые события», а уже агрегаты-состояния, поэтому отчёты работают мгновенно. Это и есть «как построить витрину данных под скорость».

Роли и ответственность

Кто вовлечён в разработку витрин данных:

Аналитик витрин данных — формулирует вопросы, зерно и метрики, делает прототипы в SQL/BI, описывает витрину.
Инженер DWH/разработчик — реализует загрузку, пишет SQL, настраивает ключи/производительность, автоматизирует обновления.
BI-специалист — подключает витрину, собирает дашборды, проверяет UX/фильтры.
Администратор платформы — отвечает за кластера/бэкапы/безопасность.

Требования и чек-лист (перед «боем»)

Коротко про требования к витринам данных и «готовность к релизу»:

Витрина обновляется вовремя (SLA по свежести).
Запросы из BI укладываются в секунды (p95).
Схема стабильна; BI читает только VIEW.
Есть описание витрины данных: что за поля, как считаются, кто владелец.
Есть подготовка витрин данных к аудиту: тесты на «баланс» с источниками и инварианты (например, CR от 0 до 1).
Настроена безопасность (маскирование/доступы).
Под рукой схема витрины данных (картинка), «навигация» по зависимостям и небольшой конвейер данных для построения витрин (скрипты/оркестратор).

Небольшая экскурсия в домены (витрина данных примеры)

E-commerce: «день × магазин × категория», продажи/чеки/конверсия/маржа, воронка (просмотр → корзина → заказ).
FinTech: «день × продукт × счет», обороты/остатки/комиссии, валюты по курсу на дату операции.
SaaS: «день × тариф», активные пользователи, NRR/GRR, Retention, эксперименты.
Здравоохранение — аналитическая витрина данных по мониторингу лекарственных препаратов:

зерно: «день × регион × препарат»;
факты: остатки, поступления, продажи, возвраты, цена;
измерения: аптечная сеть, склад, МНН/АТХ-классификация;
сигналы: аномальные просадки остатков, всплески спроса, «белые пятна» по регионам;
потребители: регулятор, дистрибьюторы, сети аптек, фарм-аналитика.
Такая витрина помогает принимать решения по запасам и ценообразованию, вовремя видеть дефицит и предотвращать перебои.

Частые вопросы «простыми словами»

«Можно ли скачать витрина данных?»
Обычно витрина — это не файл, а таблица в базе. Но всегда можно сделать экспорт (CSV/Parquet) под конкретный отчёт.

«Витрины данных содержат что именно?»
Только то, что нужно для ответа на вопрос: агрегаты, необходимые поля-измерения, готовые метрики, статусы и минимальные идентификаторы. Всё лишнее — в CORE.

«Одна или много? Что такое единая витрина данных?»
Единая — это про стандарты и каталог, а не про «одну таблицу на все случаи». Лучше несколько витрин по доменам, но одинаково спроектированных.

«Где хранить: ClickHouse или PostgreSQL?»
Если нагрузки высокие и нужен NRT — берите CH. Для небольших отчётов хватит Postgres. Главное — одинаковый процесс построения витрин данных и тестирования витрин данных.

Мини-гайд по проектированию (с нуля)

Сформулируйте цель: кому и для чего нужна витрина.
Определите зерно и список полей.
Соберите источники и опишите витрина данных интеграция.
Нарисуйте схему витрины данных и выберите ключи (по времени, по объекту).
Напишите SQL-черновик (создание витрин данных SQL).
Проверьте числа с источником (баланс), договоритесь о свойствах метрик (валюта/календарь).
Оформите документ описание витрины данных: владелец, формулы, SLA, поля.
Настройте обновления (ETL/оркестратор), мониторинг свежести, DQ.
Подключите BI только через VIEW (bi витрина данных), запретите SELECT *.
Зафиксируйте «как поддерживаем»: кто on-call, как делаем правки, как ретро-пересчёты.

Советы по эксплуатации (день за днём)

Держите витрины узкими по цели, но широкими по колонкам (чтобы BI не делал лишних JOIN).
Сложные метрики считайте заранее и храните «состояниями» (это сильно ускоряет).
Разведите «операция vs отчёт»: деньги либо по курсу на дату операции, либо на дату отчёта — сделайте две отдельных аналитические витрины данных.
Не стесняйтесь иметь v2-версию витрины: если ключи и фильтры поменялись, проще выпустить новую.
Следите за «дорогими запросами» в BI и ставьте guardrails (лимиты, обязательный фильтр по дате).
Роли и доступы — только через VIEW, не отдавайте сырые таблицы в BI.

Коротко про технологии

PostgreSQL: удобно, знакомо, годится для малых/средних задач, хорош для прототипов.
ClickHouse: быстрый слоящийся движок для аналитики и предагрегатов; отлично подходит для NRT, минутных KPI и больших витрин.
ETL/оркестрация: Airflow/Prefect, нативные инструменты в облаках; главное — прозрачно видеть пайплайн.
BI: Power BI, Tableau, DataLens, Superset — любой инструмент дружит с SQL, если витрина сделана правильно.

Что положить в «стартовый пакет» команды

Шаблон витрины (YAML/таблица полей), пример проекта «витрина данных как сделать».
Набор SQL-болванок (для ClickHouse и PostgreSQL) — «создание витрин данных SQL» под ваши домены.
Чек-лист: требования, тесты DQ, права доступа, SLO по свежести/латентности.
Примеры «витрина данных примеры» по вашим процессам (продажи, маркетинг, финансы).
Гайд «тестирование витрин данных» (баланс, дубликаты, инварианты).
Набор дашбордов «качества и свежести» — чтобы помнить, что витрина — это сервис.

Резюме

Витрина данных — это «витрина магазина» для ваших чисел: чисто, быстро, понятно, безопасно.
Правильная архитектура витрины данных — «Источники → DWH → Витрины → BI/API», а не «все таблицы в один отчёт».
Построение витрин данных — это процесс: требования → модель → SQL → проверки → публикация → наблюдение.
Хорошая витрина живёт дольше любого отчёта, потому что в неё вложены процесс и ответственность, а не только «код и таблицы».

Arenadata QuickMarts (ADQM) — корпоративная платформа на базе ClickHouse для быстрого слоя витрин и near-real-time аналитики. Решает задачи «быстрых» дашбордов и API с низкой латентностью и высокой конкуррентностью, работает поверх вашего DWH/лейкхауса как serving-уровень. Даёт предсказуемую производительность на терабайтно-петабайтных объёмах за счёт колоночного хранения, компрессии и предагрегатов (Materialized Views, AggregatingMergeTree), подключается к Kafka/S3 и стандартным BI-инструментам по SQL/HTTP. Для корпоративных ИТ ADQM предлагает поддержку и SLA, отказоустойчивые кластеры (HA/DR), безопасность (RBAC, LDAP/OIDC, шифрование трафика и данных), мониторинг и резервное копирование. Платформа хорошо ложится на методологию курса: семантика vw_*, роллап-слои, NRT-ингест, SLO/наблюдаемость и «гвардейки» для BI/API. Итог — быстрый запуск витрин за недели, снижённые риски в проде и предсказуемая стоимость владения.

FAQ

Вопрос: Что такое витрина данных?

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

Вопрос: Чем витрина данных отличается от DWH?

Ответ: DWH хранит более широкий и детальный слой корпоративных данных, часто с историей и данными из разных систем. Витрина данных обычно строится поверх DWH и оптимизирована под конкретные отчеты, метрики или пользователей.

Вопрос: Зачем бизнесу витрина данных?

Ответ: Витрина ускоряет отчеты, снижает нагрузку на источники, стандартизирует метрики, упрощает доступ к данным и помогает пользователям получать ответы без ручной сборки сложных SQL-запросов.

Вопрос: Что такое Data Mart?

Ответ: Data Mart — английский термин для витрины данных. Обычно это тематический или доменный слой данных: например, витрина продаж, маркетинга, финансов, клиентов или складских запасов.

Вопрос: Какие требования важны для витрины данных?

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

← Предыдущая статья

Глоссарий курса «Витрины данных на ClickHouse»