Yuriy Gavrilov: posts tagged dbt

dbt открывает исходный код MetricFlow: Управляемые метрики для AI и аналитики

Sat, 01 Nov 2025 01:03:55 +0300

Компания dbt Labs объявила о важном изменении в своей стратегии: `MetricFlow`, ключевая технология, лежащая в основе `dbt Semantic Layer`, становится полностью открытой. Проект переводится под лицензию Apache 2.0, что позволяет любому использовать, изменять и встраивать его в свои продукты. Это стратегический шаг, направленный на создание единого отраслевого стандарта для определения бизнес-метрик, особенно в свете бурного развития AI-систем.

Оригинал тут: https://www.getdbt.com/blog/open-source-metricflow-governed-metrics
А гит тут: https://github.com/dbt-labs/metricflow

Еще кстати есть https://github.com/memiiso/opendbt ( Make dbt great again! :) Может они сольются с метриками, интересно.

Проблема: почему семантический слой стал критически важен

Концепция семантического слоя, который служит промежуточным слоем для определения бизнес-логики (метрик, измерений, связей), не нова. Она уже много лет используется в BI-системах для обеспечения согласованности отчетов. Однако с появлением больших языковых моделей (LLM) и инструментов в стиле “Chat with your data” проблема вышла на новый уровень.

Когда AI-агент или LLM пытается ответить на вопрос, обращаясь напрямую к базе данных, он вынужден самостоятельно генерировать SQL-запрос. При этом модель “угадывает”, какие таблицы нужно соединить (`JOIN`), как правильно отфильтровать данные, какую использовать гранулярность по времени и какие оконные функции применить.

Проблемы такого подхода:

Несогласованность: Две разные модели (или даже одна и та же, но с другим запросом) могут сгенерировать разный SQL для расчета, казалось бы, одной и той же метрики. Это приводит к разным цифрам в отчетах.
Ошибки: LLM может не знать о тонкостях бизнес-логики, например, о том, что при расчете выручки нужно учитывать возвраты или использовать специальный финансовый календарь.
Потеря доверия: Когда пользователи получают противоречивые или неверные данные, доверие ко всей системе аналитики быстро падает.

Метрики не должны быть вероятностными, зависящими от “догадок” LLM при каждом вызове. Они должны быть детерминированными.

`MetricFlow` решает именно эту задачу.

Что такое MetricFlow и как он работает

`MetricFlow` — это движок, который преобразует семантические определения бизнес-понятий в готовый к выполнению и оптимизированный SQL-код. Аналитик один раз определяет метрику “Валовая маржа” на языке `MetricFlow`, и после этого любая система (BI-инструмент, AI-агент, Python-скрипт) может запросить эту метрику по имени, будучи уверенной, что получит корректный и одинаковый результат.

Ключевые изменения и их значение

Лицензия Apache 2.0: Это одно из главных нововведений. Apache 2.0 — это разрешительная лицензия, которая позволяет другим компаниям свободно встраивать `MetricFlow` в свои коммерческие и открытые продукты. Это снимает барьеры для принятия технологии и способствует ее распространению как стандарта.
Сотрудничество с Open Semantic Interchange (OSI): dbt Labs будет развивать `MetricFlow` совместно с такими партнерами, как Snowflake и Salesforce, в рамках инициативы OSI. Цель — создать единый стандарт для семантической совместимости между разными платформами, чтобы метрики, определенные один раз, одинаково работали во всех инструментах.

Как MetricFlow обеспечивает надежность AI

`MetricFlow` предоставляет открытый стандарт для метаданных и расширяемый движок, который превращает намерение (“покажи валовую маржу”) в SQL-запрос для хранилища данных.

Пример работы:

Предположим, пользователь задает AI-агенту вопрос:

“Покажи валовую маржу (%) по месяцам за прошлый квартал для Северной Америки (за вычетом скидок и возвратов, по финансовому календарю).”

Без семантического слоя LLM пришлось бы конструировать сложный запрос с нуля. С `MetricFlow` процесс выглядит так:

Агент распознает намерение и запрашивает у `MetricFlow` метрику `gross_margin_pct` с нужными измерениями (`region`, `fiscal_month`) и фильтрами.
`MetricFlow`, на основе заранее созданных определений, строит план запроса:
- Находит нужные таблицы: `orders`, `discounts`, `returns`, `cogs` (себестоимость).
- Применяет правильные `JOIN` между ними.
- Применяет фильтр по региону (`North America`).
- Группирует данные по месяцам финансового, а не календарного, года.
- Рассчитывает числитель (выручка) и знаменатель (себестоимость) с учетом того, что популяция данных для них должна быть одинаковой.
- Вычисляет итоговое соотношение.
`MetricFlow` компилирует этот план в оптимизированный SQL-запрос, специфичный для диалекта конкретного хранилища (Snowflake, BigQuery, Databricks и т.д.).
Запрос выполняется в хранилище, и результат возвращается пользователю.

При этом весь сгенерированный SQL доступен для проверки, что обеспечивает прозрачность и объяснимость вычислений.

Основные возможности движка:

Единое определение, выполнение где угодно: Метрики и измерения определяются один раз, а `MetricFlow` компилирует их в SQL для разных диалектов.
Оптимизация производительности: Движок строит эффективные запросы, чтобы избежать лишних сканирований и снизить нагрузку на хранилище данных.
Поддержка сложных вычислений: `MetricFlow` из коробки обрабатывает сложные соединения, оконные функции, расчеты по когортам и полуаддитивные метрики (например, остатки на счетах, которые нельзя просто суммировать по времени).

`MetricFlow` vs. `dbt Semantic Layer`

Важно понимать различие между двумя компонентами:

`MetricFlow` — это движок с открытым исходным кодом для определения и вычисления метрик. Это “сердце” системы, которое выполняет всю сложную работу по генерации SQL.
`dbt Semantic Layer` — это коммерческий продукт dbt Labs, построенный *поверх* `MetricFlow`. Он добавляет функциональность корпоративного уровня:
- Управление доступом (`RBAC`).
- Версионирование определений метрик.
- Аудит и отслеживание происхождения данных (`lineage`).
- Надежные API и коннекторы для интеграции с BI- и AI-инструментами.

Таким образом, `MetricFlow` становится общедоступным строительным блоком, а `dbt Semantic Layer` — готовым решением для его безопасного и управляемого внедрения в компаниях.

Итог

dbt Labs сделала `MetricFlow` (движок для расчета метрик) полностью открытым под лицензией Apache 2.0. Это позволяет всем желающим использовать его без ограничений.
Главная цель — создать открытый стандарт для определения бизнес-метрик. Это особенно актуально для AI-систем, которые часто ошибаются при самостоятельной генерации SQL.
`MetricFlow` позволяет AI и BI-инструментам запрашивать данные по имени метрики (например, `revenue`), получая детерминированный и корректный SQL-запрос. Это повышает надежность и согласованность данных.
Этот шаг способствует совместимости инструментов (`interoperability`) и снижает зависимость от конкретного вендора (`vendor lock-in`). Метрики, определенные один раз, будут работать одинаково в разных системах.
Коммерческий продукт `dbt Semantic Layer` продолжит развиваться как решение для управления жизненным циклом метрик в корпоративной среде (безопасность, контроль версий, аудит).

Новая эра трансформации данных: dbt против Bruin и aaC

Sat, 23 Aug 2025 16:04:02 +0300

В мире данных произошла тихая, но фундаментальная революция. На смену традиционному подходу ETL (Extract, Transform, Load), где данные преобразовывались до загрузки в хранилище, пришла новая парадигма — ELT (Extract, Load, Transform). Благодаря мощности современных облачных хранилищ (таких как Snowflake, BigQuery, Databricks, Starburst\Trino) стало выгоднее сначала загружать сырые данные, а уже затем трансформировать их непосредственно в хранилище.

Этот сдвиг породил потребность в инструментах, которые специализируются на последнем шаге — трансформации (T). Именно в этой нише dbt (data build tool) стал безоговорочным лидером, но на его поле появляются и новые сильные игроки, такие как Bruin. Давайте разберемся, что это за инструменты, какой подход они олицетворяют и в чем их ключевые различия.

Подход «Аналитика как код»

И dbt, и Bruin являются яркими представителями движения “Analytics as Code” (аналитика как код). Это не просто инструменты, а целая философия, которая переносит лучшие практики разработки программного обеспечения в мир аналитики данных.

Основные принципы и идеи:

Версионирование: Все трансформации данных описываются в виде кода (в основном SQL), который хранится в системе контроля версий, такой как Git. Это позволяет отслеживать изменения, совместно работать и откатываться к предыдущим версиям.
Модульность и переиспользование (DRY – Don’t Repeat Yourself): Сложные трансформации разбиваются на небольшие, логически завершенные модели, которые могут ссылаться друг на друга. Это делает код чище, понятнее и позволяет повторно использовать уже написанную логику.
Тестирование: Код трансформаций должен быть протестирован. Инструменты позволяют автоматически проверять качество данных после преобразований: на уникальность ключей, отсутствие `NULL` значений, соответствие заданным условиям и т.д.
Документация и прозрачность: Процесс трансформации становится самодокументируемым. Инструменты могут автоматически генерировать документацию и строить графы зависимостей моделей (data lineage), показывая, как данные текут и преобразуются от источника к конечному виду. element61.be
CI/CD (Continuous Integration / Continuous Deployment): Изменения в коде трансформаций могут автоматически тестироваться и разворачиваться в продуктивную среду, что значительно ускоряет циклы разработки.

Решаемые проблемы:

“Черные ящики” ETL: Заменяют сложные, трудноподдерживаемые и непрозрачные ETL-процессы на понятный и документированный код.
Рассинхронизация команд: Стирают границы между инженерами данных и аналитиками, позволяя аналитикам, владеющим SQL, самостоятельно создавать надежные модели данных.
Низкое качество данных: Встроенные механизмы тестирования помогают обеспечить надежность и согласованность данных.

---

dbt (data build tool): Золотой стандарт трансформации

dbt — это инструмент с открытым исходным кодом, который позволяет аналитикам и инженерам трансформировать данные в их хранилищах с помощью простых SQL-запросов. Важно понимать, что dbt не извлекает и не загружает данные. Он специализируется исключительно на шаге “T” в ELT vutr.substack.com. dbt git.

Он работает как компилятор и исполнитель: вы пишете модели данных в `.sql` файлах, используя шаблонизатор Jinja для добавления логики (циклы, условия, макросы). Затем dbt компилирует этот код в чистый SQL и выполняет его в вашем хранилище данных element61.be.

Плюсы dbt

Огромное сообщество и экосистема: dbt стал де-факто стандартом индустрии. Существует огромное количество статей, курсов, готовых пакетов (библиотек) и экспертов.
Фокус на SQL: Низкий порог входа для аналитиков, которые уже знают SQL. Это демократизирует процесс трансформации данных.
Мощное тестирование и документирование: Встроенные команды для тестирования данных и автоматической генерации проектной документации с графом зависимостей.
Зрелость и надежность: Инструмент проверен временем и используется тысячами компаний по всему миру.
Гибкость: Благодаря шаблонизатору Jinja можно создавать очень сложные и переиспользуемые макросы, адаптируя dbt под любые нужды.

Минусы dbt

Только трансформация: dbt не занимается извлечением (E) и загрузкой (L). Для этого вам понадобятся отдельные инструменты (например, Fivetran, Airbyte), что усложняет стек технологий.
Кривая обучения: Хотя основы просты, освоение продвинутых возможностей Jinja, макросов и структуры проекта требует времени.
Зависимость от Python-моделей: Хотя недавно появилась поддержка моделей на Python, она все еще не так нативна и проста, как основной SQL-подход, и требует дополнительных настроек.

---

Bruin Data: Универсальный боец

Bruin — это более новый игрок на рынке, который позиционирует себя как инструмент для создания “end-to-end” пайплайнов данных. В отличие от dbt, он не ограничивается только трансформацией, а стремится охватить больше этапов работы с данными, включая их загрузку (ingestion) https://github.com/bruin-data/bruin.

Bruin разделяет ту же философию “Analytics as Code”, но предлагает более интегрированный опыт, где SQL и Python являются равноправными гражданами.

Плюсы Bruin

Универсальность: Один инструмент для определения всего пайплайна: от загрузки из источников до финальных витрин данных. Это может упростить стек технологий.
Нативная поддержка SQL и Python: Позволяет легко комбинировать задачи на разных языках в одном пайплайне без дополнительных настроек. Это идеально для задач, где чистый SQL громоздок (например, работа с API, машинное обучение).
Простота конфигурации: Зачастую требует меньше шаблонного кода (boilerplate) для определения ассетов и пайплайнов по сравнению с dbt.
Встроенное качество данных: Как и dbt, делает акцент на проверках качества на каждом шаге.

Минусы Bruin

Пока маленькое сообщество: Как у нового инструмента, у Bruin гораздо меньше пользователей, готовых решений и обсуждений на форумах по сравнению с dbt. Найти помощь или готовый пакет для решения специфической задачи сложнее.
Незрелость: Инструмент моложе, а значит, наверное, потенциально менее стабилен и может иметь меньше интеграций по сравнению с проверенным dbt. Пока нет облачных функция за деньги. Я так думал, но все же есть https://getbruin.com.
“Мастер на все руки — эксперт ни в чем?”: Стремление охватить все этапы (E, L, T) может означать, что в каждом отдельном компоненте Bruin может уступать лучшим в своем классе специализированным инструментам (например, Fivetran в загрузке, dbt в трансформации), но это конечно субъективно.

Сводное сравнение

Характеристика	dbt (data build tool)	Bruin Data
Основная задача	Трансформация (T в ELT)	Весь пайплайн (E, L, T)
Ключевые языки	SQL с шаблонизатором Jinja	SQL и Python как равноправные
Экосистема	Огромная, стандарт индустрии	Маленькая, развивающаяся
Зрелость	Высокая, проверен временем	Низкая/Средняя
Стек инструментов	Требует отдельных E/L инструментов	Стремится быть самодостаточным

Итого

Выбор между dbt и Bruin — это выбор между двумя стратегиями построения современного стека данных.

Выбирайте dbt, если:

Вы строите гибкий стек из лучших в своем классе инструментов (“best-of-breed”): один для загрузки, другой для хранения, третий для трансформации.
Ваша команда в основном состоит из аналитиков, сильных в SQL.
Для вас критически важны поддержка сообщества, стабильность и наличие готовых решений.
Вы работаете в большой организации, где принятие отраслевых стандартов является преимуществом.
Вы готовы переехать к ним в платное облако, когда нибудь. Большая часть функционала доступна там.

Выбирайте Bruin, если:

Вы предпочитаете единый, интегрированный инструмент для управления всеми пайплайнами, чтобы упростить архитектуру
Вы любите open source и End-to-end дата framework: фор data ingestion + transformations + кволити. :)
Ваши пайплайны требуют тесной связки SQL и Python для трансформаций (например, обогащение данных через вызовы API или модели ML).
Вы начинаете новый проект или работаете в небольшой команде и цените скорость настройки и меньшее количество движущихся частей.
Вы Go’шник :) – Bruin написан на Go почти на 100%.

И dbt, и Bruin — мощные инструменты, воплощающие современные подходы к инженерии данных. dbt предлагает проверенный, сфокусированный и невероятно мощный движок для трансформаций, ставший стандартом. Bruin же предлагает более универсальный и интегрированный подход, который может быть привлекателен для команд, стремящихся к простоте и нативной поддержке Python.

А что такое “Аналитика как код” (Analytics as Code, AaC)?

Аналитика как код — это подход к управлению аналитическими процессами, при котором все компоненты аналитики — от моделей данных и метрик до отчетов и правил доступа — определяются в виде кода в человекочитаемых файлах. Эти файлы затем управляются так же, как исходный код любого другого программного обеспечения: с помощью систем контроля версий, автоматизированного тестирования и развертывания medium.com.

Самая близкая и известная аналогия — это Infrastructure as Code (IaC). Как IaC (например, с помощью Terraform) позволил инженерам описывать серверы, сети и базы данных в коде вместо ручной настройки через веб-интерфейсы, так и AaC позволяет описывать в коде всё, что связано с данными medium.com.

Идея проста и убедительна: “настройте свои системы один раз, выразите это в виде кода, а затем поместите в систему контроля версий” holistics.io.

Проблема: Как было раньше?

Чтобы понять ценность AaC, нужно посмотреть на проблемы, которые он решает. В традиционном подходе аналитика часто была разрозненной и хрупкой:

Логика в “черных ящиках”: Сложные преобразования данных были скрыты внутри GUI-интерфейсов старых ETL-инструментов или непосредственно в настройках BI-платформы (например, Tableau, Power BI). Никто, кроме автора, не мог легко понять, как рассчитывается та или иная метрика.
Разрозненные SQL-скрипты: Аналитики хранили важные SQL-запросы на своих локальных машинах, в общих папках или на wiki-страницах. Не было единой версии правды, код дублировался и быстро устаревал.
Отсутствие контроля версий: Невозможно было отследить, кто, когда и почему изменил логику расчета ключевого показателя. Откат к предыдущей работающей версии был настоящей головной болью.
“Ручное” тестирование: Проверка качества данных после изменений была ручным, подверженным ошибкам процессом. Часто о проблемах узнавали уже от бизнес-пользователей, которые видели неверные цифры в отчетах.
Рассинхронизация: Инженеры данных готовили сырые таблицы, а аналитики строили свою логику поверх них. Любые изменения с одной стороны могли сломать всю цепочку, не будучи замеченными вовремя.

Этот хаос приводил к главному — недоверию к данным. Никто не мог быть уверен, что цифры в дашборде верны.

Ключевые принципы “Аналитики как код”

AaC решает эти проблемы, внедряя практики из мира разработки ПО.

Декларативное определение: Все аналитические артефакты описываются в файлах.
- Модели данных:** `SELECT * FROM ...` в `.sql` файлах.
- Тесты:** `not_null`, `unique` в `.yml` файлах.
- Документация:** Описания таблиц и полей в `.yml` файлах.
- Метрики и дашборды:** Определения в `.yml` или специализированных файлах medium.com.

Контроль версий (Git): Весь код хранится в репозитории (например, на GitHub или GitLab).
- Прозрачность:** Каждое изменение — это `commit` с понятным описанием.
- Совместная работа:** Аналитики работают в отдельных ветках, а изменения вносятся через `Pull Request` (или `Merge Request`), что позволяет проводить ревью кода (code review).
- Восстанавливаемость:** Если что-то пошло не так, можно легко откатиться к предыдущей версии.

Автоматизированное тестирование: Тесты являются неотъемлемой частью кода. Они запускаются автоматически при каждом изменении, чтобы гарантировать, что данные по-прежнему соответствуют ожиданиям (например, `user_id` всегда уникален и не равен `NULL`).

CI/CD (Непрерывная интеграция и развертывание): Процессы полностью автоматизированы.
- Когда аналитик вносит изменения в `Pull Request`, автоматически запускаются тесты.
- После одобрения и слияния ветки изменения автоматически развертываются в продуктивной среде (например, dbt Cloud или Jenkins запускает команду `dbt run`).

Модульность и переиспользование (DRY – Don’t Repeat Yourself): Сложные потоки данных разбиваются на небольшие, логичные и переиспользуемые модели. Одна модель может ссылаться на другую, создавая четкий граф зависимостей (lineage), который можно визуализировать.

Преимущества подхода AaC

Принятие этой философии дает компании ощутимые выгоды:

Надежность и доверие: Благодаря автоматическому тестированию и ревью кода значительно повышается качество данных, а вместе с ним и доверие бизнеса к аналитике.
Скорость и гибкость: Аналитики могут вносить изменения гораздо быстрее. Цикл от идеи до готового отчета сокращается с недель до дней или даже часов.
Масштабируемость: Кодовая база легко поддерживается и расширяется. Новые члены команды могут быстро разобраться в проекте благодаря документации и прозрачности.
Прозрачность и обнаруживаемость: Автоматически сгенерированная документация и графы зависимостей позволяют любому сотруднику понять, откуда берутся данные и как они рассчитываются.
Демократизация: AaC дает возможность аналитикам, владеющим SQL, самостоятельно создавать надежные и протестированные модели данных, не дожидаясь инженеров данных. Это стирает барьеры между командами.

В конечном итоге, “Аналитика как код” — это культурный сдвиг, который превращает аналитику из ремесленного занятия в зрелую инженерную дисциплину, обеспечивая скорость, надежность и масштабируемость, необходимые современному бизнесу.

Описание патерна Slowly Changing Dimensions (SCD)

Sat, 16 Aug 2025 23:24:59 +0300

Slowly Changing Dimensions (SCD), или Медленно меняющиеся измерения, — это концепция и набор методов из области хранилищ данных (Data Warehousing), которые используются для управления изменениями в атрибутах измерений с течением времени. Измерения — это справочные таблицы, которые описывают бизнес-сущности, такие как клиенты, продукты, сотрудники, географические регионы.

Атрибуты этих сущностей (например, адрес клиента или категория продукта) меняются, но обычно не очень часто — отсюда и название “медленно меняющиеся”. Основная задача SCD — решить, как хранить эти изменения, чтобы обеспечить точность исторических отчетов www.datacamp.com.

Например, если вы просто перезапишете адрес клиента, вы потеряете информацию о том, где он жил раньше. Это может исказить анализ продаж по регионам за прошлые периоды. Патерны SCD предлагают различные стратегии для решения этой проблемы.

Основные типы SCD

Существует несколько типов SCD, но самыми распространенными и фундаментальными являются Типы 1, 2 и 3.

---

Тип 1: Перезапись атрибута (Overwrite)

Это самый простой подход. При изменении атрибута старое значение просто перезаписывается новым.

Как работает:** Находится существующая запись в таблице измерения и значение в нужном столбце обновляется.
Когда использовать:** Когда нет необходимости хранить историю изменений. Например, для исправления опечатки в имени клиента.
Преимущества:** Простота реализации, не требует увеличения объема хранилища.
Недостатки: **История изменений полностью теряется. Анализ, основанный на исторических значениях атрибута, становится невозможным.

Пример:
У нас есть клиент Анна Петрова, которая живет в Москве.

*Таблица `DimCustomer` до изменений:*

CustomerKey	FullName	City
:---	:---	:---
101	Анна Петрова	Москва

Анна переезжает в Санкт-Петербург. При использовании SCD Тип 1 таблица будет обновлена:

*Таблица `DimCustomer` после изменений:*

CustomerKey	FullName	City
:---	:---	:---
101	Анна Петрова	Санкт-Петербург

Теперь невозможно узнать, что раньше Анна жила в Москве.

---

Тип 2: Добавление новой строки (Add New Row)

Это самый распространенный и мощный тип SCD, так как он позволяет сохранять полную историю изменений.

Как работает:** Вместо перезаписи существующей записи, создается новая запись для той же сущности (например, того же клиента). Старая запись помечается как неактуальная (истекшая), а новая — как актуальная. Для этого в таблицу измерения обычно добавляют несколько служебных столбцов learn.microsoft.com:
- `StartDate` / `EffectiveDate` — дата, с которой запись стала актуальной.
- `EndDate` — дата, когда запись перестала быть актуальной.
- `IsCurrent` / `CurrentFlag` — флаг (например, ‘Yes’/’No’ или 1/0), показывающий, является ли эта запись текущей.
Когда использовать:** Когда сохранение истории критически важно для анализа. Это стандартный выбор для большинства атрибутов в хранилищах данных.
Преимущества:** Сохраняется полная, точная история. Позволяет проводить корректный point-in-time анализ (анализ на определенный момент времени).
Недостатки:** Увеличивается объем таблицы, так как для одного клиента может быть несколько записей. Запросы могут стать сложнее (нужно фильтровать по флагу `IsCurrent` или по диапазону дат) hevodata.com.

Пример:
Снова используем пример с Анной Петровой.

*Таблица `DimCustomer` до изменений:*

SurrogateKey	CustomerID	FullName	City	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Анна Петрова	Москва	2020-01-15	NULL	Yes

Анна переезжает 16 августа 2024 года. При использовании SCD Тип 2 таблица изменится так:

*Таблица `DimCustomer` после изменений:*

SurrogateKey	CustomerID	FullName	City	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Анна Петрова	Москва	2020-01-15	2024-08-15	No
2	101	Анна Петрова	Санкт-Петербург	2024-08-16	NULL	Yes

Теперь мы сохранили всю историю перемещений Анны.

---

Тип 3: Добавление нового атрибута (Add New Attribute)

Этот тип сохраняет ограниченную историю, добавляя в таблицу отдельный столбец для предыдущего значения атрибута.

Как работает:** Создается новый столбец, например, `PreviousCity`. Когда атрибут `City` меняется, его старое значение копируется в `PreviousCity`, а новое записывается в `City`.
Когда использовать:** Когда важно отслеживать только предыдущее состояние для сравнения, а более глубокая история не нужна.
Преимущества:** Простота реализации, не увеличивает количество строк, легко запрашивать текущее и предыдущее значения.
Недостатки:** Сохраняет историю только на один шаг назад. Не масштабируется, если нужно хранить более двух-трех последних значений.

Пример:
Анна переезжает из Москвы в Санкт-Петербург.

*Таблица `DimCustomer` до изменений:*

CustomerKey	FullName	CurrentCity	PreviousCity
:---	:---	:---	:---
101	Анна Петрова	Москва	NULL

*Таблица `DimCustomer` после изменений:*

CustomerKey	FullName	CurrentCity	PreviousCity
:---	:---	:---	:---
101	Анна Петрова	Санкт-Петербург	Москва

Если Анна переедет снова, значение “Москва” будет потеряно.

Другие типы SCD

Существуют и более сложные гибридные типы:

Тип 4 (History Table):** Основная таблица измерения хранит только текущие данные (как Тип 1), а вся история изменений выносится в отдельную таблицу. Это полезно, когда изменения происходят часто в очень больших таблицах измерений medium.com.
Тип 6 (Hybrid):** Комбинирует подходы Типов 1, 2 и 3. Например, в таблице хранятся поля для полной истории (SCD2) и одновременно поле для текущего значения (SCD1 для быстрого доступа) и предыдущего значения (SCD3 для сравнения).

Тип 4: Добавление исторической таблицы (History Table / Audit Table)

Идея: Разделить текущие данные и исторические данные в разные таблицы для оптимизации производительности.

Как работает:** Создаются две таблицы:
1. Таблица измерения (Dimension Table): Хранит *только* текущие, самые последние данные. Эта таблица по своей сути работает как SCD Тип 1 (данные просто перезаписываются). Она маленькая, быстрая и идеально подходит для большинства запросов, где история не нужна.
2. Историческая таблица (History Table): Хранит всю историю изменений. Каждый раз, когда в основной таблице происходит изменение, старая версия строки (до обновления) добавляется в историческую таблицу. Эта таблица часто содержит служебные поля, как в SCD Тип 2 (`StartDate`, `EndDate`, `Version`), для отслеживания временного периода.
Когда использовать:** Когда у вас есть очень большая таблица измерений (например, десятки миллионов клиентов), и большинство аналитических запросов относится только к текущим данным. Разделение таблиц позволяет сделать эти частые запросы очень быстрыми, не жертвуя при этом возможностью проводить глубокий исторический анализ при необходимости.
Преимущества:**
- Высокая производительность для запросов к текущим данным.
- Логическое разделение данных: актуальные и исторические.
Недостатки:**
- Усложнение ETL/ELT процесса, так как нужно управлять двумя таблицами.
- Анализ, требующий одновременного доступа к историческим и текущим данным, усложняется, так как требует `JOIN` или `UNION` между двумя таблицами.

Пример:
Клиент Анна Петрова переезжает из Москвы в Санкт-Петербург.

*Таблицы до изменений:*

`DimCustomer` (основная таблица)

CustomerID	FullName	City
:---	:---	:---
101	Анна Петрова	Москва

`HistoryCustomer` (историческая таблица) – *пустая*

*Процесс изменения:*

Перед обновлением основной таблицы, текущая строка (Анна в Москве) копируется в `HistoryCustomer`.
Затем основная таблица `DimCustomer` обновляется новым значением.

*Таблицы после изменений:*

`DimCustomer` (всегда хранит только актуальные данные)

CustomerID	FullName	City
:---	:---	:---
101	Анна Петрова	Санкт-Петербург

`HistoryCustomer` (накапливает историю)

HistoryID	CustomerID	FullName	City	StartDate	EndDate
:---	:---	:---	:---	:---	:---
1	101	Анна Петрова	Москва	2020-01-15	2024-08-15

Тип 5: Гибридный подход (Mini-Dimension + Type 1 Outrigger)

Идея: Вынести часто меняющиеся атрибуты из большой таблицы измерений в отдельную “мини-таблицу”, чтобы избежать “раздувания” основной таблицы.

Как работает:**
1. Из основной таблицы измерения (например, `DimCustomer`) выделяется группа атрибутов, которые часто меняются вместе (например, “Тарифный план”, “Статус подписки”).
2. Создается отдельная таблица — “мини-измерение” (например, `DimSubscriptionProfile`) — только для этих атрибутов. Эта мини-таблица управляется по SCD Тип 2 (добавление новой строки для каждого уникального набора значений).
3. В основной таблице `DimCustomer` эти атрибуты удаляются, и вместо них добавляется один внешний ключ (например, `SubscriptionProfileKey`), который ссылается на мини-измерение.
4. Этот ключ в основной таблице `DimCustomer` обновляется по принципу SCD Тип 1 (просто перезаписывается), указывая на *актуальную* запись в мини-измерении.
Когда использовать:** В очень больших (широких и/или с большим количеством строк) таблицах измерений, где лишь небольшая группа атрибутов меняется относительно часто. Это позволяет отслеживать историю этих атрибутов, не создавая новую многомиллионную запись в основной таблице при каждом изменении.
Преимущества:**
- Экономия места и контроль над ростом основной таблицы измерения.
- Позволяет вести детальную историю для подгруппы атрибутов.
Недостатки:**
- Более сложная модель данных, требующая дополнительных `JOIN`.
- Может быть сложнее для понимания конечными пользователями.

Пример:
Клиент Иван меняет свой тарифный план.

*Таблицы до изменений:*

`DimCustomer`

CustomerKey	FullName	SubscriptionProfileKey
:---	:---	:---
202	Иван Иванов	55

`DimSubscriptionProfile` (мини-измерение, управляется по SCD2)

ProfileKey	Plan	Status	IsCurrent
:---	:---	:---	:---
55	Basic	Active	Yes

*Процесс изменения:* Иван переходит на план “Premium”.

В `DimSubscriptionProfile` добавляется новая строка для “Premium”, а старая помечается как неактуальная.
В `DimCustomer` у Ивана обновляется ключ `SubscriptionProfileKey`.

*Таблицы после изменений:*

`DimCustomer` (здесь изменился только ключ)

CustomerKey	FullName	SubscriptionProfileKey
:---	:---	:---
202	Иван Иванов	56

`DimSubscriptionProfile` (здесь хранится вся история)

ProfileKey	Plan	Status	IsCurrent
:---	:---	:---	:---
55	Basic	Active	No
56	Premium	Active	Yes

Тип 6: Гибридный (Комбинация Типа 1, 2 и 3)

Идея: Обеспечить максимальную гибкость для анализа, объединив сильные стороны трех основных типов в одной таблице.

Как работает: Этот тип строится на основе **SCD Тип 2 (добавление новой строки для истории), но с добавлением атрибутов из SCD Тип 1 (перезапись) для упрощения некоторых запросов.
- Основная структура — это SCD Тип 2: есть строки для каждой исторической версии с полями `StartDate`, `EndDate` и `IsCurrent`. Поле атрибута (например, `City`) хранит значение, актуальное на тот исторический период.
- Дополнительно в таблицу добавляется столбец `CurrentCity`. Этот столбец для *всех* записей одного клиента (и исторических, и текущей) всегда хранит актуальное на данный момент значение (поведение SCD Тип 1).
Когда использовать:** Когда аналитикам часто нужно отвечать на два типа вопросов:
1. “Каким был город клиента на момент продажи?” (Используется историческое поле `City`).
2. “Каковы продажи всем клиентам, которые *сейчас* живут в Москве, за всю историю?” (Используется поле `CurrentCity` для фильтрации).
Преимущества:**
- Невероятная гибкость анализа без сложных `JOIN` или подзапросов для определения текущего состояния.
Недостатки:**
- Усложнение ETL/ELT. При изменении адреса нужно не только создать новую строку и закрыть старую, но и обновить поле `CurrentCity` во всех предыдущих строках для этого клиента. Это может быть ресурсозатратно.

Пример:
Снова Анна, переезжающая из Москвы в Санкт-Петербург.

*Таблица `DimCustomer` до изменений:*

SurrogateKey	CustomerID	City	CurrentCity	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Москва	Москва	2020-01-15	NULL	Yes

*Процесс изменения:*

Старая строка “закрывается” (обновляется `EndDate`, `IsCurrent` = ‘No’).
Создается новая актуальная строка.
Во всех строках для CustomerID=101 поле `CurrentCity` обновляется до “Санкт-Петербург”.

*Таблица `DimCustomer` после изменений:*

SurrogateKey	CustomerID	City	CurrentCity	StartDate	EndDate	IsCurrent
:---	:---	:---	:---	:---	:---	:---
1	101	Москва	Санкт-Петербург	2020-01-15	2024-08-15	No
2	101	Санкт-Петербург	Санкт-Петербург	2024-08-16	NULL	Yes

Теперь можно легко отфильтровать по `City` для исторического анализа или по `CurrentCity` для анализа в разрезе текущего состояния.

Ссылки для дальнейшего изучения

Microsoft Fabric:** Slowly changing dimension type 2 https://learn.microsoft.com/en-us/fabric/data-factory/slowly-changing-dimension-type-two — Хорошее описание и пример реализации SCD Тип 2.
DataCamp:** Mastering Slowly Changing Dimensions (SCD) https://www.datacamp.com/tutorial/mastering-slowly-changing-dimensions-scd — Комплексный учебник по основным типам SCD.
HevoData:** Slowly Changing Dimensions(SCD): Types with Examples https://hevodata.com/learn/slowly-changing-dimensions/ — Детальное объяснение всех основных типов с примерами.
ThoughtSpot:** Slowly Changing Dimensions (SCD): 4 Types & How to ...https://www.thoughtspot.com/data-trends/data-modeling/slowly-changing-dimensions-in-data-warehouse — Еще один ресурс с обзором и сравнением типов SCD.

Идея: Концептуальная архитектура: SCD на стеке Lakehouse + Data Mesh + dbt

Основная идея заключается в создании надежных, версионируемых и децентрализованных “продуктов данных”, одним из которых является таблица измерений с полной историей (SCD). (Автоматическая)

Вот как компоненты взаимодействуют друг с другом:

Lakehouse (Основа): Это наша физическая среда. Мы используем открытое озеро данных (например, S3, ADLS) для хранения, а поверх него — табличный формат Apache Iceberg. Iceberg предоставляет нам ACID-транзакции, эволюцию схемы и, что самое важное для SCD, атомарные и эффективные операции `MERGE` (`UPDATE`/`INSERT`/`DELETE`) на уровне строк прямо в озере данных.

Data Mesh (Философия организации): Вместо централизованной команды данных, мы принимаем философию Data Mesh. A “Команда домена Клиенты” несет полную ответственность за все данные, связанные с клиентами. Их задача — предоставить остальной компании высококачественный продукт данных под названием `dim_customers`. Этот продукт должен включать полную историю изменений (SCD Type 2).

ETL/ELT (Процесс): Это конвейер, по которому данные текут от источника к потребителю.
- Extract & Load: Исходные данные (например, изменения в базе данных клиентов) захватываются с помощью CDC (Change Data Capture) инструментов типа Debezium и попадают в **Kafka. Оттуда они загружаются (Load) в “бронзовый” слой нашего Lakehouse (в сыром виде, в таблицы Iceberg).
- Transform: Здесь в игру вступает **dbt. Команда домена использует `dbt` для преобразования сырых данных из бронзового слоя в готовую к использованию модель в “серебряном” слое — нашу таблицу `dim_customers`.

dbt (Инструмент автоматизации SCD): `dbt` является сердцем автоматизации. Он не просто выполняет SQL-скрипты. У него есть встроенный функционал для реализации SCD Type 2, который называется `Snapshots`.

---

Сценарий 1: Автоматическое формирование SCD с помощью `dbt snapshots`

Это наиболее распространенный, надежный и идиоматический способ реализации идеи.

Как это работает:

Источник: У нас есть “бронзовая” таблица `bronze_customers`, которая содержит текущее состояние всех клиентов. Эта таблица обновляется периодически (например, раз в час) новыми данными из Kafka.
dbt Snapshot: В проекте `dbt` команда домена создает файл “снэпшота” (`snapshot/customers_snapshot.sql`). Внутри него описывается, как `dbt` должен отслеживать изменения.

{% snapshot customers_snapshot %}

    {{
        config(
          target_schema='silver',
          unique_key='customer_id',
          strategy='check',
          check_cols=['address', 'email', 'phone_number'],
          updated_at='last_modified_at',
        )
    }}

    select * from {{ source('bronze', 'customers') }}

    {% endsnapshot %}

Автоматизация: Оркестратор (например, Airflow) запускает команду `dbt snapshot` по расписанию.
Что делает dbt “под капотом”:
- Он сравнивает записи из исходной таблицы (`bronze_customers`) с текущими записями в целевой таблице (`silver.customers_snapshot`).
- Используя `unique_key` (`customer_id`), он находит совпадающие записи.
- С помощью стратегии `check` он проверяет, изменилось ли значение в любом из столбцов, перечисленных в `check_cols`.
- Если изменение обнаружено:
  - Он обновляет старую запись в целевой таблице, проставляя ей дату окончания актуальности (`dbt_valid_to`).
  - Он вставляет новую строку с обновленными данными и датой начала актуальности (`dbt_valid_from`).
- `dbt` генерирует одну атомарную операцию `MERGE` для таблицы Iceberg, которая эффективно выполняет все эти обновления и вставки за одну транзакцию.

Результат: В `silver.customers_snapshot` мы получаем идеальную таблицу SCD Type 2, которая обновляется автоматически и надежно, без написания сложной логики `MERGE` вручную.