12 KiB
Отлично! Я умею рисовать Mermaid-схемы и с удовольствием добавлю их в план. Вот переработанный вариант с дополнительными визуализациями для ключевых концепций.
**Структура статьи про хранилище данных **
1. Введение. Проблема аналитики в OLTP
2. Учебный пример. Интернет-магазин
3. Архитектура. Зачем слои?
4. Путешествие данных. STG→ODS→DDS→DM
5. Базовые понятия. Факты, Измерения, SCD
6. Модели данных. 3NF, DV, Звезда
7. Практикум. Собираем витрину
8. Выбор моделию Дерево решений
9. Эксплуатация. Качество и эволюция
10. Заключение
1. Введение: Аналитика — это не оперативный учет
OLTP - Оперативный учет
- CRM
- Заказы
- Склад
DWH - Аналитическое хранилище -> Единая модель
для анализа
OLTP - Сложные JOIN -> Медленные отчеты -> Проблемы
Ообенности DWH
- Слоистая архитектура
- Оптимизированные модели
Ключевые тезисы:
- OLTP vs OLAP: транзакции против анализа
- Почему "одна большая таблица" не работает на истории
- 3 преимущества слоев: управляемость, производительность, прозрачность
2. Учебный пример: интернет-магазин
(Оставляю вашу отличную ER-диаграмму без изменений)
erDiagram
CUSTOMER ||--o{ ORDER : places
ORDER ||--|{ ORDER_ITEM : contains
PRODUCT ||--o{ ORDER_ITEM : referenced
PRODUCT ||--o{ PRICE : has
PROMO ||--o{ ORDER_ITEM : applied
CUSTOMER {
int customer_id PK
string email
string phone
}
PRODUCT {
int product_id PK
string name
}
ORDER {
int order_id PK
date order_date
int customer_id FK
}
ORDER_ITEM {
int order_item_id PK
int order_id FK
int product_id FK
int qty
numeric price_at_sale
}
PRICE {
int product_id FK
date valid_from
date valid_to
numeric price
}
PROMO {
int promo_id PK
string code
}
Описание примера текстом
3. Архитектура хранилища: зачем делить на слои?
flowchart TD
subgraph Sources[Источники OLTP]
A[CRM]
B[Заказы]
C[Склад]
end
A --> STG
B --> STG
C --> STG
subgraph STG[STG - Сырые данные]
D[Таблицы-клоны<br>сырые данные]
end
STG --> ODS
subgraph ODS[ODS - Очищенные данные]
E[Стандартизированные<br>типы и форматы]
end
ODS --> DDS
subgraph DDS[DDS - Интегрированная модель]
F[Бизнес-сущности<br>SCD, интеграция]
end
DDS --> DM
subgraph DM[DM - Витрины для аналитики]
G[Звезда/снежинка<br>агрегаты]
end
DM --> BI[BI-системы<br>и отчеты]
4. Путешествие данных по слоям
flowchart LR
subgraph STG[STG - Сырье]
A[raw_orders.json]
B[raw_customers.csv]
C[Формат как в источнике]
end
subgraph ODS[ODS - Очистка]
D[stg_orders]
E[stg_customers]
F[Типизация, валидация]
end
subgraph DDS[DDS - Интеграция]
G[dim_customer<br>SCD Type 2]
H[fact_orders<br>с суррогатными ключами]
end
subgraph DM[DM - Готовые решения]
I[mart_sales<br>агрегированные данные]
J[mart_customer_360<br>обзор по клиентам]
end
STG --> ODS
ODS --> DDS
DDS --> DM
4.1 STG (Staging/Bronze)
Коротко: «как пришло». Идемпотентность, дедупликация, неизменяемость/переигрузка.
4.2 ODS (Operational Data Store/Silver)
Коротко: чистка и выравнивание типов, базовая унификация кодов, ещё без тяжёлой бизнес-логики. Несколько примеров из учебного примера
4.3 DDS (Integrated/Conformed Layer)
Коротко: интеграция источников, общие справочники, SK/BK, SCD. Здесь уже начинаются модели данных. Какие модели испольуют.
4.4 DM (Data Marts/Gold)
Коротко: модели под задачи BI (звезда/снежинка). Агрегаты, материализации.
5. Базовые понятия: Факты, Измерения, Ключи
erDiagram
dim_date ||--o{ fact_sales : "дата"
dim_customer ||--o{ fact_sales : "клиент"
dim_product ||--o{ fact_sales : "товар"
dim_customer {
bigint customer_sk PK
varchar customer_bk
varchar customer_name
varchar email
date valid_from
date valid_to
boolean is_current
}
fact_sales {
bigint sale_id PK
bigint customer_sk FK
bigint product_sk FK
date date_sk FK
int quantity
decimal amount
}
Что из базвой модели данных
SCD Type 2 - Визуализация истории:
gantt
title SCD Type 2: История изменений клиента (ID = 123)
dateFormat YYYY-MM-DD
axisFormat %Y-%m
section Москва, premium@email.com
Версия 1 :active, 2023-01-01, 2023-05-15
section Москва, new_premium@email.com
Версия 2 :active, 2023-05-16, 2023-09-30
section Санкт-Петербург, new_premium@email.com
Версия 3 :active, 2023-10-01, 2024-12-31
Краткое описание текстом. Указание, что подробно про scd можно почитать в соседней статье SCD.md
6. Модели данных для DDS
Варианты, как можно было бы разложить в dds учебный пример - придумать.
3NF
Снежинка
Data Vault 2.0:
erDiagram
hub_customer ||--o{ sat_customer_info : "хаб"
hub_order ||--o{ sat_order_details : "хаб"
hub_product ||--o{ sat_product_info : "хаб"
hub_customer ||--o{ link_order_customer : "участвует"
hub_order ||--o{ link_order_customer : "включает"
hub_order ||--o{ link_order_product : "содержит"
hub_product ||--o{ link_order_product : "входит в"
hub_customer {
string customer_hash_key PK
string customer_id BK
datetime load_dttm
}
sat_customer_info {
string customer_hash_key PK,FK
datetime load_dttm PK
string customer_name
string email
string phone
}
link_order_customer {
string order_customer_hash_key PK
string order_hash_key FK
string customer_hash_key FK
datetime load_dttm
}
Описание текстом про хабы, сателлиты, связи. Показать, как учебную БД можно разложить по схеме Data Vault. Сказить, что здесь DV рассмотрен обзорно
Упомянуть про DV 1
Anchor Modeling
Кратко
Сравнение моделей:
quadrantChart
title Сравнение моделей данных по сложности и гибкости
x-axis "Низкая сложность" --> "Высокая сложность"
y-axis "Низкая гибкость" --> "Высокая гибкость"
"Звезда": [0.2, 0.3]
"3NF": [0.6, 0.5]
"Data Vault": [0.8, 0.8]
"Anchor": [0.9, 0.9]
Рассказать, что выбор модели для данных далеко не всегда однозначен, и является компромисснным.
3NF - преимущества и недостатки Снежинка - преимущества и недостатки DV Anchor Modeling
7. Практикум: собираем витрину
Раздел мне не нравится, надо бы переработать.
flowchart TD
A[Источники] --> STG
STG[STG: сырые заказы, товары] --> ODS
ODS[ODS: очищенные данные] --> DDS
subgraph DDS[DDS: интегрированная модель]
B[dim_customer<br>SCD Type 2]
C[dim_product]
D[dim_date]
E[fact_sales]
end
DDS --> F{Сборка витрины}
F --> G[mart_daily_sales]
F --> H[mart_customer_lifetime]
G --> I[Дашборд продаж]
H --> J[Отчет по клиентам]
Пример SQL для витрины:
-- Витрина ежедневных продаж
CREATE TABLE mart_daily_sales AS
SELECT
d.date,
p.product_name,
c.customer_segment,
SUM(f.quantity) as total_quantity,
SUM(f.amount) as total_amount
FROM fact_sales f
JOIN dim_date d ON f.date_key = d.date_key
JOIN dim_product p ON f.product_key = p.product_key
JOIN dim_customer c ON f.customer_key = c.customer_key
WHERE c.is_current = true
GROUP BY d.date, p.product_name, c.customer_segment;
9. Эксплуатация: качество и эволюция
graph TB
A[Данные] --> B{Контроль качества}
B --> C[Проверка уникальности]
B --> D[Проверка полноты]
B --> E[Валидация форматов]
B --> F[Свежесть данных]
C --> G[✅ Успех]
D --> G
E --> G
F --> G
C --> H[❌ Ошибка]
D --> H
E --> H
F --> H
G --> I[Загрузка в слой]
H --> J[Оповещение<br>и остановка]
10. Заключение: главное — понимать "почему"
mindmap
root((Хранилище данных))
Архитектура
Слои STG→ODS→DDS→DM
Разделение ответственности
Управляемость изменений
Модели данных
3NF: Целостность
Data Vault: Масштабируемость
Звезда: Производительность
Ключевые понятия
Факты и измерения
Суррогатные ключи
SCD Type 2
Практика
Понимать бизнес-задачу
Выбирать подходящую модель
Строить итеративно
Такой визуализированный план поможет студентам:
- Быстрее понять сложные концепции через схемы
- Увидеть связи между разделами через общую навигацию
- Запомнить ключевые отличия моделей через сравнительные диаграммы
- Поножить практическое применение через конкретные примеры
Все схемы готовы к использованию в статье и будут отлично работать в Markdown-редакторах с поддержкой Mermaid.