diff --git a/dwh-modeling/DataVault.md b/dwh-modeling/DataVault.md index f40ceb4..c3ace60 100644 --- a/dwh-modeling/DataVault.md +++ b/dwh-modeling/DataVault.md @@ -126,17 +126,18 @@ erDiagram Чуть менее «сказочно», чуть более технично. -### 3.1. Hub — сущность и её бизнес-ключ +### 3.1. Hub: сущность и её бизнес-ключ **Hub** содержит: * бизнес‑ключ (customer_bk, order_id, contract_number); * техническую информацию: - * record_source — из какой системы пришла первая запись; - * load_dttm — когда запись попала в DV; - * иногда — хэш бизнес‑ключа (hk_customer). + * record_source — из какой системы пришла первая запись; + * load_dttm — когда запись попала в DV; + * иногда — хэш бизнес‑ключа (hk_customer). Главные правила: + * один бизнес‑ключ — один хаб (одна строка на сущность, без истории); * хаб не знает про атрибуты (имя, email) — только идентичность. @@ -153,7 +154,7 @@ CREATE TABLE hub_customer ( Конкретные типы данных (`BYTEA`, длины `VARCHAR`, детали `hashdiff`) и реализации хэш‑ключей можно не запоминать: на старте важнее понять саму идею — у сущностей есть стабильные ключи, а все изменения атрибутов мы записываем отдельными версиями в сателлитах. -### 3.2. Link — связи между сущностями +### 3.2. Link: связи между сущностями **Link** описывает факт связи, например: @@ -178,7 +179,7 @@ CREATE TABLE link_order_customer ( ); ``` -### 3.3. Satellite — атрибуты и история +### 3.3. Satellite: атрибуты и история **Satellite** хранит: @@ -249,7 +250,7 @@ Star Schema] * **Raw Vault** — это про приём и хранение данных «как есть», но уже в форме Hub / Link / Satellite. * **Business Vault** — это про приведение этих данных в более «деловой» вид: с бизнес-правилами, PIT/Bridge и подготовленными представлениями. -### 5.1. Raw Vault — «всё прилетевшее, аккуратно разложенное по ящичкам» +### 5.1. Raw Vault: «всё прилетевшее, аккуратно разложенное по ящичкам» Raw DV — первый слой поверх STG / ODS: @@ -261,20 +262,20 @@ Raw DV — первый слой поверх STG / ODS: * минимум бизнес-логики: - * никаких правил вроде «клиент активен, если была хотя бы одна покупка за 90 дней»; + * никаких правил вроде «клиент активен, если была хотя бы одна покупка за 90 дней»; * все источники показываются «как есть», только приведены к общим ключам; * структура стабильна: добавился новый источник → появился новый Satellite к тому же Hub. -### 5.2. Business Vault — «там, где из Lego собирают модули» +### 5.2. Business Vault: «там, где из Lego собирают модули» Business Vault (BV) — следующий слой над Raw DV: * здесь применяются бизнес-правила (что считать активным клиентом, как трактовать статусы); * здесь строятся вспомогательные структуры: - * PIT-таблицы, - * Bridge-таблицы, - * агрегаты и derived-таблицы. + * PIT-таблицы, + * Bridge-таблицы, + * агрегаты и derived-таблицы. Именно из BV чаще всего строятся витрины в формате Звезды, к которым подключаются BI и отчётность. diff --git a/dwh-modeling/Homework_Customer_Status_DDS_DM.md b/dwh-modeling/Homework_Customer_Status_DDS_DM.md index 2a8643c..8fdfdd5 100644 --- a/dwh-modeling/Homework_Customer_Status_DDS_DM.md +++ b/dwh-modeling/Homework_Customer_Status_DDS_DM.md @@ -71,7 +71,7 @@ customer_id,status,event_ts,_load_id,_load_ts --- -## 3. Часть 1 — STG → ODS (обязательно) +## 3. Часть 1: STG → ODS (обязательно) **Задача:** загрузить CSV в STG и переложить данные в ODS с приведением типов. @@ -145,7 +145,7 @@ ORDER BY customer_id, event_ts; --- -## 4. Часть 2 — ODS → DDS (SCD Type 2, обязательно) +## 4. Часть 2: ODS → DDS (SCD Type 2, обязательно) **Задача:** по событиям в `ods.customer_status` построить измерение `dds.dim_customer_status`, где каждая строка — период действия статуса. @@ -216,7 +216,7 @@ ORDER BY customer_bk, valid_from; --- -## 5. Часть 3 — инкрементальная загрузка (по желанию) +## 5. Часть 3: инкрементальная загрузка (по желанию) Если хочется потренироваться глубже: @@ -241,7 +241,7 @@ cat dwh-modeling/data/customer_status_events_increment.csv | ./postgres-bookings --- -## 6. Часть 4 — витрина в DM (по желанию) +## 6. Часть 4: витрина в DM (по желанию) Опциональное задание для закрепления: собрать небольшую витрину с количеством клиентов по статусам на каждую дату. diff --git a/dwh-modeling/README.md b/dwh-modeling/README.md index 6e9c0c8..bc3fac8 100644 --- a/dwh-modeling/README.md +++ b/dwh-modeling/README.md @@ -145,7 +145,7 @@ flowchart TD Давайте проследим, как превращается строка заказа. -### **STG (Staging / Bronze)** — «как пришло» +### **STG (Staging / Bronze)**: «как пришло» - Таблицы: `stg.orders_raw`, `stg.customers_raw`; - Структура — *точно как в источнике* (может быть `VARCHAR` даже у дат); @@ -158,7 +158,7 @@ flowchart TD --- -### **ODS (Operational Data Store / Silver)** — «почистили, но не трогали смысл» +### **ODS (Operational Data Store / Silver)**: «почистили, но не трогали смысл» - Таблицы: `ods.orders`, `ods.customers`; - Здесь: @@ -174,7 +174,7 @@ flowchart TD --- -### **DDS (Data Delivery Store / Core / Conformed)** — «интеграция + история» +### **DDS (Data Delivery Store / Core / Conformed)**: «интеграция + история» Здесь рождается *единая бизнес-модель*. Появляются понятия: **измерения**, **факты**, **суррогатные ключи**, **SCD**. @@ -199,7 +199,7 @@ flowchart TD --- -### **DM (Data Mart / Gold/ «Витрины»)** — «готово к употреблению» +### **DM (Data Mart / Gold / «Витрины»)**: «готово к употреблению» Здесь — таблицы и представления для конкретных задач: @@ -266,7 +266,7 @@ erDiagram } ``` -### SCD Type 2 — как хранить историю +### SCD Type 2: как хранить историю Клиент №101: @@ -418,7 +418,7 @@ WHERE c.city = 'Москва' --- -### 3. Data Vault 2.0 — «конструктор Lego» для больших DWH +### 3. Data Vault 2.0: «конструктор Lego» для больших DWH *Идея: Дэн Линстедт (Dan Linstedt). Цель — так организовать хранилище, чтобы можно было спокойно добавлять новые источники и хранить историю, не ломая старую модель.* @@ -468,7 +468,7 @@ Anchor Modeling - ещё более атомарный подход к моде --- -### Сравнение моделей — наглядно +### Сравнение моделей наглядно ```mermaid quadrantChart @@ -540,7 +540,7 @@ flowchart TD ### Готовые SQL-скрипты -Все необходимые скрипты для построения хранилища находятся в папке [`sql/`](sql/): +Все необходимые скрипты для построения хранилища находятся в папке [`sql/`](https://github.com/dementev-dev/de-roadmap/tree/main/dwh-modeling/sql): - [`01_ddl_stg-dds.sql`](sql/01_ddl_stg-dds.sql) — создание схем и таблиц (STG, ODS, DDS); - [`02_dml_stg-dds.sql`](sql/02_dml_stg-dds.sql) — первичная загрузка данных и демонстрация SCD2 через полный пересчёт (`full backfill`) из STG; @@ -605,7 +605,7 @@ GROUP BY d.date_actual, p.product_name, --- -### ✅ Базовые советы — с чего начать, если вы учитесь или делаете первый DWH +### ✅ Базовые советы: с чего начать, если вы учитесь или делаете первый DWH 1. **Начните с витрины в формате Звезды (Star Schema).** — Это просто: одна таблица фактов + несколько «плоских» измерений. @@ -660,7 +660,7 @@ GROUP BY d.date_actual, p.product_name, --- -### 📌 Кратко — что выбрать *сегодня*, если вы только учитесь +### 📌 Кратко: что выбрать *сегодня*, если вы только учитесь | У вас… | Делайте… | |--------|----------| @@ -791,7 +791,7 @@ SELECT 'OK' WHERE EXISTS ( ### Мини-датасет (для практики) -Все данные для практики находятся в папке [`data/`](data/) — тренируйтесь: +Все данные для практики находятся в папке [`data/`](https://github.com/dementev-dev/de-roadmap/tree/main/dwh-modeling/data) — тренируйтесь: [`customers.csv`](data/customers.csv): ```csv @@ -832,7 +832,7 @@ product_id,valid_from,valid_to,price 9002,2023-01-01,,50 ``` -> 📂 Все SQL-скрипты для построения хранилища находятся в папке [`sql/`](sql/). +> 📂 Все SQL-скрипты для построения хранилища находятся в папке [`sql/`](https://github.com/dementev-dev/de-roadmap/tree/main/dwh-modeling/sql). --- diff --git a/dwh-modeling/SCD.md b/dwh-modeling/SCD.md index 4daf7f5..42a324a 100644 --- a/dwh-modeling/SCD.md +++ b/dwh-modeling/SCD.md @@ -28,15 +28,15 @@ SCD — это подход к хранению изменений в измер --- -## 3. Типы SCD — простыми словами +## 3. Типы SCD простыми словами Существует несколько стандартных стратегий обработки изменений. Рассмотрим самые важные. -### **Type 0 — Никогда не меняется** +### **Type 0: никогда не меняется** Атрибут фиксирован навсегда. Например, дата рождения клиента. Такие поля не требуют специальной обработки — они просто не обновляются. -### **Type 1 — Просто перезаписать** +### **Type 1: просто перезаписать** Вы просто делаете `UPDATE`, и старое значение исчезает. ✅ Просто. @@ -44,7 +44,7 @@ SCD — это подход к хранению изменений в измер > Подходит, если изменение — это исправление ошибки (например, опечатка в имени). -### **Type 2 — Новая строка для новой версии** +### **Type 2: новая строка для новой версии** Каждое изменение порождает **новую строку** в таблице. Старая строка остаётся, но помечается как «устаревшая». ✅ Полная история. @@ -53,7 +53,7 @@ SCD — это подход к хранению изменений в измер > Это **самый распространённый** подход в аналитике. -### **Type 3 — Добавить колонку «предыдущее значение»** +### **Type 3: добавить колонку «предыдущее значение»** В таблице появляются поля вроде `previous_category`, `category_change_date`. ✅ Простая история «до/после». @@ -61,7 +61,7 @@ SCD — это подход к хранению изменений в измер > Используется редко, чаще как компромисс в очень простых системах. -### **Type 4, 5, 6 — Продвинутые гибриды** +### **Type 4, 5, 6: продвинутые гибриды** Эти типы существуют, но **встречаются редко** и почти не используются новичками: - **Type 4**: история выносится в отдельную таблицу («мини-хранилище» для одного измерения). @@ -99,7 +99,7 @@ WHERE customer_id = 1; --- -### Type 2: сохраняем историю — подробнее +### Type 2: сохраняем историю (подробнее) Чтобы хранить историю, мы меняем структуру таблицы. Вот ключевые поля: