Материал: Часть 2. Почему банковские данные требуют спецификаций

Урок 1 из 5 в модуле «Часть 2. Почему банковские данные требуют спецификаций»

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

Источник

Часть 2. Почему банковские данные требуют спецификаций

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

Где риск выше обычного

В учебном банке нас интересуют пять классов риска:

PII и прямые идентификаторы;
платежи и риск-сигналы;
согласия на доступ к данным;
кредитный портфель и просрочка;
отчётность и воспроизводимость расчётов.

Каждый класс риска требует не только SQL, но и проверяемого правила. «Не раскрывать персональные данные» слишком широко. Рабочее правило звучит так: models/marts/ не содержит колонок pii_email, phone, passport_number и других прямых идентификаторов, а ревьюер проверяет это до релиза.

Почему dbt-тестов недостаточно

dbt-тесты хорошо ловят not_null, unique, accepted values и часть кастомных инвариантов. Но они не знают, что customer_360 обещан как «одна

строка на клиента», если вы не записали это в спецификации. Они не знают, что добавление product_code меняет потребительский контракт. Они не знают, что risk_flag — учебный сигнал, а не финальное решение кредитного скоринга.

Поэтому в SDD Data есть несколько слоёв:

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

Пример плохой спецификации

Сделать витрину клиентов для аналитиков. Добавить полезные поля по счетам и
операциям. Проверить качество данных.

Проблемы:

не указан grain;
не сказано, можно ли раскрывать PII;
не определены «полезные поля»;
нет SLA и свежести данных;
«качество данных» не превращено в факты;
нет владельца, который принимает дрейф.

Хорошая версия

Дата-продукт: customer_360.
Потребитель: аналитики клиентского портфеля и филиальной сети.
Витрина: mart_customer_360.
Гранулярность: одна строка на `customer_id`.
PII: в витрине нет прямых PII.
Свежесть данных: 24 часа.

Обязательные факты: `customer_id` unique/not_null, `total_balance_rub` not_null,
`risk_event_count_7d` присутствует, проверка списка запрещённых прямых PII проходит.

Такая спецификация не решает весь продукт, но задаёт границы, которые агент не должен угадывать.

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

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

Особенно важно различать «таблица построилась» и «данные можно использовать». Зелёный dbt build говорит, что граф исполним и заявленные проверки прошли. Он не говорит, что выбрана правильная гранулярность. Он не знает, что в одной витрине нельзя смешивать клиента и счёт. Он не видит, что поле выглядит как скоринговый вывод, хотя на самом деле является учебным флагом источника. Это не недостаток dbt; это граница инструмента.

Читателю полезно тренироваться на плохих спецификациях. Плохая спецификация обычно звучит уверенно: «сделать полезную витрину», «добавить качество», «учесть риски». В ней мало явных ошибок, потому что она почти ничего не обещает. Хорошая спецификация, наоборот, выглядит более узкой. Она говорит: одна строка на клиента, прямые PII запрещены, freshness 24 часа, обязательные поля такие-то, проверки такие-то. Узость здесь не слабость, а способ сделать работу проверяемой.

В этой главе важно не запомнить список банковских рисков, а привыкнуть к вопросу «как это будет доказано?». Если правило нельзя превратить в команду, SQL-запрос, ручной шаг ревьюера или подтверждение человеком, оно пока не готово для агента. Хороший агент не должен угадывать, что значит «корректно»; он должен получить критерий, по которому его работу можно отклонить.

Практика

Возьмите один mart из README и напишите для него три риска: grain, PII и дрейф контракта. Для каждого риска сформулируйте не лозунг, а проверяемое правило. Если правило нельзя проверить, перепишите его до команды или ручного шага ревьюера.

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

После главы создайте короткую заметку:

# Заметки о рисках данных

## PII
## Grain
## Freshness
## Дрейф контракта
## Подтверждения человеком

Заполните по одному правилу в каждый раздел. Если правило нельзя проверить, перепишите его как команду, SQL, ревью схемы или подтверждение человеком.

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

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