Обновлена статья DWH-моделирование: переработан раздел Data Vault, исправлены опечатки, добавлена ссылка на домашку
This commit is contained in:
+6
-77
@@ -281,7 +281,7 @@ AND (dim_customer.valid_to IS NULL OR fact_sales.order_date < dim_customer.valid
|
||||
```
|
||||
и получаем актуальный на тот день email и город.
|
||||
|
||||
> 🔍 Подробнее про SCD — в отдельной статье [Slow Changing Dimensions](SCD.md) (сравнение Type 1/2/3, паттерны обновления).
|
||||
> 🔍 Подробнее про SCD — в отдельной статье [Slowly Changing Dimensions](SCD.md) (сравнение Type 1/2/3, паттерны обновления).
|
||||
|
||||
Теперь, когда мы разобрались, что такое факты, измерения и SCD, давайте посмотрим, как именно можно устроить слой DDS внутри — есть несколько вариантов.
|
||||
|
||||
@@ -374,82 +374,9 @@ AND (dim_customer.valid_to IS NULL OR fact_sales.order_date < dim_customer.valid
|
||||
- новые источники проще прикручивать;
|
||||
- меньше шансов «сломать» старые отчёты.
|
||||
|
||||
---
|
||||
Data Vault хорошо подходит там, где много разнородных источников, нужна полная история изменений и прозрачный аудит. За гибкость приходится платить сложностью модели и количеством таблиц — поэтому для небольших проектов (2–5 источников, маленькая команда) DV почти наверняка избыточен.
|
||||
|
||||
#### Чем DV отличается от 3NF и Звезды
|
||||
|
||||
Если сильно упростить:
|
||||
|
||||
- В **3NF/Звезде** мы часто смешиваем:
|
||||
- бизнес-ключ,
|
||||
- текущие атрибуты,
|
||||
- историю (SCD2)
|
||||
— всё это в одной таблице измерения.
|
||||
|
||||
- В **Data Vault** это *разнесено*:
|
||||
- Hub — только бизнес-ключ;
|
||||
- Satellite — только атрибуты + история;
|
||||
- Link — только связи между сущностями.
|
||||
|
||||
За это приходится платить сложностью модели и количеством таблиц. Зато DV хорошо выдерживает:
|
||||
- много разнородных источников;
|
||||
- «грязные» данные;
|
||||
- жёсткие требования по аудиту и трассировке.
|
||||
|
||||
---
|
||||
|
||||
#### Raw Vault и Business Vault — два слоя
|
||||
|
||||
Часто говорят «Raw Vault» и «Business Vault». Грубо:
|
||||
|
||||
- **Raw Vault** — «как прилетело из источников».
|
||||
Хабы, линкы и сателлиты, максимально близкие к исходным данным.
|
||||
Задача: надёжно собрать и сохранить **полную историю**.
|
||||
|
||||
- **Business Vault** — «как удобно считать дальше».
|
||||
На основе Raw Vault появляются:
|
||||
- служебные таблицы (PIT, Bridge и т.п.),
|
||||
- подготовленные представления под витрины и отчёты,
|
||||
- бизнес-правила (например, что считать «активным клиентом»).
|
||||
|
||||
Дальше поверх этого уже строятся **обычные витрины в формате Звезды**, с которыми работают аналитики.
|
||||
|
||||
Если примерить это к классическим слоям `stg → ods → dds → dm`, то **очень грубо** можно думать так:
|
||||
|
||||
- `stg` всё равно остаётся как «приземление» (landing) из источников;
|
||||
- **Raw Vault** по духу ближе к **ODS**: мало бизнес-логики, зато полная история и интеграция из разных систем;
|
||||
- **Business Vault** ближе к **DDS**: здесь уже живут бизнес-правила и подготовка данных к витринам;
|
||||
- `dm` по-прежнему остаётся витринами в формате Звезды, с которыми работают аналитики и BI.
|
||||
|
||||
Важно: это именно *аналогия для понимания*, а не жёсткое правило проектирования.
|
||||
|
||||
---
|
||||
|
||||
#### Когда DV вам, скорее всего, рано
|
||||
|
||||
Если у вас:
|
||||
|
||||
- 2–5 источников,
|
||||
- небольшая команда (1–2 инженера + аналитик),
|
||||
- задачи уровня «сделать первые отчёты»,
|
||||
|
||||
то **Data Vault почти наверняка избыточен**.
|
||||
Чаще всего хватает связки:
|
||||
|
||||
> `stg → ods → dds (3NF или простая Звезда с SCD2) → dm (Звезда)`
|
||||
|
||||
---
|
||||
|
||||
#### Что важно запомнить из этой статьи
|
||||
|
||||
Для этой статьи достаточно:
|
||||
|
||||
- знать, что **Data Vault** — это способ строить хранилище как **конструктор из Hub/Link/Satellite**,
|
||||
- понимать, что он нужен в первую очередь там, где:
|
||||
- много систем-источников,
|
||||
- нужна *полная* история и прозрачный аудит.
|
||||
|
||||
Детали (Raw vs Business Vault, PIT/Bridge, DV 1.0 vs 2.0 и т.п.) — это уже тема для отдельной, взрослой статьи.
|
||||
> 🔍 Подробнее про Data Vault — сравнение с 3NF/Звездой, Raw и Business Vault, когда внедрять — в отдельной статье [DataVault: как пережить бурную жизнь источников](DataVault.md).
|
||||
|
||||
---
|
||||
|
||||
@@ -577,6 +504,8 @@ GROUP BY d.date_actual, p.product_name, c.customer_segment;
|
||||
|
||||
> 💡 **Материализованное представление (MATERIALIZED VIEW)** — это «кэш» результата. Обновляется по расписанию (например, ночью).
|
||||
|
||||
✏️ **Попробуйте сами:** [Домашка: статусы клиента от STG до DDS (и немного DM)](Homework_Customer_Status_DDS_DM.md) — пройдёте тот же путь, но самостоятельно.
|
||||
|
||||
---
|
||||
|
||||
## 8. Как выбрать модель данных? Советы от практиков
|
||||
@@ -628,7 +557,7 @@ GROUP BY d.date_actual, p.product_name, c.customer_segment;
|
||||
Почему: ему нужны готовые метрики без сложных JOIN’ов. Звезда даёт понятные таблицы: «продажи по дням и товарам» — без углубления в атомарные сущности.
|
||||
|
||||
— **BI-разработчик в Power BI / Tableau** → **Звезда**
|
||||
Почему: все инструменты визуализации оптимизированы под star schema. Один факт + несколько измерений = быстрые отчёты и простою модель.
|
||||
Почему: все инструменты визуализации оптимизированы под star schema. Один факт + несколько измерений = быстрые отчёты и простую модель.
|
||||
|
||||
— **Инженер ML (Data Scientist / ML-инженер)** → **3NF или сырые ODS-таблицы**
|
||||
Почему: для фичей нужны атомарные события и детальные атрибуты. Машинное обучение ценит полноту и детализацию данных больше, чем удобство отчётов.
|
||||
|
||||
Reference in New Issue
Block a user