# Часть 15. Gold layer: бизнес-сущности и grain Gold layer — это слой дата-продуктов. Здесь потребитель ниже по цепочке видит устойчивые витрины, а не промежуточные вычисления. Поэтому gold начинается с grain и контракта, а не с удобного `select`. ## Что делает gold-модель готовой Gold-модель готова, если: - у неё есть явно названный потребитель; - grain записан и проверен; - обязательные поля связаны с контрактом; - политика PII применена; - проверочные факты покрывают ключевые риски; - отчёт ревьюера отделяет факты от предположений. Для `mart_customer_360` потребитель — аналитика клиентов и портфеля. Для `mart_payment_risk_signals` потребитель — мониторинг риск-сигналов. Для `mart_open_api_consents` — контроль состояния согласий. Эти потребители не должны получать одинаковый grain случайно. ## Grain как защита Grain отвечает на вопрос «что означает одна строка». Если ответ меняется, это не косметика. Это изменение API данных. Примеры: - одна строка на `customer_id`; - одна строка на `transaction_id`; - одна строка на `scope`; - одна строка на день и канал. Если mart называется `customer_360`, но содержит несколько строк на клиента, название обманывает потребителя. ## Gold приёмочные факты - первичный ключ grain проходит `not_null`; - первичный ключ grain проходит `unique`, если grain предполагает одну строку на ключ; - обязательные показатели проходят `not_null`; - нет прямых PII; - поля контракта присутствуют; - lineage читается через граф dbt или заметку ревьюера. ## Qwen-запрос ```text Прочитай specs/models и models/marts. Для каждой витрины определи grain, основные проверочные факты, политику PII и влияние на контракт. Найди витрины, где grain не доказан тестом или ручным фактом ревьюера. Файлы не меняй. ``` ## Минимальный выход Составьте реестр gold-слоя: ```markdown # Реестр gold-слоя ## mart_customer_360 Потребитель: Гранулярность: Обязательные поля: Политика PII: Проверочные факты: ``` ## Разбор для читателя Gold layer — это момент, где инженерная работа становится публичным обещанием. До него можно говорить о промежуточных сущностях, нормализации и подготовке. В gold-слое появляется потребитель: аналитик, риск-команда, отчётность, мониторинг согласий. Поэтому любая неясность здесь стоит дороже. Если grain не записан, потребитель сам его додумает. Если политика PII не проверена, лишняя колонка может попасть в отчёт. Если обязательные показатели не покрыты тестами, витрина выглядит готовой только внешне. Gold-модель должна быть узкой. Это звучит странно, потому что хочется сделать витрину «богаче»: добавить продукт, канал, сегмент, последнюю операцию, флаг риска, кредитный stage. Но каждое расширение меняет вопрос, на который отвечает таблица. Customer 360 может быть клиентским срезом, а может незаметно стать клиентско-продуктовой витриной. Название останется прежним, а смысл уже нет. Именно поэтому публичное обещание полезно писать одной строкой. Если эту строку невозможно сформулировать без запятых и исключений, gold-модель слишком широка. «Одна строка на клиента для аналитики портфеля без прямых PII» — хорошая рамка. «Полезная витрина клиентов со счетами, платежами, рисками и всем, что может понадобиться» — приглашение к дрейфу. Ревью gold-слоя должно быть строже ревью staging. В staging можно обсуждать техническую нормализацию. В gold нужно спрашивать о потребителе, контракте, SLA, PII, grain и доказательствах. Если ревьюер не может понять, кому обещана витрина и как она будет использоваться, модель ещё не gold, даже если лежит в `models/marts/`. ## Практика Для каждой витрины из README запишите одно публичное обещание в одну строку. Если обещание не содержит потребителя и grain, витрина ещё не готова считаться gold дата-продуктом. ## Типичная ошибка Называть любую таблицу в `models/marts/` gold layer. Gold — это не папка. Это обещание потребителю, закреплённое спецификацией, контрактом и проверкой. ## Контрольные вопросы 1. Почему grain является частью публичного контракта? 2. Какие тесты нужны для mart уровня клиента? 3. Когда nullable-поле всё равно может быть ломающим изменением?