# Часть 14. Silver layer: клиенты, счета, карты, платежи

Silver layer создаёт устойчивые промежуточные сущности. Это не финальные
витрины для потребителей, но уже не сырые источники. Silver должен быть
переиспользуемым: Customer 360, витрина риска и кредитная витрина могут читать одни и те
же промежуточные модели без копирования логики.

## Что входит в silver

В учебном примере silver представлен intermediate-моделями:

- `int_customer_balances`;
- `int_customer_card_activity`.

Они агрегируют счета и карточные операции до сигналов уровня клиента, которые
потом использует `mart_customer_360`.

## Правила silver

- не раскрывать прямые PII дальше, чем нужно;
- сохранять понятный grain;
- не смешивать несвязанные домены;
- не принимать продуктовые решения, если модель переиспользуемая;
- использовать `ref()`, чтобы lineage читался в dbt.

Если `int_customer_card_activity` считает `risk_event_count_7d`, спецификация должна
объяснять, что такое 7 дней и откуда берётся риск-флаг. Если этого нет, модель
похожа на SQL, но не на устойчивый дата-актив.

## Приёмочные факты

Для silver:

- входные модели читаются только через `ref()`;
- модели уровня клиента имеют одну строку на `customer_id`;
- суммы не становятся null без объяснения;
- риск-счётчики имеют понятное окно;
- PII не утекает в переиспользуемый слой без политики.

## Qwen-запрос

```text
Сравни intermediate-модели со спецификациями и требованиями mart.
Покажи grain каждой intermediate-модели, входные `ref()`, переиспользуемые поля
и разрывы проверки.
Файлы не меняй.
```

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

Составьте таблицу:

| Модель | Гранулярность | Входы | Используется в | Разрыв проверки |
|---|---|---|---|---|
| int_customer_balances | customer_id | stg_accounts | mart_customer_360 | |
| int_customer_card_activity | customer_id | stg_card_transactions | mart_customer_360 | |

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

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

Silver layer часто становится местом, где проект либо взрослеет, либо начинает
тонуть в случайных преобразованиях. Здесь источники уже приведены к понятным
типам, но ещё не стали продуктами. Значит, возникает соблазн «немного
улучшить» данные: соединить клиентов со счетами, убрать странные строки,
переименовать риск, посчитать удобный признак. Если эти решения не записаны,
silver превращается в скрытый бизнес-слой.

Хороший silver строит устойчивые сущности: клиент, счёт, операция, кредит,
согласия. Он устраняет техническую грязь, но не присваивает себе право менять
обещание продукта. Например, можно привести `customer_id` к единому имени и
подготовить балансы для дальнейшей агрегации. Нельзя без спецификации решить,
что клиент активен только при положительном остатке, если это влияет на
потребителей.

Silver полезен ещё и как слой повторного использования. Если каждая gold-витрина
сама чистит клиентов и счета, расхождения появятся неизбежно. Одна витрина
иначе обработает null, другая иначе отфильтрует закрытые счета, третья иначе
посчитает просрочку. Общий silver-слой делает эти решения видимыми и снижает
дублирование, но только если сам остаётся понятным и проверяемым.

Читателю важно не измерять silver количеством моделей. Иногда одна аккуратная
intermediate-модель лучше трёх слоёв с красивыми именами. Критерий простой:
помогает ли слой выразить повторяемую сущность и доказать её качество? Если
ответ нет, модель, вероятно, создана ради архитектурной симметрии, а не ради
читателя или потребителя данных.

## Практика

Постройте таблицу grain / входы / используется в для двух intermediate-моделей примера.
Если модель имеет больше одного назначения, разделите назначения словами до
изменения SQL.

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

Превращать silver в «свалку удобных CTE». Если модель нельзя описать одним
grain и одним назначением, она слишком широкая.

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

1. Почему silver не должен быть привязан к одному продукту?
2. Какие поля из staging нельзя переносить дальше без политики?
3. Как `ref()` помогает ревьюеру?