Medallion Architecture¶
Раздел 01 · Уровни и общие гарантии
Тип материала: архитектурный разбор. Схемы и примеры иллюстративные, если не указано иное.
Уровень: логическая организация качества и представлений данных. Проверка источников: 2026-11-02.
1. Назначение и решаемая проблема¶
Medallion делает явным переход от принятого input к проверенным данным и бизнес-показателям. Она полезна, когда аналитики, data scientists и аудиторы нуждаются в разных представлениях одной истории и должны понимать, где были применены правила качества.
Bronze/Silver/Gold — роли данных, не три обязательных физических копии и не встроенная гарантия достоверности. Ошибочная сумма не становится правильной после перемещения в каталог gold.
2. Принцип работы¶
Bronze сохраняет исходные сообщения и ingestion metadata. Silver нормализует типы, проверяет ключи, обрабатывает duplicates и связывает revisions. Gold строит бизнес-модель: например оборот по merchant и currency.
Ошибочные записи переводятся в quarantine с причиной и исходным идентификатором; их нельзя незаметно терять. Каждая выходная версия должна указывать input versions и rule version. Это позволяет отличать «данные ещё не дошли» от «данные отклонены» и повторить только нужный участок.
3. Архитектурная схема¶
flowchart TB
S["Events и batch files"] --> B["Bronze: raw и provenance"]
B --> V["Validation и normalization"]
V --> X["Quarantine с причиной"]
V --> I["Silver: canonical records"]
X --> C["Исправление и повторная проверка"]
C --> V
I --> G["Gold: versioned metrics"]
G --> U["BI и ML"]4. Walkthrough движения данных¶
- В bronze поступают settlement file и live events. Сохраняются оригинальные payload, source position, schema version и received_at.
- Validation проверяет обязательные поля, currency и business key. Две доставки event_id не должны дать две операции.
- Silver сохраняет canonical transaction и revision; связь с raw позволяет объяснить каждую строку. Нераспознанный currency code отправляется в quarantine.
- После исправления справочника этот input повторно проходит validation. Нельзя просто переписать gold без следа изменения.
- Gold пересчитывает затронутый период или делает корректирующий upsert; отчёт получает dataset version и completeness status.
- Закрываемый финансовый отчёт читает согласованный набор версий, а не произвольный latest каждой таблицы.
5. Технологии реализации¶
Варианты: Spark/dbt для transformations; Delta Lake, Iceberg или Hudi для table storage; Kafka/Connect для ingestion; catalog и lineage store для provenance. Это логический паттерн и он может реализовываться также SQL schemas в warehouse.
FACT: документация Databricks называет Bronze/Silver/Gold слоями качества. INFERENCE: из этих названий не следует одна ACID transaction через весь pipeline; проверять нужно конкретный table/engine contract. Databricks, обновление 2026-10-29.
6. Консистентность и гарантии обработки¶
Atomic commit одной таблицы не означает атомарное обновление нескольких слоёв. Для согласованного отчёта потребуется published manifest input/output versions либо orchestration gate. Между слоями допустим lag, но он должен быть наблюдаемым.
Важны два разных контроля: idempotent ingestion предотвращает duplicate effect, а semantic validation проверяет смысл. Дедупликация по неверному ключу может удалить легитимные две одинаковые по сумме операции. «Exactly-once gold» не исправляет такой key design.
7. Отказы и восстановление¶
| Сбой | Восстановление | Проверка |
|---|---|---|
| Silver job упал до commit | Повторить из bronze с тем же input scope | Нет частично видимого результата |
| Изменилось quality rule | Новая rule version и controlled backfill | Разница объяснима по IDs/причинам |
| Gold обновлён, dimension ещё старый | Не публиковать report manifest | Читатель не видит смешанный release |
| Quarantine растёт | Alert owner, исправить правило/producer | Учёт unique accepted + duplicates + quarantined + pending покрывает input |
Удаление raw ради экономии ограничивает reprocessing. Retention согласовывать с recovery и privacy; «raw immutable» не означает бессрочное хранение любых PII.
8. Масштабирование и узкие места¶
Основные затраты: repeated scans, small files, merge/update amplification и lineage metadata. Partitioning выбирается по доступу и backfill scope, а не по каждому high-cardinality business ID. Gold tables могут быть узкими, silver — детальными, bronze — append-oriented.
По мере роста важнее точный incremental dependency graph, чем дополнительные слои. Не каждый промежуточный transform нужно сохранять физически. Следить за freshness каждого слоя и количеством input без конечного решения.
9. Преимущества и недостатки¶
Плюсы: прозрачные quality gates, traceability, повторная обработка из raw и разные формы потребления. Минусы: дополнительное storage/compute, задержка между слоями и необходимость version-aware публикации.
Простому отчёту из одной контролируемой OLTP-таблицы три слоя могут добавить лишнюю работу. Слои полезны, когда соответствуют разным контрактам и owners.
10. Альтернативные решения¶
Прямое ELT в marts подходит при малом числе источников и уже качественных данных. Warehouse staging/core/marts решает похожую задачу другим словарём. Kappa и Lambda описывают execution/recompute и могут проходить через все три слоя. Data Mesh определяет ownership, включая владельцев этих quality contracts.
11. Реальные примеры и границы подтверждения¶
FACT: статья Patrick Brown, Lead Product Manager Data Platform FedEx, от 2025-12-15 прямо описывает Medallion как основу Enterprise Data Platform. Совместная публикация FedEx/Databricks.
UNKNOWN: из текста нельзя вывести универсальный transaction protocol между слоями или считать каждый опубликованный gold dataset финансово закрытым. Это документированный пример слоёв, не benchmark.
12. Применение в FinTech и iGaming¶
FinTech: raw bank reports → canonical ledger/provider records → reconciled reporting datasets. Расхождения сохранять отдельно, не исправлять изменением исходного файла.
iGaming: original bet/result messages → canonical bet revisions → player/market aggregates. Late correction должна заново затронуть silver и зависимые gold metrics. Bronze telemetry сама по себе не служит authoritative wallet ledger.
13. Типичные ошибки проектирования¶
- Считать quality gate обычным cast с silent NULL.
- Удалять quarantine rows из контроля completeness.
- Терять исходный payload при schema evolution.
- Считать ACID таблицы общей транзакцией bronze/silver/gold.
- Создавать gold без owner и определения метрики.
14. Вопросы технического интервью с ответами¶
Обязателен ли Delta Lake? Нет, это логическая организация; нужны подходящие guarantees выбранного storage/compute.
Что означает completeness gold? Что определённый input scope обработан по установленным правилам, включая явный учёт quarantine и pending; не просто успешный job.
Как изменить правило дедупликации? Выпустить rule version, пересчитать staging dataset, объяснить differences и опубликовать новое поколение.
15. Практическое упражнение¶
HYPOTHETICAL: шесть input rows содержат один повтор event_id и одну запись с неизвестной currency. Спроектируйте bronze metadata, quarantine reason и silver business key.
Ожидается четыре принятых unique events, один duplicate и один quarantine при заданном различии ключей. После исправления currency ожидается пять принятых unique events и новый gold release. Опишите, как доказать баланс input без потери исходных шести строк.