Моделирование DWH на собеседовании Data Engineer

Зачем разбирать на собесе

DWH modeling — основа аналитического стека. На собесе DE: «типы fact», «conformed dim», «junk dim».

Fact tables — типы

Transaction fact. Самый частый. Каждая строка — event (order, click, payment).

Periodic snapshot. Snapshot per period (daily inventory, monthly account balance).

Accumulating snapshot. Каждая строка — process с timestamps на каждом stage.

order_id | placed_at | paid_at | shipped_at | delivered_at

Updated as process progresses. Хорошо для funnel analysis.

Factless fact. Connecting dimensions без metric (registration to course — no fact, just relation).

Dimension tables

Standard. Customer, product, date, time, location.

Date dimension. Pre-populated with dates + attributes (day_of_week, is_holiday, fiscal_quarter, etc).

Time dimension. Если importance — на минутный / hourly grain.

Role-playing dimension. Same dim referenced multiple times (order_date, ship_date, delivery_date — все ссылаются на date_dim).

Degenerate dimension. Dimension без separate table — стрига в fact (например, transaction_id).

Conformed dimensions

Same dim используется в multiple fact tables.

fact_orders ──→ dim_customer ←── fact_returns
fact_orders ──→ dim_product  ←── fact_inventory

Зачем: consistency analytics. «Customer» same definition в Sales и Returns.

Implementation. Single source of truth dim. Fact tables референсируют через PK.

Junk dimension

Сольёт многие low-cardinality flags / enums в одну таблицу.

Без junk dim. 10 boolean flags в fact — bloat fact rows.

С junk dim.

junk_dim_order:
  junk_id | is_premium | is_promo | shipping_speed | payment_method
  1       | true        | false    | express        | card
  2       | false       | false    | standard       | cash
  ...

Fact ссылается на junk_id. Уменьшает fact size.

Mini-dimension

Если dim имеет много changing attributes — Type 2 raises in size huge. Вынесем changing attributes в отдельную mini-dim.

Customer — name, address (rarely change) + age_group, income_band (могут меняться).

dim_customer (slow-changing — Type 2)
mini_dim_customer_demographics (фrequently changing — like Type 2)
fact_orders → both dims

Bridge tables

Для many-to-many между fact и dim.

Example. Customer has multiple addresses. Без bridge — duplicate fact rows. С bridge:

dim_customer ─┐
              ├─ bridge_customer_address ─┐
              │                            ├─ dim_address
              └────────────────────────────┘

Querying — через bridge.

Allocation factor. Bridge может содержать weight (50% / 50% между addresses).

Связанные темы

• Inmon vs Kimball для DE
• Star schema vs Snowflake для DE
• SCD типы для DE
• SCD deep для DE
• Подготовка к собесу Data Engineer

FAQ

Можно ли пропустить date dim?

Технически да, но плохо. Pre-computed date dim ускоряет queries и стандартизирует date logic.

Это официальная информация?

Нет. Статья основана на Kimball methodology («The Data Warehouse Toolkit»).

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.