From c66ba776c28e1cdebb29d22cc9816cd6000b9200 Mon Sep 17 00:00:00 2001 From: Dmitry Dementev Date: Sat, 15 Nov 2025 18:43:43 +0300 Subject: [PATCH] =?UTF-8?q?=D0=9F=D0=B5=D1=80=D0=B5=D1=81=D0=BE=D0=B1?= =?UTF-8?q?=D1=80=D0=B0=D0=BD=20=D1=80=D0=B0=D0=B7=D0=B4=D0=B5=D0=BB=208?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- dwh-modeling/README.md | 72 ++++++++++++++++++++---------------------- 1 file changed, 35 insertions(+), 37 deletions(-) diff --git a/dwh-modeling/README.md b/dwh-modeling/README.md index 995cd1f..1ea81df 100644 --- a/dwh-modeling/README.md +++ b/dwh-modeling/README.md @@ -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. Он того стоит. Но *не раньше времени*.