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

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

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

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

Пример:

```sql
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-запрос

```text
Прочитай 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?