diff --git a/dwh-modeling-ds.md b/dwh-modeling-ds.md index 7d099e5..b910b01 100644 --- a/dwh-modeling-ds.md +++ b/dwh-modeling-ds.md @@ -1,48 +1,47 @@ -Отлично! Я умею рисовать Mermaid-схемы и с удовольствием добавлю их в план. Вот переработанный вариант с дополнительными визуализациями для ключевых концепций. +Что нас здесь ждет ---- +* **Уже умеете:** SQL-основы (SELECT/JOIN/GROUP BY), простые агрегаты. +* **Узнаете:** слои (STG/ODS/DDS/DM), модели (3NF/Star/DV/Anchor), SCD и суррогатные ключи. +* **Не рассматриваем здесь:** физический дизайн, производительность, партиционирование, распределённые кластеры — это отдельная тема. # **Структура статьи про хранилище данных ** - 1. Введение. Проблема аналитики в OLTP - 2. Учебный пример. Интернет-магазин - 3. Архитектура. Зачем слои? - 4. Путешествие данных. STG→ODS→DDS→DM - 5. Базовые понятия. Факты, Измерения, SCD - 6. Модели данных. 3NF, DV, Звезда - 7. Практикум. Собираем витрину - 8. Выбор моделию Дерево решений - 9. Эксплуатация. Качество и эволюция - 10. Заключение +1. Введение. Проблема аналитики в OLTP +2. Учебный пример. Интернет-магазин +3. Архитектура. Зачем слои? +4. Путешествие данных. STG→ODS→DDS→DM +5. Базовые понятия. Факты, Измерения, SCD +6. Модели данных. 3NF, DV, Звезда +7. Практикум. Собираем витрину +8. Выбор моделию Дерево решений +9. Эксплуатация. Качество и эволюция +10. Заключение --- # **1. Введение: Аналитика — это не оперативный учет** -OLTP - Оперативный учет -- CRM -- Заказы -- Склад - -DWH - Аналитическое хранилище -> Единая модель
для анализа +**OLTP (оперативный учёт)**: CRM, заказы, склад. +**DWH (аналитическое хранилище)**: единая модель для анализа. - -OLTP - Сложные JOIN -> Медленные отчеты -> Проблемы +Проблема: в OLTP для исторической аналитики — сложные JOIN, тяжёлые агрегации, нестабильная производительность. -Ообенности DWH -- Слоистая архитектура -- Оптимизированные модели +**Особенности DWH**: + +* Слоистая архитектура +* Оптимизированные под аналитику модели **Ключевые тезисы**: -- OLTP vs OLAP: транзакции против анализа -- Почему "одна большая таблица" не работает на истории -- 3 преимущества слоев: управляемость, производительность, прозрачность + +* OLTP vs OLAP: транзакции против анализа +* Почему «одна большая таблица» не работает на истории +* 3 преимущества слоёв: управляемость, производительность, прозрачность --- # **2. Учебный пример: интернет-магазин** -*(Оставляю вашу отличную ER-диаграмму без изменений)* +ER-диаграмма сущностей источника (упрощённо): ```mermaid erDiagram @@ -160,22 +159,33 @@ flowchart LR DDS --> DM ``` -### 4.1 STG (Staging/Bronze) +STG (Staging/Bronze) -**Коротко**: «как пришло». Идемпотентность, дедупликация, неизменяемость/переигрузка. +Коротко: «как пришло». Идемпотентность, дедупликация, неизменяемость/переигрузка. -### 4.2 ODS (Operational Data Store/Silver) +ODS (Operational Data Store/Silver) -**Коротко**: чистка и выравнивание типов, базовая унификация кодов, ещё без тяжёлой бизнес-логики. -Несколько примеров из учебного примера +Коротко: чистка и выравнивание типов, базовая унификация кодов, ещё без тяжёлой бизнес-логики. -### 4.3 DDS (Integrated/Conformed Layer) +DDS (Integrated/Conformed) -**Коротко**: интеграция источников, общие справочники, SK/BK, SCD. Здесь уже начинаются модели данных. Какие модели испольуют. +Коротко: интеграция источников, общие справочники, SK/BK, SCD. Здесь живут модели данных (3NF/DV/Anchor/Star). -### 4.4 DM (Data Marts/Gold) +DM (Data Marts/Gold) -**Коротко**: модели под задачи BI (звезда/снежинка). Агрегаты, материализации. +Коротко: модели под задачи BI (звезда/снежинка). Агрегаты, материализации. + +* **STG (Bronze):** как пришло; неизменяемо/переигрузка; идемпотентность; дедуп по `(BK, load_ts)`; только тех. обогащения (например, `_ingest_id`). +* **ODS (Silver):** типизация; базовая очистка и стандартные коды; **без** тяжёлой бизнес-логики; стабильные схемы/имена. +* **DDS (Conformed/Core):** интеграция источников; единая терминология; SK/BK; SCD; здесь живут модели (3NF/Star/DV/Anchor). +* **DM (Gold):** под конкретные вопросы BI/продукта; агрегаты/материализации; доступные метрики и измерения. + +Нейминг-гайд (пример) + +* `stg.*` — как в источнике, добавочные тех. поля: `_ingest_id`, `_load_ts`. +* `ods.*` — очищенные «плоские» таблицы, стаб. схемы. +* `dds.dim_*`, `dds.fact_*` — интегрированная модель. +* `dm.mart_*` — витрины/представления. --- @@ -226,17 +236,25 @@ gantt section Санкт-Петербург, new_premium@email.com Версия 3 :active, 2023-10-01, 2024-12-31 ``` +в fact берём версию dim_customer по дате факта (между valid_from и valid_to) + Краткое описание текстом. Указание, что подробно про scd можно почитать в соседней статье SCD.md --- ## **6. Модели данных для DDS** -Варианты, как можно было бы разложить в dds учебный пример - придумать. +### 3NF (третья нормальная форма) -### 3NF +Классическая нормализованная модель, сильная целостность и интеграция, но SQL для аналитики сложнее. -### Снежинка +### Снежинка (Snowflake) + +Нормализованные измерения поверх звезды — компромисс между читаемостью и дублированием. + +### Звезда (Star Schema) + +Факт + денормализованные измерения — просто и быстро для BI/SQL. ### **Data Vault 2.0**: @@ -274,15 +292,15 @@ erDiagram } ``` -Описание текстом про хабы, сателлиты, связи. -Показать, как учебную БД можно разложить по схеме Data Vault. -Сказить, что здесь DV рассмотрен обзорно +Коротко: хабы (BK), линки (связи), сателлиты (история атрибутов). Этот раздел обзорный. Упомянуть про DV 1 -## Anchor Modeling +### Anchor Modeling (анкерное моделирование) -Кратко +Атомарная декомпозиция сущностей и атрибутов, гибкая эволюция схемы; высокая гранулярность усложняет чтение. + +> **Сравнение (интуитивно):** Звезда — проще/быстрее для BI; 3NF — целостность и интеграция; DV/Anchor — масштабируемая интеграция из многих источников и «история по умолчанию», но сложнее читать и писать. **Сравнение моделей**: @@ -403,10 +421,129 @@ mindmap --- -Такой визуализированный план поможет студентам: -1. **Быстрее понять сложные концепции** через схемы -2. **Увидеть связи между разделами** через общую навигацию -3. **Запомнить ключевые отличия** моделей через сравнительные диаграммы -4. **Поножить практическое применение** через конкретные примеры +## **10. Заключение: главное — понимать «почему»** + +Ключевые идеи: разделение на слои (STG → ODS → DDS → DM), разные модели для разных задач (3NF, Star, DV, Anchor), факты/измерения/SCD, итеративная сборка витрин под конкретные вопросы бизнеса. + +# Приложения + +### 2) Мини-глоссарий RU/EN (по 1–2 строки) + +* **Слой (Layer)** — логический уровень в DWH: STG/ODS/DDS/DM. +* **Витрина (Data Mart)** — предметно-ориентированный набор таблиц/представлений для конкретной аналитики. +* **Факт (Fact)** — таблица событий/измерений величин (кол-во, сумма). +* **Измерение (Dimension)** — справочник контекста фактов (клиенты, товары, даты). +* **Суррогатный ключ (Surrogate Key, SK)** — искусственный технический ключ (int/bigint). +* **Бизнес-ключ (Business Key, BK)** — естественный ключ из источника (например, `customer_id`). +* **SCD (Slowly Changing Dimension)** — подход к хранению истории атрибутов измерения. +* **CDC (Change Data Capture)** — техника инкрементальной загрузки изменений. +* **Conformed Dimension** — «конформное» измерение, общее для нескольких витрин. + +### 3) Отображение синонимов слоёв + +* **STG (Bronze)** → **ODS (Silver)** → **DDS (Conformed/Core)** → **DM (Gold)**. + +### 4) «Правила слоя» — короткие чек-листы + + + +### 5) Антипаттерны (короткий бокс) + +* «Одна огромная историческая таблица» → медленные запросы, нет истории атрибутов. +* «Смешали STG и ODS» → потеря трассировки ошибок и инцидентов качества. +* «Факт с текстовыми атрибутами без причин» → раздутая таблица и неявные бизнес-правила. +* «SCD без BK» → история «плывёт», не привязана к бизнес-идентификатору. + + + + +### 10) «Зачем разные модели» (без выбора) + +* **Star (звезда):** быстро писать отчёты, учим новичков на ней. +* **3NF:** лучшая консистентность/интеграция понятий, тяжелее для BI. +* **Data Vault:** масштабируемая интеграция множества источников + «история по умолчанию». +* **Anchor:** гибкая эволюция схемы, максимальная атомарность, цена — сложность. + +### 11) Что почитать дальше + +* **Kimball, The Data Warehouse Toolkit** — модели «звезды», SCD. +* **Inmon, Building the Data Warehouse** — корпоративный DWH и нормализация. +* **Linstedt & Olschimke, The Data Vault 2.0** — практический DV. +* **Anchor Modeling** — официальный сайт/документация по Anchor. + +--- + +## ЧАСТЬ C. Мини-датасет (для примеров в статье) + +> Опционально приложить к репозиторию/приложению статьи. + +**customers.csv** + +``` +customer_id,email,phone,city +101,a@ex.com,700,Москва +101,b@ex.com,700,Москва +102,c@ex.com,701,СПб +``` + +**orders.csv** + +``` +order_id,order_date,customer_id +5001,2024-01-10,101 +5002,2024-02-05,102 +``` + +**order_items.csv** + +``` +order_item_id,order_id,product_id,qty,price_at_sale +1,5001,9001,2,100.00 +2,5001,9002,1,50.00 +3,5002,9001,1,100.00 +``` + +**products.csv** + +``` +product_id,name +9001,Phone +9002,Case +``` + +**prices.csv** + +``` +product_id,valid_from,valid_to,price +9001,2023-12-01,2024-01-31,100 +9001,2024-02-01,2999-12-31,110 +``` + +--- + +## ЧАСТЬ D. DDL-скелеты (минимально) + +```sql +-- DDS: измерение клиента (Type 2) +CREATE TABLE dds.dim_customer ( + customer_sk BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, + customer_bk VARCHAR NOT NULL, + email VARCHAR, + phone VARCHAR, + city VARCHAR, + valid_from DATE NOT NULL, + valid_to DATE, + is_current BOOLEAN NOT NULL DEFAULT TRUE +); + +-- DDS: факт продаж (гранулярность: строка заказа) +CREATE TABLE dds.fact_sales ( + sale_id BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, + customer_sk BIGINT NOT NULL, + product_sk BIGINT NOT NULL, + date_sk INT NOT NULL, + quantity INT NOT NULL, + amount DECIMAL(18,2) NOT NULL +); +``` -Все схемы готовы к использованию в статье и будут отлично работать в Markdown-редакторах с поддержкой Mermaid. \ No newline at end of file