SCD (Slowly Changing Dimensions): типы 1, 2 и 3 — как хранить историю

Если атрибут измерения меняется со временем — клиент переехал из Казани в Москву, сменил тариф, к нему прикрепили нового менеджера — у вас есть три базовых способа это хранить, и называются они SCD, Slowly Changing Dimensions. Type 1 перезаписывает старое значение поверх нового и теряет историю. Type 2 заводит на каждое изменение новую строку-версию с полями valid_from, valid_to и is_current, поэтому хранит всё — это тот самый золотой стандарт, к которому сводится большинство продакшн-витрин. Type 3 добавляет колонку «предыдущее значение» и помнит ровно один шаг назад. На практике разница между ними — это разница между отчётом, который честно показывает прошлое, и отчётом, который задним числом переписывает историю. Разберу каждый на живых таблицах.

Что такое медленно меняющиеся измерения и при чём тут город клиента?

Начну с модели данных. В хранилище есть факты и измерения. Факт — это событие: заказ, платёж, клик. Он случился один раз и больше не меняется. Измерение — это справочник, который описывает участников события: клиент, товар, магазин, менеджер. Строки в измерениях живут долго и иногда меняются, но медленно — не каждую секунду, как факты, а раз в месяцы. Отсюда и название: slowly changing dimensions.

Классический пример — таблица dim_customers. У клиента есть id, имя, город, тариф. Заказы (orders) ссылаются на него по customer_id. Пока клиент никуда не переезжает, всё просто. Проблема появляется в тот день, когда он меняет город: жил в Казани, сделал за полтора года 50 заказов, потом переехал в Москву и продолжил заказывать. Вопрос, на который вам придётся ответить: что делать со строкой в dim_customers? Перезаписать город? Завести новую строку? От этого решения зависит, что покажет ваш отчёт «выручка по городам» за прошлый год.

Что сломается в отчёте, если просто перезаписать значение?

Самое дорогое, что ломается, — сопоставимость с прошлым. Возьмём тот же переезд: клиент сделал 50 заказов из Казани и 10 из Москвы. Если вы просто обновили город в справочнике на «Москва», то при джойне orders с dim_customers все 60 заказов подтянут актуальный город. Отчёт «выручка по городам за 2024» задним числом переедет: Казань потеряет выручку, которую реально принесла, Москва получит лишнюю.

Дальше начинается неприятное. Финансы открывают дашборд и видят, что прошлогодняя цифра по региону изменилась с последнего раза — хотя в прошлое, казалось бы, попасть уже нельзя. Каждый переезд клиента незаметно шевелит исторические агрегаты. Ошибки в запросе нет, данные «правильные» — просто справочник хранит только текущее состояние мира, а отчёт спрашивает про состояние на дату заказа. Именно это противоречие и решают типы SCD. И именно поэтому тема не абстрактная для дата-инженеров, а прямая боль аналитика: без историчного измерения вы не посчитаете корректно retention по когортам, доход по тарифу на момент покупки или конверсию по каналу, который был у клиента тогда, а не сейчас.

SCD Type 1: перезапись — когда истории не жалко?

Type 1 — это обычный UPDATE. Новое значение затирает старое, прошлого больше не существует.

update dim_customers
set city = 'Москва',
    updated_at = now()
where customer_id = 4820;

Всё. Одна строка на клиента, всегда актуальная, никакого разбухания таблицы. Джойн простой, отчёты быстрые. Расплата одна, но серьёзная: восстановить, что клиент когда-то жил в Казани, уже невозможно — эта информация физически стёрта.

Когда это нормально? Когда историческая версия атрибута не имеет смысла или даже вредна. Опечатку в имени исправили — старую версию хранить незачем. Пользователь попросил удалить неверный email — по требованиям к персональным данным его вообще нельзя держать. Технический флаг, который никто не режет в разрезах, — тоже кандидат на Type 1. Правило простое: если ни один отчёт никогда не спросит «а что было раньше» — берите Type 1 и не усложняйте. Как только такой вопрос хотя бы теоретически возможен — Type 1 закрывает вам дорогу навсегда.

SCD Type 2: как хранить каждую версию строки?

Type 2 — стандарт индустрии для историчных измерений. Идея: строку не трогаем, а на каждое изменение добавляем новую версию. Старую при этом «закрываем» датой.

Для этого в таблицу добавляют служебные колонки: valid_from (с какого момента версия действует), valid_to (до какого) и is_current (флаг актуальной версии — чисто для удобства). Плюс появляется суррогатный ключ customer_sk, уникальный для каждой версии, тогда как customer_id (бизнес-ключ) остаётся общим для всех версий одного клиента.

После переезда таблица выглядит так:

Логика обновления — две операции: закрыть текущую версию и вставить новую.

-- закрываем действующую версию
update dim_customers
set valid_to = '2025-06-01',
    is_current = false
where customer_id = 4820
  and is_current = true;

-- вставляем новую версию
insert into dim_customers (customer_id, city, valid_from, valid_to, is_current)
values (4820, 'Москва', '2025-06-01', '9999-12-31', true);

Обратите внимание на две детали, на которых спотыкаются. Первая — интервал полуоткрытый: valid_from новой версии совпадает с valid_to старой, а границы трактуются как valid_from, valid_to). Так между версиями нет ни зазора, ни нахлёста, и заказ ровно на дату перехода попадёт строго в одну строку. Вторая — для текущей версии valid_to ставят не NULL, а «бесконечность» вроде 9999-12-31. Тогда фильтр по дате работает без костылей с coalesce. Да, таблица растёт, джойны становятся сложнее — но взамен вы получаете полную, точную историю каждого атрибута. Для аналитики это почти всегда правильный размен.

alter table dim_customers add column previous_city text;

update dim_customers
set previous_city = city,   -- старое значение уезжает в «предыдущее»
    city = 'Москва'         -- новое встаёт в актуальное
where customer_id = 4820;

{% snapshot customers_snapshot %}

{{
    config(
      target_schema='snapshots',
      unique_key='customer_id',
      strategy='timestamp',
      updated_at='updated_at'
    )
}}

select customer_id, city, plan, updated_at
from {{ source('crm', 'customers') }}

{% endsnapshot %}

select
    o.order_id,
    o.order_date,
    o.amount,
    c.city                       -- город, актуальный на дату заказа
from orders o
join dim_customers c
    on o.customer_id = c.customer_id
   and o.order_date >= c.valid_from
   and o.order_date <  c.valid_to;

select city, count(*) as customers
from dim_customers
where is_current = true
group by city;

Одна и та же таблица Type 2 закрывает оба сценария: и «как было тогда», и «как есть сейчас». В этом вся её сила. Такой интервальный джойн стоит один раз собрать руками, чтобы он улёгся в пальцы — потренироваться можно в [SQL-тренажёре или подсмотреть синтаксис BETWEEN и джойнов в SQL-справочнике.

Что спрашивают про SCD на собеседовании?

SCD — любимая тема секции про хранилища, особенно на позициях analytics engineer и на грейдах middle+. Чаще всего просят: объяснить разницу между Type 1 и Type 2 на пальцах, написать запрос, который достаёт актуальную на дату версию (тот самый интервальный джойн выше), рассказать, что такое valid_from/valid_to/is_current и суррогатный ключ. Любят вопрос-ловушку «что будет с историческим отчётом, если сделать Type 1» — проверяют, понимаете ли вы про переписывание прошлого.

Если готовитесь целенаправленно — соберите теорию по хранилищам и прорешайте SQL на джойны и оконки: разборы реальных задач лежат в разделе вопросов с собеседований и в тренажёре задач, а как эту тему спрашивают в конкретных командах — в разборах собеседований по компаниям. Понимание SCD и историчности — из тех навыков, что напрямую двигают грейд и вилку: насколько именно, я разбирал в обзоре зарплат аналитиков.

И совет напоследок: не заучивайте типы как список, держите в голове одну мысль — SCD это про то, врёт ваш отчёт о прошлом или нет. Как только начинаете смотреть на измерения через вопрос «а что было на дату события», выбор типа становится очевидным сам собой. Если хотите системно закрыть SQL для хранилищ — джойны, оконные функции, интервальную логику — и дойти до уровня, когда историчный отчёт пишется на автомате, загляните в курс по SQL. Pro-доступ открывает все задачи тренажёра и разборы, но и на бесплатном хватит, чтобы собрать первый корректный джойн по Type 2 уже сегодня.

Связанная тема — dbt Snapshots: SCD Type 2 для истории изменений.