Часть 10. Staging-модели dbt

Staging превращает raw-факты в устойчивые технические модели. Это не место для сложной бизнес-логики, но место для понятных типов, именования, первичных ключей и минимальной нормализации. Хороший staging делает SQL ниже по цепочке скучным и предсказуемым.

Что разрешено в staging

• привести имена полей к соглашению проекта;
• привести типы (date, integer, decimal);
• явно обработать семантику пустых значений и null;
• сохранить ключи источника;
• пометить PII-поля, но не скрывать их без причины.

Пример:

try_cast(nullif(cast(revoked_at as varchar), '') as date) as revoked_at

Эта строка не решает продуктовый вопрос сама по себе. Она технически превращает пустое значение в null, а смысл «null в revoked_at = активное согласие» должен быть отражён в спецификации и mart.

Что запрещено в staging

• агрегировать клиентов;
• считать риск-скор;
• выбирать финальный grain витрины;
• удалять строки «для красоты»;
• скрывать дрейф контракта.

Если staging начинает отвечать на вопросы потребителя, слой стал слишком умным.

dbt-тесты

Минимум:

• not_null и unique для ключей источника;

• not_null для обязательных сумм и дат;
• accepted_values там, где домен мал;
• singular-тесты для сложных ограничений.

Тесты в staging должны ловить технические проблемы источника, но не заменять проверку дата-продукта.

Разбор для читателя

Staging — первый слой, где данные начинают говорить на языке платформы. Здесь появляются устойчивые имена колонок, явные типы, понятная обработка пустых значений, базовые ключи. Но staging не должен становиться маленькой бизнес-витриной. Его задача — сделать источник пригодным для дальнейшей работы, не присваивая себе решения, которые принадлежат продуктовой спецификации.

Хорошая staging-модель скучна: выбрать поля, привести типы, явно обработать пустые значения и null, сохранить синтетические идентификаторы, не менять grain. Скука здесь полезна. Если в staging появляется сложная агрегация, фильтр «только активные», классификация риска или расчёт бизнес-метрики, ревьюер должен спросить, почему это решение принято до спецификации модели.

Обработка пустых значений — хороший учебный пример. Пустой revoked_at может сломать приведение типа. Можно быстро заменить его на null и забыть. Но SDD-подход требует

больше: записать, что пустое значение встречается в raw; объяснить, почему в staging оно становится null; проверить, что mart считает активные и отозванные согласия согласованно. Тогда техническое исправление превращается в документированное решение.

Staging также задаёт стиль SQL для агента. Модели должны быть небольшими, читаться сверху вниз и использовать ref()/source() там, где это уместно. Если staging трудно прочитать, модели ниже по цепочке станут ещё хуже. Если staging понятен, ревьюер может быстро отделить техническую нормализацию от продуктового смысла.

Практика

Выберите одну staging-модель и подпишите каждое преобразование: переименование, приведение типа, обработка null или бизнес-логика. Если нашли бизнес-логику, проверьте, есть ли на неё спецификация.

Qwen-запрос

Прочитай Schema Manifest и raw-источники.
Создай или проверь staging-модели.
Не добавляй бизнес-агрегации. Для каждого приведения типа объясни факт источника, на котором
он основан.

Минимальный выход

После главы:

• есть staging-модели для основных источников;
• ключи покрыты dbt-тестами;
• решения по пустым значениям и null записаны;

• PII остаётся видимым только там, где это нужно для демонстрации политики.

Типичная ошибка

Прятать бизнес-логику в staging. Например, `case when amount_rub > 100000 then 1 else 0 end as risk_event` допустим только если правило уже записано в спецификации или манифесте источника. Иначе агент придумывает риск-политику.

Контрольные вопросы

1. Какие решения staging может принимать без утверждения?
2. Почему PII иногда остаётся в staging?
3. Чем staging-тест отличается от проверочного факта mart?