Материал: Часть 1. Введение: SDD для данных

Урок 1 из 5 в модуле «Часть 1. Введение: SDD для данных»

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

Источник

Часть 1. Введение: SDD для данных

В первом томе SDD применялся к веб-приложению: миссия, стек, дорожная карта, спецификация фичи, план, проверка и реализация. В дата-платформе та же логика сохраняется, но главный риск меняется. В приложении агент может ошибиться в маршруте или UI. В данных агент может незаметно изменить смысл метрики, grain витрины, freshness, политику персональных данных или совместимость с потребителями ниже по цепочке.

Поэтому SDD Data начинается не с SQL. Он начинается с вопроса: какое обещание даёт дата-продукт потребителю?

Что вы построите

Учебный проект — DataLakeHouse вымышленного банка Банк Северный Мост. К концу книги у вас будет локальный dbt-проект, который строит финальные витрины:

mart_customer_360;
mart_card_turnover_daily;
mart_payment_risk_signals;
mart_credit_portfolio_quality;
mart_open_api_consents.

Все данные синтетические. Российский банковский контекст используется как набор ограничений: персональные данные, платежи, согласия, риск-сигналы, регуляторная отчётность. Это учебная архитектура, а не юридическая инструкция.

Чем SDD Data отличается от обычного dbt-курса

Обычный dbt-курс часто начинается с select * from source. Здесь порядок другой:

Сначала миссия платформы.
Затем спецификация продукта и контракт.
Затем raw/staging.
Затем marts.
Затем проверочные факты и отчёт ревьюера.

dbt остаётся основным инструментом трансформаций, но не становится источником смысла. Смысл живёт в спецификациях. SQL должен исполнять зафиксированное обещание, а не создавать его постфактум.

Краткое повторение SDD

SDD — это цикл, в котором агент не начинает с реализации. Сначала человек и агент фиксируют намерение, границы, решения и факты проверки. Затем агент пишет код или SQL по утверждённым файлам. После реализации отдельное ревью проверяет не только «прошли ли тесты», но и совпадает ли результат со спецификацией.

Для данных этот цикл выглядит так:

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

Три правила нужно помнить с первой главы:

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

автор и ревьюер должны работать в разных режимах, даже если это один и

тот же CLI-агент после /clear.

Первый риск: невидимое изменение смысла

Представьте, что агент добавил product_code в mart_customer_360. SQL компилируется, dbt-тесты могут пройти, но grain больше не «одна строка на customer_id». Для потребителя ниже по цепочке это ломающее изменение контракта: отчёт, который считал клиентов, начинает считать пары клиент-продукт. В веб-приложении такой дефект часто виден сразу. В данных он может попасть в отчёт, KPI или модель риска через неделю.

SDD Data нужен именно для таких случаев. Он заставляет писать до SQL:

какой grain обещан;
какие поля обязательны;
какие поля запрещены;
какие проверки допускают изменение;
кто подтверждает дрейф или ломающие изменения.

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

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

должно быть правдой для бизнеса. Если читатель не удержит это различие с первой главы, дальше все артефакты начнут казаться бюрократией.

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

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

Если после этой главы осталось ощущение, что все слова можно заменить одной командой «собери витрину», стоит остановиться. Такая команда просит агента одновременно быть аналитиком, архитектором, ревьюером и владельцем риска. В первом томе это было опасно для фичи. В данных это опаснее: итоговая таблица может выглядеть аккуратно, но уже говорить неправду.

Практика

Откройте пример:

cd book3/examples/bank-lakehouse
bash smoke_all.sh

Если dbt не установлен, smoke всё равно сгенерирует синтетические данные и проверит структуру. После установки зависимостей он выполнит полный dbt build.

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

После этой части у вас должен быть выбран режим чтения:

учебный локальный трек на DuckDB;
сопоставление с боевым контуром как справочный слой, не как обязательная

инфраструктура;

понимание, что книга строит не «банк вообще», а один воспроизводимый

процесс дата-продукта.

Запишите в рабочие заметки:

Первый проход: строю локальный DataLakeHouse банка на dbt-duckdb; сопоставление
с боевым контуром не внедряю до практического зачёта.

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

Начинающие пытаются сразу заменить DuckDB на «настоящий» стек. Это

преждевременно. В первом проходе важнее увидеть связь между спецификацией и проверяемой витриной. Если локальная версия не держит grain, тесты и политику PII, боевой кластер только ускорит ошибку.