Часть 3. Обзор процесса DataLakeHouse

SDD Data использует тот же принцип, что и базовый SDD: сначала намерение и проверяемые факты, затем реализация. Отличие в том, что артефактов больше. В обычной фиче достаточно requirements.md, plan.md, validation.md. В дата-проекте появляются профиль источника, Schema Manifest, ODCS/ODPS, спецификация модели, dbt-тесты, lineage и отчёт ревьюера.

Основной поток

миссия -> профилирование источников -> Schema Manifest -> спецификация дата-продукта
-> контракт -> dbt-модель -> проверочные факты -> отчёт ревьюера

Этот поток не обязан быть тяжёлым. Для учебного примера каждый артефакт короткий, но он отвечает на отдельный вопрос:

• миссия: зачем существует платформа;
• профилирование источников: что реально пришло;
• Schema Manifest: какие поля наблюдаем и что ещё неизвестно;
• спецификация дата-продукта: что обещаем потребителю;
• контракт: какие поля, SLA и качество обязаны сохраняться;
• dbt-модель: как строим результат;
• проверочные факты: чем доказываем готовность;
• отчёт ревьюера: кто проверил изменение и где остаётся риск.

Роли агента и человека

Агент хорошо делает механическую работу: читает CSV, предлагает манифест, пишет SQL, находит расхождения между спецификацией и моделью. Человек отвечает за смысл: grain, политика PII, бизнес-владелец, ломающие изменения, утверждение релиза. Если агент сам решил, что customer_id можно заменить на account_id, процесс уже сорвался.

Разделяйте роли:

• профилировщик читает источники и возвращает факты;
• сборщик пишет модели по утверждённым спецификациям;
• ревьюер сравнивает изменение с контрактами и проверочными фактами.

Даже если все роли выполняет один инструмент, запускайте их разными сессиями после /clear. Так проверяется, достаточно ли контекст записан в файлах.

Минимальная структура репозитория

specs/
  mission.md
  tech-stack.md
  roadmap.md
  customer_360_product.odps.yaml
  customer_360_contract.odcs.yaml
  models/
    mart_customer_360.md
  validation/
    customer_360.md
models/
  staging/
  intermediate/
  marts/
tests/

Если важное решение живёт только в чате, следующий агент его потеряет. Если оно лежит в спецификации, ревьюер может проверить его независимо.

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

Главная опасность процесса DataLakeHouse в том, что он похож на линейную лестницу: источник, манифест, контракт, модель, проверка, ревью. В реальности это не лестница, а система с обратной связью. Профилирование источника может показать пустые даты. Контракт может обнаружить, что продукт обещан слишком широко. Ревью может вернуть автора к grain. SDD не запрещает возвращаться назад; он делает возврат видимым.

Каждый артефакт в этой главе отвечает на свой вопрос. Манифест отвечает: «что мы увидели?» Контракт отвечает: «что мы обещаем?» Модель отвечает: «как мы это строим?» Проверка отвечает: «чем доказываем?» Отчёт ревьюера отвечает: «кто смотрел на связку целиком?» Если объединить эти ответы в один большой документ, читателю сначала станет проще, а потом сложнее: источник, обещание и проверка начнут незаметно подменять друг друга.

Разделение ролей нужно по той же причине. Автор модели естественно защищает своё решение. Даже если автор — агент, он уже шёл по выбранному пути и склонен объяснять его как правильный. Ревьюер в режиме только чтения смотрит иначе: он не пытается спасать реализацию, а проверяет, удерживает ли она обещание. После

/clear эта проверка становится честнее, потому что ревьюер не помнит разговор, где автор мог объяснить незаписанные решения.

На практике эта глава должна научить читателя видеть пустые места. Если существует SQL, но нет validation.md, это не «почти готово». Если есть ODCS, но нет проверки обязательных полей, это не контракт, а декларация. Если есть отчёт ревьюера без ссылок на спецификации, это мнение, а не доказательство. SDD Data работает только тогда, когда пробелы видны раньше, чем ошибка попала в витрину.

Практика

Нарисуйте карту артефактов для mart_customer_360: какие файлы отвечают за факты источника, продуктовое обещание, контракт, реализацию, validation.md и ревью. Отдельно отметьте пробелы, где файл ещё не создан или не связан с проверкой.

Qwen-запрос для обзора

Прочитай AGENTS.md, specs/mission.md, specs/tech-stack.md и specs/roadmap.md.
Построй карту артефактов DataLakeHouse: какие файлы отвечают за факты источника,
продуктовое обещание, контракт, dbt-реализацию и проверку.
Файлы не меняй.

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

Создайте workflow-map.md или рабочую заметку:

Факты источника:
Продуктовое обещание:
Контракт:
Реализация:
Проверка:

Ревью:

Для каждого пункта укажите файл или отметьте пробел. Пробел лучше увидеть сейчас, чем после того, как SQL уже написан.

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

Делать одну команду /sdd:do-everything. Она удобна в демонстрации, но разрушает контроль человека. В банковских данных опасно, когда один агент сам профилирует источник, сам решает grain, сам пишет SQL и сам подтверждает готовность.

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

1. Чем Schema Manifest отличается от спецификации дата-продукта?
2. Почему сборщик и ревьюер должны быть отдельными ролями?
3. Как /clear помогает проверить, что процесс записан в файлах?