Как отслеживать изменения бизнес-атрибутов в уже загруженных данных

Что проверяют

Знаете ли вы медленно меняющиеся измерения (SCD) и можете ли выбрать тип под задачу. Интервьюера интересует, как вы узнаёте об изменении и как отчёт за прошлый период видит старое значение атрибута. Следом просят показать, как факты джойнятся к нужной версии измерения.

Как отвечать

Сначала решите с бизнесом, какие атрибуты нужно хранить в истории. Дальше выбирается тип SCD:

• SCD1: перезапись без истории. Подходит для исправления опечаток;
• SCD2: при изменении закрываете текущую строку и вставляете новую с valid_from, valid_to и флагом is_current. Факт ссылается на суррогатный ключ версии или джойнится по дате в интервале;
• SCD3: колонка с предыдущим значением, когда нужно только «было и стало»;
• история отдельной таблицей (SCD4) или сателлиты Data Vault, когда меняющихся атрибутов много.

Как ловить изменения:

• CDC из журнала базы: Debezium читает WAL или binlog и отдаёт в Kafka все вставки, обновления и удаления;
• сравнение снимков: хэш по отслеживаемым колонкам сравнивают с последней версией, дальше MERGE в хранилище или в Delta Lake;
• updated_at: дешевле всего, но зависит от дисциплины источника и не видит удалений.

В dbt это делают снапшоты со стратегией timestamp или check и списком check_cols, колонки dbt_valid_from и dbt_valid_to они ведут сами.

Где спотыкаются

Берут updated_at за единственный источник правды. Если строку обновили дважды между загрузками, промежуточная версия теряется, а удалённые записи так и остаются в хранилище живыми.

Считают хэш без учёта NULL. concat_ws в PostgreSQL пропускает NULL, и наборы ('a', NULL, 'b') и ('a', 'b', NULL) дают одинаковый хэш. NULL заменяют маркером через COALESCE до склейки.

Джойнят факты к SCD2 только по бизнес-ключу, без условия на интервал. Каждая версия измерения размножает факты, и суммы в отчёте растут.