Часть 7. Спецификация первого дата-продукта

Первый дата-продукт книги — customer_360. Он должен дать аналитикам клиентский срез без прямого PII. На этом шаге важно не писать SQL. Сначала нужно сформулировать обещание продукта: кто потребитель, какой выходной порт, какой grain, какие поля обязательны, какая freshness и какие проверки докажут готовность.

Артефакты

specs/customer_360_product.odps.yaml
specs/customer_360_contract.odcs.yaml
specs/models/mart_customer_360.md
specs/validation/customer_360.md

ODPS описывает продукт. ODCS описывает технический контракт. Спецификация модели описывает grain и приёмочные факты. Заметка о проверке связывает спецификацию с командами и проверками ревьюера.

Grain

Для mart_customer_360 grain простой:

одна строка на `customer_id`

Если добавить account_id, product_code или scope, это уже другая витрина. Такое изменение требует подтверждения, потому что потребитель ниже по цепочке иначе получит другую единицу строки.

Политика PII

Staging может читать pii_email, чтобы показать риск. Mart не должен его раскрывать. Правило должно быть проверяемым:

models/marts/mart_customer_360.sql не содержит прямые PII-поля.
singular-тест dbt assert_customer_360_no_direct_pii возвращает 0 строк.

SLA и freshness

В учебном примере freshness — 24 часа. Локально мы не строим планировщик, поэтому freshness остаётся продуктовым обещанием и заметкой к релизу. В боевом контуре её нужно поддержать метаданными загрузки, source freshness или оркестратором.

Запрос для Qwen Code

Прочитай specs/customer_360_product.odps.yaml,
specs/customer_360_contract.odcs.yaml и specs/models/mart_customer_360.md.
Сформулируй grain, политику PII, SLA, обязательные поля и приёмочные факты.
Не меняй файлы.

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

После главы должна быть таблица:

Эта таблица станет ориентиром для частей 10–16.

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

Спецификация дата-продукта — это место, где техническая таблица впервые

становится обещанием. До неё mart_customer_360 выглядит как имя модели. После неё это уже договор с потребителем: кому нужна витрина, что означает строка, какие поля обязательны, какие поля запрещены, какой возраст данных допустим. Если этот договор не записан, SQL начинает играть роль продукта, хотя SQL показывает только способ вычисления.

ODPS и ODCS разделяют два разных разговора. ODPS говорит о продукте: кто потребитель, зачем витрина существует, какой результат она обещает. ODCS говорит о техническом контракте: какие поля, типы, SLA и правила изменения должны сохраняться. Когда эти слои смешиваются, ревью становится мутным. Нельзя понять, сломался ли продуктовый смысл или только техническая форма.

Grain стоит писать до SQL, потому что после SQL автор уже видит конкретный join, конкретную группировку и конкретный удобный набор колонок. На этом этапе легко оправдать лишнюю детализацию: «она пригодится», «она не мешает», «так проще проверить». Но для потребителя это может быть другой продукт. Одна строка на клиента и одна строка на клиента-продукт — разные обещания, даже если обе таблицы называются Customer 360.

Хорошая спецификация не пытается описать всё будущее. Она фиксирует минимум, который нужен для первой версии: потребитель, grain, политика PII, обязательные поля, SLA и факты приёмки. Этого достаточно, чтобы агент мог реализовать витрину и чтобы ревьюер мог её отклонить. Если ревьюер не может назвать причину отказа, значит спецификация слишком расплывчата.

Практика

Сравните ODPS, ODCS и спецификацию модели для Customer 360. Найдите по одному полю, которое относится к продукту, техническому контракту и приёмке на уровне модели. Если поле встречается в неправильном слое, запишите почему это риск.

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

Записывать «customer 360» как общий лозунг. Для агента это слишком широко. Нужно явно указать, какие источники входят, какой grain, какие поля запрещены и что считается готовностью.

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

1. Чем ODPS отличается от ODCS?
2. Почему grain нужно писать до SQL?
3. Как проверить, что mart не раскрывает PII?