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 свалены в одну схему. Проблемы очевидны. Аналитик не понимает, какой таблице доверять — где сырьё, а где готовый результат. Изменение в источнике может неконтролируемо «протечь» прямо в дашборд. Невозможно сказать, на каком этапе данные испортились.

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

Названия — из спорта: 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.

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

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

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

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

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

Попробуй сам

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

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

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