Для чего используются слои Staging и Data Mart (DM)?

Staging и Data Mart в архитектуре хранилища данных

В архитектуре ETL и Data Warehouse существует многоуровневая структура обработки данных. Staging (промежуточный слой) и Data Mart (витрина данных) решают разные задачи в этой цепи.

Staging Area (промежуточное хранилище)

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

Назначение Staging:

• Приём данных из множества источников (базы данных, API, файлы, потоки)
• Валидация и стандартизация данных перед обработкой
• Деноализация данных перед загрузкой в центральное хранилище
• Буферизация для отделения исходных систем от основного ETL процесса
• Отладка и аудит — сохранение исходных данных для анализа проблем
• Восстановление при сбое обработки

Характеристики Staging:

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

-- Пример Staging таблиц
CREATE TABLE stg_users (
    stg_id INT PRIMARY KEY,
    raw_id VARCHAR(50),
    raw_name VARCHAR(200),
    raw_email VARCHAR(100),
    raw_phone VARCHAR(20),
    loaded_at TIMESTAMP,
    source_system VARCHAR(50)
);

CREATE TABLE stg_orders (
    stg_id INT PRIMARY KEY,
    raw_order_id VARCHAR(50),
    raw_user_id VARCHAR(50),
    raw_amount DECIMAL(10,2),
    raw_status VARCHAR(20),
    loaded_at TIMESTAMP
);

Data Mart (витрина данных)

Data Mart — это специализированное хранилище данных, оптимизированное для конкретного бизнес-процесса или подразделения.

Назначение Data Mart:

• Аналитика для конкретного подразделения (продажи, финансы, маркетинг)
• Оптимизация запросов под конкретные аналитические задачи
• Денормализация данных для ускорения отчётов
• Бизнес-логика в виде вычисляемых метрик и измерений
• Предоставление данных для BI-инструментов
• Масштабируемость — несколько витрин могут работать независимо

Характеристики Data Mart:

• Данные полностью обработаны и очищены
• Применена бизнес-логика
• Часто денормализованы для быстрых запросов
• Построены на основе центрального Data Warehouse
• Могут работать автономно

-- Пример Data Mart для отдела продаж
CREATE TABLE dm_sales_fact (
    sale_id INT PRIMARY KEY,
    customer_id INT,
    product_id INT,
    date_id INT,
    quantity INT,
    amount DECIMAL(12,2),
    profit DECIMAL(12,2),
    region VARCHAR(50),
    quarter VARCHAR(10)
);

-- Пример Data Mart для финансов
CREATE TABLE dm_finance_fact (
    transaction_id INT PRIMARY KEY,
    department_id INT,
    amount DECIMAL(14,2),
    transaction_type VARCHAR(50),
    fiscal_period VARCHAR(10),
    approval_status VARCHAR(20)
);

Архитектурный поток

Источники данных
    ↓
[Staging] ← загрузка, валидация, минимальная обработка
    ↓
[Data Warehouse / Core] ← консолидация, очистка, нормализация
    ↓
[Data Marts] ← витрины для аналитики
    ↓
BI-инструменты (Tableau, Power BI, Looker)

Сравнительная таблица

Практические рекомендации

• Используй Staging как буфер между внешними системами и основным хранилищем
• Staging данные удаляй после успешной обработки (экономия места)
• Создавай несколько Data Marts для разных подразделений
• В Data Mart применяй предварительные агрегации для быстрых отчётов
• Используй SCD (Slowly Changing Dimensions) в витринах для истории изменений
• Мониторь размер Staging — он не должен расти беспредельно