Medallion architecture: bronze, silver, gold

Предыдущие модули дали вам набор техник моделирования: нормализация, star schema, SCD, Data Vault. Возникает практический вопрос — а как они уживаются в одном реальном хранилище? Ответ современной индустрии — medallion architecture: способ организовать хранилище в три слоя по зрелости данных. Эту схему популяризировала Databricks, и к 2025-2026 она стала де-факто стандартом организации lakehouse.

Сразу зафиксируем важное, чтобы не было главного заблуждения новичков. Medallion — это не методология моделирования. Это не альтернатива Kimball или Data Vault. Medallion говорит, на какие слои поделить хранилище по зрелости данных; но внутри каждого слоя всё равно нужна конкретная модель — 3NF, Data Vault, star schema или OBT. Medallion — про слои, методологии моделирования — про то, как устроены таблицы внутри слоя. Это два ортогональных вопроса.

Зачем вообще слои

Представьте хранилище без слоёв: сырые данные из источников, очищенные таблицы и витрины для BI свалены в одну схему. Проблемы очевидны. Аналитик не понимает, какой таблице доверять — где сырьё, а где готовый результат. Изменение в источнике может неконтролируемо «протечь» прямо в дашборд. Невозможно сказать, на каком этапе данные испортились.

Слои наводят порядок. Каждый слой — это уровень зрелости данных: насколько они обработаны, очищены и готовы к потреблению. Данные текут строго в одну сторону, от менее зрелого слоя к более зрелому. Это даёт изоляцию (изменение в одном слое контролируемо влияет на следующий), понятность (по слою сразу ясен статус данных) и точку отладки (видно, где сломалось).

Три слоя medallion: рост зрелости данных

Bronze

очистка, типизация, согласование

Silver

агрегация, денормализация под бизнес

Gold

Названия — из спорта: bronze, silver, gold, медали по возрастанию ценности. Чем выше слой, тем ценнее и готовее данные. Разберём каждый и, главное, какая модель данных на нём уместна.

Ещё одно правило, общее для всех слоёв, — однонаправленность потока. Данные текут только снизу вверх: bronze питает silver, silver питает gold. Никогда наоборот и никогда «через слой» — gold не читает напрямую из bronze, минуя silver. Это ограничение кажется формальным, но оно и создаёт изоляцию. Когда поток строго однонаправлен, любое изменение распространяется предсказуемо: правка в silver затронет gold, но физически не может затронуть bronze. Если бы слои читали друг у друга как попало, изоляция исчезла бы, и «где сломалось» снова стало бы неразрешимым вопросом. Однонаправленный поток — это то, что превращает три папки с таблицами в архитектуру.

Bronze: сырьё как есть

Bronze — слой приёма. Сюда данные попадают из источников как есть, с минимальной обработкой или вообще без неё. Структура bronze-таблицы повторяет источник; значения не очищаются, типы часто остаются строковыми, к строкам добавляются только технические метаданные приёма.

Что обычно добавляют к каждой строке в bronze: время загрузки (ingestion_timestamp), имя источника (source_system), имя файла или offset (source_file). Это нужно для отладки и для инкрементальной обработки.

-- Bronze-таблица: повторяет источник, плюс метаданные приёма
CREATE TABLE bronze.orders (
    raw_payload          VARIANT,      -- сырой JSON из источника как есть
    ingestion_timestamp  TIMESTAMP,    -- когда строка принята
    source_system        VARCHAR,      -- 'shop_api'
    source_file          VARCHAR,      -- 'orders_2026-05-20.json'
    is_processed         BOOLEAN       -- обработана ли silver-слоем
);

Bronze почти всегда append-only: новые данные дописываются, существующие не трогаются. Это даёт свойство, знакомое по Data Vault, — возможность переиграть обработку. Если в коде silver-слоя нашли баг, bronze хранит все исходные данные, и silver можно пересобрать с нуля. Bronze — это страховка и точка восстановления.

Какая модель данных на bronze? Практически никакой осознанной — структура диктуется источником. Это сырьё, и моделировать его незачем.

Silver: очищено и согласовано

Silver — слой, где данные приводятся в порядок. Здесь происходит то, что в Data Vault делал Business Vault: очистка, типизация, дедупликация, согласование между источниками.

Типичные операции silver-слоя:

Типизация. Строка '2026-05-20' из bronze превращается в настоящий DATE; '1500.00' — в DECIMAL. Это важнее, чем кажется: пока дата лежит строкой, по ней нельзя корректно отфильтровать диапазон или отсортировать, а арифметика над строковой суммой невозможна.
Очистка. Телефоны и адреса приводятся к единому формату; явный мусор отсеивается.
Дедупликация. Если источник прислал дубли — лишние строки убираются.
Согласование источников. Клиент из CRM и из биллинга сводится к единой записи; расхождения разрешаются по правилам.
Применение бизнес-ключей. Сущности получают понятные идентификаторы.

-- Silver: типизировано, очищено, дедуплицировано
CREATE TABLE silver.orders AS
SELECT
    CAST(raw_payload:order_id   AS BIGINT)    AS order_id,
    CAST(raw_payload:customer_id AS BIGINT)   AS customer_id,
    CAST(raw_payload:order_date  AS DATE)     AS order_date,
    CAST(raw_payload:amount      AS DECIMAL(12,2)) AS amount,
    source_system
FROM bronze.orders
WHERE raw_payload:order_id IS NOT NULL          -- отсев мусора
QUALIFY ROW_NUMBER() OVER (
    PARTITION BY raw_payload:order_id
    ORDER BY ingestion_timestamp DESC) = 1;     -- дедупликация

Какая модель данных на silver? Здесь важная оговорка. У silver-слоя нет одной канонической модели — выбор зависит от организации и инструментов. На практике silver commonly моделируют write-оптимизированно: часто это структуры, близкие к 3NF, либо Data Vault-подобные. Логика такая: silver — это чистое, согласованное представление сущностей, а нормализованные или Data Vault-структуры хорошо хранят согласованные данные с историей. Но это распространённая практика, а не предписание: некоторые команды держат silver ближе к источнику, другие — уже частично размерным. Не запоминайте «silver = 3NF» как закон; запоминайте «silver — слой согласованных сущностей, моделируется write-оптимизированно».

Gold: бизнес-готовые витрины

Gold — верхний слой, то, с чем работают аналитики и BI. Данные здесь бизнес-готовые: агрегированные, денормализованные, оптимизированные под чтение и понятные не-инженеру.

Какая модель данных на gold? Здесь как раз вступают в дело методологии из предыдущих модулей. Gold-слой — это обычно:

Star schema — классическая размерная модель Kimball: fact в центре, dimensions вокруг.
One Big Table (OBT) — одна широкая денормализованная таблица (подробно — в следующем уроке).
Агрегаты — предвычисленные сводки: выручка по месяцам, метрики по сегментам.

Gold оптимизирован под чтение: денормализация уместна и желательна, JOIN-ов мало, запросы быстрые. Именно здесь живут dim_customer, fct_orders, agg_monthly_revenue.

Какая модель на каждом слое medallion

Bronze

Silver

Gold

Почему именно три слоя, а не один или десять

Можно спросить: зачем три? Почему не грузить из bronze сразу в gold?

Каждый слой решает свою задачу, и пропуск любого больно бьёт:

Без bronze теряется возможность переиграть обработку — нет исходных данных, баг в трансформации означает потерю.
Без silver очистка и согласование размазываются по витринам gold; одна и та же логика дублируется в каждой витрине, расходится, и единого «согласованного представления сущностей» нет.
Без gold аналитик работает с нормализованными silver-таблицами — десятки JOIN, медленно, непонятно бизнесу.

Три слоя — это разделение трёх разных ответственностей: принять, согласовать, подать. А почему не десять? Больше слоёв — больше копий данных, больше пайплайнов, больше задержка. Три — проверенный баланс. При необходимости внутри слоя делают подслои (silver.staging, silver.core), но базовых уровней зрелости остаётся три.

Слой	Зрелость	Запись/чтение	Типичная модель
Bronze	Сырьё	Append-only	Структура источника
Silver	Очищено, согласовано	Write-оптимизировано	3NF-подобное / Data Vault (commonly)
Gold	Бизнес-готово	Read-оптимизировано	Star schema / OBT / агрегаты

TIP

Когда вы слышите спор «Kimball против Data Vault» — частый ответ в архитектуре с medallion: оба, на разных слоях. Data Vault или 3NF-подобная модель на silver как согласованный backbone; Kimball star schema на gold как consumption-слой. Medallion даёт каркас, в котором обе методологии не конкурируют, а дополняют друг друга.

Medallion в production — как bronze/silver/gold реализуются в batch-пайплайне Delta Lake как хранилище для medallion — ACID и time travel на каждом слое

Попробуй сам

Возьмите источник — например, выгрузку заказов интернет-магазина в JSON.

Опишите, как выглядела бы строка этого заказа в bronze-таблице. Какие технические метаданные приёма вы бы добавили?
Перечислите 4-5 операций, которые произойдут с этими данными на пути bronze -> silver (типизация, очистка, дедупликация, согласование).
Опишите 2-3 gold-таблицы, которые вы построили бы поверх silver для типичных вопросов бизнеса («выручка по месяцам», «топ клиентов»). Какая модель — star schema или OBT?
Объясните себе, почему нельзя просто грузить из bronze сразу в gold, минуя silver. Что конкретно потеряется?

В следующем уроке детально разберём One Big Table — одну из главных моделей gold-слоя — и её компромисс «storage против compute».

Проверка знанийKnowledge check

Что описывает medallion architecture, почему это НЕ методология моделирования, и какая модель данных уместна на каждом из трёх слоёв?

ОтветAnswer

Medallion architecture описывает организацию хранилища в три слоя по зрелости данных: bronze (сырьё из источников как есть, append-only, плюс метаданные приёма), silver (очищенные, типизированные, дедуплицированные, согласованные между источниками данные) и gold (бизнес-готовые витрины, оптимизированные под чтение). Это НЕ методология моделирования и не альтернатива Kimball или Data Vault: medallion говорит только про слои зрелости, а внутри каждого слоя всё равно нужна конкретная модель — это ортогональные вопросы. На bronze осознанной модели практически нет — структура диктуется источником, это сырьё. Silver не имеет одной канонической модели, но commonly моделируется write-оптимизированно: часто 3NF-подобные или Data Vault-подобные структуры, потому что это слой согласованных сущностей. Gold моделируется read-оптимизированно: star schema (Kimball), One Big Table или предвычисленные агрегаты. Три слоя разделяют три ответственности — принять, согласовать, подать; пропуск любого из них теряет соответственно возможность переиграть обработку, единое согласованное представление сущностей или удобство для аналитика.