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

Урок 1 из 5 в модуле «Часть 22. Практический зачёт»

Вы просматриваете урок без входа. Войдите, чтобы сохранять прогресс и проходить тесты.

Источник

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

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

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

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

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

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

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

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

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

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

Что является источником истины для grain?
Чем ODPS отличается от ODCS?
Почему dbt-тесты не заменяют контракт данных?
Где должен быть описан список запрещённых PII?
Что такое дрейф контракта?
Когда добавление nullable-колонки может быть ломающим изменением?
Почему автор и ревьюер должны быть разными ролями?
Что доказывает dbt build, а чего он не доказывает?
Чем Schema Manifest отличается от спецификации модели?
Почему raw-данные не нужно «чинить» ради зелёного dbt build?
Что должен содержать проверочный факт?

Когда требуется подтверждение человеком?

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

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

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

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

## Данные

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

## Проверка

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

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

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

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

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

# Спецификация модели: 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-тесты;
иметь спецификацию модели и проверочные факты;
иметь заметку о влиянии на контракт и отчёт ревьюера.

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

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

Если ревьюер находит дрейф, исправьте спецификацию или SQL до релиза.

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

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

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

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

Спецификация модели или контракт дата-продукта, не SQL.
ODPS описывает продукт и потребителей; ODCS — технический контракт.
dbt-тесты проверяют часть формы/данных, но не весь продуктовый смысл.
В спецификации, AGENTS.md, чек-листе ревьюера и, по возможности, singular-тесте.
Расхождение между контрактом/спецификацией и фактической моделью.
Если она выглядит как новая бизнес-метрика, меняет grain или API ниже по цепочке.
Ревьюер должен проверять догадки автора, а не защищать их.
dbt build доказывает исполнимость DAG/тестов, но не полноту спецификации.
Манифест описывает наблюдаемый источник; спецификация модели описывает обещанную

витрину.

Raw сохраняет вход; семантика пустых значений и null решается в staging/спецификации.
Команду, SQL или ручной шаг ревьюера, ожидание и статус.
При изменении grain, политики PII, SLA, полей контракта или методологии риска.

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

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

Автор:

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

Ревьюер:

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

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

После зачёта

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

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

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

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