Часть 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-запрос
Прочитай specs/models и models/marts.
Для каждой витрины определи grain, основные проверочные факты, политику PII и влияние
на контракт. Найди витрины, где grain не доказан тестом или ручным фактом ревьюера.
Файлы не меняй.
Минимальный выход
Составьте реестр gold-слоя:
# Реестр 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 — это не папка. Это обещание потребителю, закреплённое спецификацией, контрактом и проверкой.
Контрольные вопросы
- Почему grain является частью публичного контракта?
- Какие тесты нужны для mart уровня клиента?
- Когда nullable-поле всё равно может быть ломающим изменением?