# Часть 9. Raw и Bronze-приземление

Raw и Bronze отвечают за воспроизводимость входа. В учебном примере raw — это
CSV-файлы, которые генерирует `scripts/generate_data.py`. В боевом контуре raw может
быть зоной посадки в хранилище объектов, топике Kafka, CDC-таблице или внешнем источнике.
Но принцип тот же: нельзя менять смысл данных на первом шаге.

## Raw

Raw-слой отвечает на вопрос «что пришло». Он не должен:

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

Если источник содержит пустой `revoked_at`, raw сохраняет пустой `revoked_at`.
Решение «пустое значение означает активное согласие» появляется позже, в staging-спецификации.

## Bronze

Bronze добавляет минимальную техническую нормализацию: формат файла, базовую
обработку типов, метаданные загрузки, lineage. В учебном dbt-duckdb примере отдельного
bronze-слоя почти нет, потому что CSV читаются прямо staging-моделями. Но в
тексте важно понимать границу: bronze не должен принимать продуктовые решения.

## Проверяемость

Raw/Bronze приёмочные факты:

- файлы источников существуют;
- заголовки ожидаемые;
- генерация синтетических данных воспроизводима;
- семантика пустых значений и `null` описана в манифесте;
- PII не потеряно до того, как политика утверждена.

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

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

Raw-слой должен быть скучным и честным. Он сохраняет вход. Bronze может добавить
минимальную техническую нормализацию: расположение файла, имя источника, дату
загрузки, базовую типизацию, контроль наличия. Но Bronze тоже не должен решать
вопросы, которые относятся к продукту. Если пустой `revoked_at` означает активное
согласие, это должно быть записано в спецификации и staging-логике, а не спрятано
в ручной правке CSV.

Читателю полезно различать исправление данных и описание данных. На учебном
примере соблазн велик: открыть CSV, заменить пустую строку на дату, получить
зелёный `dbt build`. Но такой путь учит неверному поведению. Правильный путь:
зафиксировать, что пришло; описать, как staging трактует пустоту; добавить
проверку; записать в заметке о проверке, почему это решение принято.

Raw/Bronze — это место, где SDD Data защищает будущий разговор. Когда ревьюер
спрашивает «почему активные согласия считались именно так», ответ не должен
звучать как «так получилось после чистки файла». Ответ должен вести к raw,
манифесту, спецификации, staging и тесту. Чем короче эта цепочка доказательств, тем
меньше доверия к витрине.

## Практика

Найдите в raw-источнике одно поле с неоднозначной семантикой пустого значения.
Запишите, где оно должно быть сохранено как raw-факт, где типизировано и где
превращено в бизнес-правило.

## Qwen-запрос

```text
Проверь raw-источники в book3/examples/bank-lakehouse/raw.
Сравни заголовки с ожидаемыми источниками из доменной карты.
Составь список фактов источника и открытых вопросов.
dbt-модели не меняй.
```

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

После главы:

- raw-файлы можно сгенерировать командой;
- учебный пример имеет заметки манифеста минимум для двух источников, а
  остальные источники разбираются как упражнение;
- спорные значения помечены как открытые вопросы;
- никто не перепутал очистку raw с бизнес-моделированием.

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

Исправлять raw-данные, чтобы «`dbt build` прошёл». Если `dbt build` падает из-за пустой
даты, исправляйте staging-контракт или обработку типов, а не стирайте исходный
сигнал из raw.

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

1. Почему raw не должен удалять PII?
2. Где нужно решать, что пустой `revoked_at` означает активное согласие?
3. Какие приёмочные факты у raw/bronze слоя?