Доработки идей

2025-11-07 12:25:41 +03:00
parent dfc5748358
commit 42c8515b62
3 changed files with 165 additions and 27 deletions
@@ -433,27 +433,71 @@ GROUP BY d.date_actual, p.product_name, c.customer_segment;

 ---

-## **8. Как выбрать модель? Дерево решений**
+## **8. Как выбрать модель данных? Советы от практиков**

-Вот простой алгоритм:
+Выбор модели — **не техническая задача, а стратегическая**.  
+Это как решать: строить дом из кирпича, дерева или SIP-панелей. У каждой технологии — свои плюсы, но **главное — подходит ли она *вам* сегодня**.

-```
-Нужна ли история изменений? ── Нет → Звезда (просто и быстро)
-                             │
-                             Да
-                             │
-Много ли источников (>5)? ── Нет → 3NF (надёжно, понятно)
-                             │
-                             Да
-                             │
-Нужна ли аудиторская трассировка? ── Нет → 3NF + SCD
-                                      │
-                                      Да → Data Vault
-```
+### 🔹 Главное, что нужно понять новичку:

-> 🛑 Не делайте «гибрид» без причины:  
-> — Звезда в DDS — плохо (потеряете гибкость);  
-> — DV в DM — плохо (BI не потянет 50 JOIN’ов).
+> **Не существует «самой правильной» модели.**  
+> Есть **самая подходящая под ваш контекст** — и он у всех разный.
+
+---
+
+### 🛑 Что делать **не стоит** (если опыта < 2 лет в DWH):
+
+| Что делать не стоит | Почему |
+|---------------------|--------|
+| **Брать Data Vault «потому что модно»** | DV требует глубокого понимания интеграции, CDC, идемпотентности. Без этого — получите «историю», где невозможно найти актуальные данные. |
+| **Строить сложную 3NF «как в книжках» под 10 таблиц** | Если у вас 2 источника — вы потратите 2 недели на нормализацию, чтобы потом делать 5 JOIN’ов ради простого отчёта. |
+| **Пытаться «сделать сразу гибко на 5 лет вперёд»** | Гибкость = сложность. А сложность = баги, задержки, выгорание команды. |
+
+---
+
+### ✅ **Базовые советы — с чего начать, если вы учитесь или делаете первый DWH**
+
+1. **Начните с витрины в формате Звезды (Star Schema).**  
+   — Это просто: одна таблица фактов + несколько «плоских» справочников.  
+   — Это быстро: отчёт в Power BI — за 10 минут.  
+   — Это понятно: даже менеджер поймёт структуру.
+
+2. **Стройте DDS только когда это *действительно нужно*.**  
+   — Если источников ≤ 3 и они стабильны — можно `ods → dm` напрямую.  
+   — Если появятся расхождения («email в CRM и в заказах — разные»), *тогда* заводите `dds.dim_customer`.
+
+3. **Историю (SCD) включайте *постепенно*.**  
+   — Сначала — без истории (Type 1: просто обновляете строку).  
+   — Потом — только для ключевых сущностей (клиент, товар).  
+   — Только потом — думайте про DV или полную историзацию.
+
+4. **Если сомневаетесь — спросите: «А кто будет этим пользоваться?»**  
+   — Аналитик в Metabase → Звезда.  
+   — BI-разработчик в Power BI → Звезда.  
+   — Инженер, который строит ML-фичи → 3NF или даже сырые ODS-таблицы.  
+   — Аудитор или регулятор → DV (но только если вы *готовы* к его сложности).
+
+---
+
+### 💡 И ещё один совет от практиков:
+
+> **Лучше сделать простую модель — и вовремя переделать,**  
+> чем сделать «идеальную» — и застрять на этапе проектирования.
+
+Переделать Звезду → Звезда с SCD Type 2 — легко.  
+Переделать «недоделанный DV» → что-то рабочее — в 10 раз сложнее.
+
+---
+
+### 📌 Кратко — что выбрать *сегодня*, если вы только учитесь:
+
+| У вас… | Делайте… |
+|--------|----------|
+| Учебный проект, 1–2 CSV | `ods → dm` по модели **Звезда** (без DDS, без истории) |
+| Первый рабочий DWH, 3–5 источников | `stg → ods → dds (3NF/простая Звезда) → dm (Звезда)` |
+| Команда из 1 инженера + 1 аналитика | **Не трогайте DV и Anchor** — они «съедят» ваше время без отдачи |
+
+А когда наберётесь опыта — приходите в DV. Он того стоит. Но *не раньше времени*.

 ---

@@ -621,7 +665,7 @@ product_id,valid_from,valid_to,price
 9001,2024-02-01,2999-12-31,110
 ```

-> 📂 Примеры DDL, SQL-загрузки, SCD-скрипты — в [GitHub-репозитории к статье](https://github.com/yourname/dwh-basics) (реальный репо — по вашему усмотрению).
+> 📂 Примеры DDL, SQL-загрузки, SCD-скрипты — в [GitHub-репозитории к статье](https://github.com/dementev-dev/de-roadmap/).

 ---

@@ -653,11 +697,3 @@ CREATE TABLE dds.fact_sales (

 > 💡 `date_key` — это `20240110`, а не `DATE`, чтобы не делать JOIN по диапазону в `fact → dim_date`.

---
-
-Если нужно — могу:  
- добавить **интерактивные схемы** (например, кликабельные Mermaid → SVG);  
- подготовить **полный SQL-скрипт загрузки** (STG→ODS→DDS);  
- сделать **вариант статьи в формате Jupyter Notebook** (с исполняемыми ячейками).
-
-Готов дорабатывать под ваш стиль и аудиторию.