Часть 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-запрос

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

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

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

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

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

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

silver превращается в скрытый бизнес-слой.

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

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

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

Практика

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

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

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

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

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