# Часть 22. Практический зачёт

Финальная задача — провести изменение через полный SDD Data-цикл. Это не тест
на знание dbt-синтаксиса. Это проверка, можете ли вы удержать обещание
дата-продукта от спецификации до отчёта ревьюера.

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

Практический зачёт нужен не для проверки памяти. Его задача — заставить
студента пройти весь цикл без подсказок автора учебника. Если человек может
написать SQL, но не может объяснить grain, политику PII, влияние на контракт и
проверочные факты, он пока не освоил SDD Data. В реальной работе именно эти
пропуски превращают аккуратные модели в рискованные витрины.

Зачёт специально начинается с плохой спецификации. Это важнее, чем сразу дать
задачу на реализацию. Хороший дата-инженер должен уметь остановить слабое
задание до SQL. Если спецификация говорит «сделать полезную витрину», нельзя
начинать моделирование. Нужно спросить о потребителе, grain, входах,
обязательных полях, PII, влиянии на существующие контракты и критериях
приёмки.

Парный формат показывает ещё одну мысль тома: ревью — это активная инженерная
роль. Ревьюер не просто ищет опечатки в SQL. Он проверяет, что автор не
подменил обещание удобной реализацией, не ослабил проверку после провала, не
спрятал ломающие изменения в «маленьком улучшении». Поэтому хороший зачёт
должен включать не только модель и тесты, но и отчёт ревьюера.

Ретроспектива в конце нужна для честности. Если после SQL пришлось уточнить
много пунктов, это не провал студента, а сигнал, что следующую фазу нужно
сузить или подробнее специфицировать. SDD Data не обещает, что все вопросы
закроются заранее. Он требует, чтобы вопросы не исчезали бесследно и чтобы
каждое уточнение возвращалось в файлы проекта.

## Блок 1. Быстрые вопросы

Ответьте письменно, без Qwen Code.

1. Что является источником истины для grain?
2. Чем ODPS отличается от ODCS?
3. Почему dbt-тесты не заменяют контракт данных?
4. Где должен быть описан список запрещённых PII?
5. Что такое дрейф контракта?
6. Когда добавление nullable-колонки может быть ломающим изменением?
7. Почему автор и ревьюер должны быть разными ролями?
8. Что доказывает `dbt build`, а чего он не доказывает?
9. Чем Schema Manifest отличается от спецификации модели?
10. Почему raw-данные не нужно «чинить» ради зелёного `dbt build`?
11. Что должен содержать проверочный факт?
12. Когда требуется подтверждение человеком?

## Блок 2. Найдите проблемы в спецификации данных

Дана спецификация:

```markdown
# Сводка риска клиента

Сделать полезную витрину риска клиентов.

## Данные

Использовать customer_360 и платежи. Добавить нужные поля риска.

## Проверка

Проверить, что данные корректные и нет персональных данных.
```

Найдите минимум 10 проблем. Хороший ответ заметит:

- не указано имя витрины;
- не указан потребитель;
- не указана гранулярность (grain);
- «полезную» непроверяемо;
- «нужные поля» не определены;
- нет обязательных показателей;
- политика PII не превращена в тест по списку запрещённых полей;
- не описано влияние на контракт;
- нет списка входных моделей;
- нет dbt-команд;
- нет ручных фактов для ревьюера;
- не сказано, является ли это новым продуктом или расширением.

## Блок 3. Перепишите спецификацию

Перепишите спецификацию в SDD Data-формате:

```markdown
# Спецификация модели: mart_customer_risk_summary

## Назначение
## Потребитель
## Grain
## Входы
## Выходные поля
## Политика PII
## Влияние на контракт
## Приёмочные факты
## Открытые подтверждения
```

Ограничения:

- grain: одна строка на `customer_id`;
- входы: `mart_customer_360`, `mart_payment_risk_signals`;
- поля: `customer_id`, `risk_event_count`, `large_amount_event_count`,
  `last_risk_event_date`;
- без прямых PII;
- проверки: `customer_id` not_null/unique, риск-счётчики not_null;
- существующий контракт `mart_customer_360` не менять.

## Блок 4. Итоговый проект

Добавьте новую витрину `mart_customer_risk_summary`.

Она должна:

- иметь grain «одна строка на `customer_id`»;
- использовать `mart_customer_360` и `mart_payment_risk_signals`;
- считать `risk_event_count`, `large_amount_event_count`, `last_risk_event_date`;
- не раскрывать прямой PII;
- иметь dbt-тесты;
- иметь спецификацию модели и проверочные факты;
- иметь заметку о влиянии на контракт и отчёт ревьюера.

## Требования к процессу

1. Начните с понятного рабочего дерева.
2. Создайте спецификацию в `specs/models/mart_customer_risk_summary.md`.
3. До SQL напишите проверочные факты.
4. Опишите влияние на контракт: новый дата-продукт или расширение.
5. Реализуйте dbt-модель.
6. Обновите `models/schema.yml`.
7. Запустите `dbt build --profiles-dir .`, если dbt установлен.
8. Подготовьте отчёт ревьюера.
9. Запишите, меняет ли витрина существующие контракты.
10. Если ревьюер находит дрейф, исправьте спецификацию или SQL до релиза.

## Рекомендуемый Qwen-сценарий

Создание спецификации:

```text
/clear
Прочитай AGENTS.md, specs и текущие marts.
Помоги создать спецификацию для mart_customer_risk_summary.
Код пока не пиши. Сначала задай вопросы по grain, политике PII, обязательным полям и
проверочные факты.
```

Реализация:

```text
/clear
Реализуй только mart_customer_risk_summary по утверждённой спецификации.
После изменения перечисли файлы и проверки.
Не меняй существующие контракты без подтверждения.
```

Ревью:

```text
/clear
Используй data-contract-review.
Проверь изменение против спецификации, политики PII, тестов, проверочных фактов и
влияние на контракт. Файлы не меняй.
```

## Рубрика на 25 баллов

| Раздел | Баллы | Критерии |
|---|---:|---|
| Спецификация до SQL | 5 | спецификация и проверочные факты появились до SQL |
| Grain | 5 | «одна строка на `customer_id`» доказана тестами |
| PII/контракт | 5 | нет прямых PII, влияние на контракт описано |
| dbt-проверки | 5 | `dbt build` проходит, тесты покрывают обязательные факты |
| Ревью | 5 | отчёт ревьюера отделяет факты, допущения и подтверждения |

21+ балл — процесс можно переносить на реальный дата-продукт.
16–20 — результат полезен для обучения, но проверку и ревью нужно усилить.
Ниже 16 — фаза слишком большая или спецификации не удерживают смысл.

## Ответы на быстрые вопросы

1. Спецификация модели или контракт дата-продукта, не SQL.
2. ODPS описывает продукт и потребителей; ODCS — технический контракт.
3. dbt-тесты проверяют часть формы/данных, но не весь продуктовый смысл.
4. В спецификации, `AGENTS.md`, чек-листе ревьюера и, по возможности, singular-тесте.
5. Расхождение между контрактом/спецификацией и фактической моделью.
6. Если она выглядит как новая бизнес-метрика, меняет grain или API ниже по цепочке.
7. Ревьюер должен проверять догадки автора, а не защищать их.
8. `dbt build` доказывает исполнимость DAG/тестов, но не полноту спецификации.
9. Манифест описывает наблюдаемый источник; спецификация модели описывает обещанную
   витрину.
10. Raw сохраняет вход; семантика пустых значений и `null` решается в staging/спецификации.
11. Команду, SQL или ручной шаг ревьюера, ожидание и статус.
12. При изменении grain, политики PII, SLA, полей контракта или методологии риска.

## Парный вариант зачёта

Один студент — автор, второй — ревьюер.

Автор:

- пишет спецификацию;
- пишет проверочные факты до SQL;
- реализует dbt-модель;
- запускает проверки;
- готовит пакет доказательств.

Ревьюер:

- читает спецификацию до реализации;
- проверяет изменение против спецификации;
- запускает или перепроверяет dbt-команды;
- отделяет замечания к контракту, SQL, тестам и процессу;
- не редактирует файлы автора.

После первой витрины роли меняются. Это снимает иллюзию, что ревью — пассивное
чтение SQL.

## После зачёта

Напишите короткую ретроспективу:

```markdown
# Ретроспектива SDD Data

## Что спецификация описала хорошо
## Что пришлось уточнить после SQL
## Какие проверки поймали ошибку
## Где Qwen Code пытался угадать смысл
## Что усилить перед переносом в боевой контур
```

Если в разделе «что пришлось уточнить после SQL» больше трёх пунктов, следующую
фичу надо уменьшить или подробнее описать до реализации.