Пересобран раздел 8
This commit is contained in:
+35
-37
@@ -607,79 +607,77 @@ GROUP BY d.date_actual, p.product_name, c.customer_segment;
|
||||
|
||||
---
|
||||
|
||||
### 🛑 Что делать **не стоит** (если опыта еще мало):
|
||||
### 🛑 Что делать **не стоит** (если опыта ещё мало):
|
||||
|
||||
| Что делать не стоит | Почему |
|
||||
|---------------------|--------|
|
||||
| **Брать Data Vault «потому что модно»** | DV требует глубокого понимания интеграции, CDC, идемпотентности. Без этого — получите «историю», где невозможно найти актуальные данные. |
|
||||
| **Строить сложную 3NF «как в книжках» под 10 таблиц** | Если у вас 2 источника — вы потратите 2 недели на нормализацию, чтобы потом делать 5 JOIN’ов ради простого отчёта. |
|
||||
| **Брать Data Vault «потому что модно»** | DV требует глубокого понимания интеграции, CDC, идемпотентности. Без этого легко получить «историю», в которой невозможно найти актуальные данные. |
|
||||
| **Строить сложную 3NF «как в книжках» под 10 таблиц** | Если у вас 2–3 источника — вы потратите недели на нормализацию, чтобы потом делать 5 JOIN’ов ради простого отчёта. |
|
||||
| **Пытаться «сделать сразу гибко на 5 лет вперёд»** | Гибкость = сложность. А сложность = баги, задержки, выгорание команды. |
|
||||
|
||||
---
|
||||
|
||||
### ✅ **Базовые советы — с чего начать, если вы учитесь или делаете первый DWH**
|
||||
### ✅ Базовые советы — с чего начать, если вы учитесь или делаете первый DWH
|
||||
|
||||
#### **Начните с витрины в формате Звезды (Star Schema).**
|
||||
— Это просто: одна таблица фактов + несколько «плоских» справочников.
|
||||
1. **Начните с витрины в формате Звезды (Star Schema).**
|
||||
— Это просто: одна таблица фактов + несколько «плоских» измерений.
|
||||
— Это быстро: отчёт в BI — за 10 минут.
|
||||
— Это понятно: даже менеджер поймёт структуру.
|
||||
|
||||
#### **Стройте DDS только когда это *действительно нужно*.**
|
||||
— Если источников ≤ 3 и они стабильны — можно `ods → dm` напрямую.
|
||||
— Если появятся расхождения («email в CRM и в заказах — разные»), *тогда* заводите `dds.dim_customer`.
|
||||
2. **Стройте DDS только когда это *действительно нужно*.**
|
||||
— Если источников ≤ 3 и они стабильны — можно идти `ods → dm` напрямую.
|
||||
— Если появляются расхождения («email в CRM и в заказах — разные») — тогда заводите `dds.dim_customer` и другие общие сущности.
|
||||
|
||||
#### **Историю (SCD) включайте *постепенно*.**
|
||||
3. **Историю (SCD) включайте *постепенно*.**
|
||||
— Сначала — без истории (Type 1: просто обновляете строку).
|
||||
— Потом — только для ключевых сущностей (клиент, товар).
|
||||
— Только потом — думайте про DV или полную историзацию.
|
||||
— Потом — только для ключевых сущностей (клиент, товар, договор).
|
||||
— Только потом — думайте про DV или полную историзацию всего.
|
||||
|
||||
#### **Если сомневаетесь — спросите: «А кто будет этим пользоваться?»**
|
||||
— Аналитик в Metabase → Звезда.
|
||||
— BI-разработчик в Power BI → Звезда.
|
||||
— Инженер, который строит ML-фичи → 3NF или даже сырые ODS-таблицы.
|
||||
— Аудитор или регулятор → DV (но только если вы *готовы* к его сложности).
|
||||
4. **Если сомневаетесь — спросите: «А кто будет этим пользоваться?»**
|
||||
|
||||
#### **Если сомневаетесь — спросите: «А кто будет этим пользоваться?»**
|
||||
Выбор модели начинается не с технологий, а с вопроса: **кто будет работать с результатом?**
|
||||
Это как выбрать инструмент в мастерской: для гвоздей — молоток, для саморезов — отвёртка.
|
||||
|
||||
Выбор модели данных начинается не с технологий, а с вопроса: **кто будет работать с результатом?** Это как выбрать инструмент в мастерской: для гвоздей — молоток, для саморезов — отвертка.
|
||||
Вот как это выглядит на практике:
|
||||
|
||||
Вот как это выглядит на практике:
|
||||
— **Аналитик в Metabase / Looker Studio** → **Звезда (Star Schema)**
|
||||
Почему: ему нужны готовые метрики без сложных JOIN’ов. Звезда даёт понятные таблицы: «продажи по дням и товарам» — без углубления в атомарные сущности.
|
||||
|
||||
— **Аналитик в Metabase** → **Звезда**
|
||||
Почему: ему нужны готовые метрики без сложных JOIN'ов. Звезда даёт понятные таблицы: «продажи по дням и товарам» — без углубления в атомарные сущности.
|
||||
— **BI-разработчик в Power BI / Tableau** → **Звезда**
|
||||
Почему: все инструменты визуализации оптимизированы под star schema. Один факт + несколько измерений = быстрые отчёты и простою модель.
|
||||
|
||||
— **BI-разработчик в Power BI** → **Звезда**
|
||||
Почему: все инструменты визуализации оптимизированы под star schema. Один факт + несколько измерений = быстрые отчёты и простое обновление.
|
||||
— **Инженер ML (Data Scientist / ML-инженер)** → **3NF или сырые ODS-таблицы**
|
||||
Почему: для фичей нужны атомарные события и детальные атрибуты. Машинное обучение ценит полноту и детализацию данных больше, чем удобство отчётов.
|
||||
|
||||
— **Инженер ML** → **3NF или сырые ODS-таблицы**
|
||||
Почему: для построения фичей нужны атомарные события и детальные атрибуты. Машинное обучение ценит полноту данных больше, чем удобство отчётов.
|
||||
— **Юрист, финансовый контролёр, аудитор / регулятор** → **3NF с SCD Type 2, иногда + DV в ядре**
|
||||
Почему: им нужна доказуемая история изменений, но не инфраструктурная сложность DV на каждый чих.
|
||||
Обычно достаточно хранить аудит-историю по ключевым сущностям (клиенты, договоры, счета) в формате 3NF + SCD Type 2.
|
||||
**Data Vault имеет смысл только если** у вас 10+ разнородных источников и жёсткие требования по аудиту и трассировке.
|
||||
|
||||
— **Юрист или финансовый контролёр** → **3NF с SCD Type 2**
|
||||
Почему: им нужна доказуемая история изменений, но не инфраструктурная сложность DV. Достаточно хранить аудит-логи по ключевым сущностям (клиенты, договоры) с указанием «кто, когда и что изменил».
|
||||
💡 **Золотое правило:**
|
||||
«**Собирай данные как DV (максимально детально), показывай как Звезду (максимально просто).**»
|
||||
|
||||
💡 **Золотое правило**:
|
||||
«Собирай данные как DV (максимально детально), показывай как Звезду (максимально просто)».
|
||||
|
||||
На начальных этапах хватит SCD Type 2 в рамках 3NF/Звезды. Data Vault оправдан только при работе с 10+ источниками и жёстких требованиях к аудиту.
|
||||
На начальных этапах вам почти всегда хватит **SCD Type 2 в рамках 3NF/Звезды**.
|
||||
**Data Vault** нужен тогда, когда основная боль — интеграция множества систем и аудит, а не «первый отчёт для маркетинга».
|
||||
|
||||
---
|
||||
|
||||
#### 💡 И ещё один совет от практиков:
|
||||
### 💡 Ещё один совет от практиков
|
||||
|
||||
> **Лучше сделать простую модель — и вовремя переделать,**
|
||||
> чем сделать «идеальную» — и застрять на этапе проектирования.
|
||||
|
||||
Переделать Звезду → Звезда с SCD Type 2 — легко.
|
||||
Переделать «недоделанный DV» → что-то рабочее — в 10 раз сложнее.
|
||||
Переделать Звезду → Звезду с SCD Type 2 — относительно легко.
|
||||
Переделать «недоделанный DV» → что-то рабочее — в разы сложнее.
|
||||
|
||||
---
|
||||
|
||||
### 📌 Кратко — что выбрать *сегодня*, если вы только учитесь:
|
||||
### 📌 Кратко — что выбрать *сегодня*, если вы только учитесь
|
||||
|
||||
| У вас… | Делайте… |
|
||||
|--------|----------|
|
||||
| Учебный проект, 1–2 CSV | `ods → dm` по модели **Звезда** (без DDS, без истории) |
|
||||
| Первый рабочий DWH, 3–5 источников | `stg → ods → dds (3NF/простая Звезда) → dm (Звезда)` |
|
||||
| Первый рабочий DWH, 3–5 источников | `stg → ods → dds (3NF или простая Звезда) → dm (Звезда)` |
|
||||
| Команда из 1 инженера + 1 аналитика | **Не трогайте DV и Anchor** — они «съедят» ваше время без отдачи |
|
||||
|
||||
А когда наберётесь опыта — приходите в DV. Он того стоит. Но *не раньше времени*.
|
||||
|
||||
Reference in New Issue
Block a user