SCD типы deep на собеседовании Data Engineer

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Карьерник — Duolingo для аналитиков: 10 минут в день тренируй SQL, Python, A/B, статистику, метрики и ещё 3 темы собеса. 1500+ вопросов в Telegram-боте. Бесплатно.

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

SCD — стандарт DWH моделирования. На собесе DE: «отличия типов», «когда type 2 vs 4».

Type 0: Retain Original

Никогда не обновляем. Insert once, never change.

Применение: immutable атрибуты (date_of_birth, country_of_birth).

ALTER TABLE customer ADD CONSTRAINT date_of_birth_immutable
CHECK (...);

Type 1: Overwrite

Просто UPDATE — старое значение теряется.

UPDATE customer SET email = 'new@a.com' WHERE id = 42;

Применение: атрибуты без historical value (исправление опечатки в имени).

Минус: нет истории.

Type 2: Add new row

Каждое изменение → новая запись со start/end dates.

-- before
| id | name  | email      | start      | END        | is_current |
| 42 | Alice | a@old.com  | 2025-01-01 | 2026-05-07 | FALSE      |

-- after change
| id | name  | email      | start      | END        | is_current |
| 42 | Alice | a@old.com  | 2025-01-01 | 2026-05-07 | FALSE      |
| 42 | Alice | a@new.com  | 2026-05-07 | NULL       | TRUE       |

Stable identity (surrogate key): customer_sk отдельно от customer_id.

customer_sk | customer_id | name | email | start | end | is_current
1           | 42          | ...  | ...   | ...   | ... | ...

Fact tables ссылаются на customer_sk — точная snapshot dim в момент event.

Применение: SCD Type 2 — самый частый. Для большинства dimensions.

Type 3: Add new column

Хранить current + previous value в same row.

| id | name  | current_email | previous_email |
| 42 | Alice | new@a.com     | old@a.com      |

Применение: редко. Когда нужно знать только last change. Слабая history.

Готовься к собесу аналитика как в Duolingo
10 минут в день — SQL, Python, A/B, метрики. 1700+ вопросов в Telegram
Открыть Карьерник в Telegram

Type 4: History table

Текущая table + separate historical table.

-- customer (current)
| id | name | email |

-- customer_history (all versions)
| id | name | email | valid_from | valid_to |

Применение: when current state queried часто, history — редко.

Type 6: Hybrid

Combine 1 + 2 + 3.

| sk | id | current_name | historical_name | start | END | is_current |

current_name — Type 1 (overwrite), historical_name — Type 2 (this row's value), start/end/is_current — Type 2 metadata.

Позволяет:

  • Get current name по any version row (Type 1 view).
  • Get name на момент row (Type 2 view).

Минус: сложнее логика.

Когда что

Type 0: immutable атрибуты.

Type 1: correction-only changes без semantic меaning.

Type 2: изменения важны (для analytics, reports). Default choice.

Type 3: очень specific need для «previous value».

Type 4: read-heavy current, rare history queries.

Type 6: advanced — flexibility query в обоих modes.

В практике 90% — Type 2. Иногда Type 4 для performance.

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

FAQ

Late-arriving dimension?

Атрибут изменился неделю назад, fact записывается сейчас — должен указывать на правильную historical version. Нужно matching по event_date.

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

Нет. Статья основана на Kimball methodology.


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