Что такое медальонная архитектура? Слои Bronze, Silver и Gold — объяснение

Медальонная архитектура и традиционные ETL‑пайплайны

В хранилищах данных с традиционными конвейерами extract-transform-load (ETL) схему данных нужно определить заранее. Если формат или схема меняется, система упадёт, если вы не внесёте ручные правки. 

В медальонной extract-load-transform (ELT) архитектуре данные сначала сохраняются в сыром виде, а не преобразуются на лету с сохранением уже итоговых данных. Благодаря этому медальонные архитектуры одновременно надёжны и гибки: вы можете хранить сырые данные как есть и решать позже, как их использовать. 

Для подробного сравнения двух подходов рекомендуем наш гид ETL vs ELT.

Ещё одно преимущество медальонной архитектуры — её независимость от платформы. Bronze, Silver и Gold — это логические стадии, а не технологии конкретного вендора. Паттерн можно реализовать на разных системах хранения, движках обработки и форматах таблиц — в зависимости от вашей платформы и требований к нагрузке.

Как работают слои Bronze, Silver и Gold в медальонной архитектуре?

Три слоя медальона логически выстраиваются друг за другом, и каждый опирается на предыдущий.

Слой Bronze: сырые данные как точка восстановления

Сюда приземляются сырые данные как есть — будь то реляционные БД, SaaS‑приложения вроде Salesforce, Kafka‑топики с потоками событий в реальном времени, REST API, CSV‑экспорты или потоки от IoT‑устройств. Инжест обычно выполняют инструменты вроде Fivetran для CDC или Databricks Auto Loader для файлов, попадающих в объектное хранилище.

Данные Bronze обычно содержат ошибки, несоответствия и дубликаты, поэтому их нельзя использовать напрямую для бизнеса. При этом слой крайне ценен как точка восстановления, из которой можно регенерировать данные Silver или Gold.

Важность этого слоя — в его следе: он фиксирует и логирует каждое событие или транзакцию инжеста. Здесь часто есть полезные метаданные — метки времени инжеста, источники данных и всевозможные идентификаторы. Цель — хранить данные максимально сырыми и полными, чтобы можно было переигрывать нижележащие пайплайны на тех же исходных данных для отладки.

Слой Silver: слой контракта

Серебряный слой преобразует сырые данные в чистые и структурированные. Примеры важных очистительных трансформаций, происходящих между Bronze и Silver:

• Отсев лишних столбцов
• Удаление дубликатов записей
• Исправление несоответствий
• Обработка пропусков
• Стандартизация данных
• Объединение и слияние различных наборов данных

Этот слой также обеспечивает принудительное соблюдение схемы, гарантируя соответствие предопределённой структуре и поддерживая эволюцию схемы. 

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

Так как на этом этапе данные модифицируются, важно использовать инструменты родословной данных, такие как dbt, чтобы отслеживать трансформации от Bronze к Silver. Проверки качества обычно реализуются через тесты dbt, Great Expectations или Soda, а управление — через каталог данных вроде Databricks Unity Catalog или Collibra.

Если хотите научиться превращать «грязные» данные в корректные наборы уровня Silver, начните с нашего курса Cleaning Data in Python.

Слой Gold: бизнес‑готовые результаты

Финальный слой хранит данные максимально высокого качества. Эти глубоко доработанные данные используются для бизнес‑отчётности в Power BI, Tableau или Looker, потребляются нижележащими аналитическими приложениями или подаются моделям ML через фичехранилища, такие как Feast или Databricks Feature Store.

Поскольку данные уже очищены, фокус этого этапа — превратить их в ценный бизнес‑актив. В зависимости от конкретного сценария (финансовые отчёты, маркетинговые дашборды, системы алёртов, обучение ML‑моделей и т. п.) трансформации после Silver гарантируют, что Gold содержит ровно ту информацию, которая нужна для задачи.

Здесь создаются KPI, применяются пользовательские бизнес‑формулы или выполняется агрегация до недельных, месячных или квартальных данных для плановой отчётности. Операции Bronze и Silver часто типовые, а операции Gold — более гибкие и зависят от того, как вы хотите использовать данные.

Как пересобрать Silver и Gold из данных Bronze?

Сохранять сырые данные в Bronze имеет смысл только если вы реально можете их переиспользовать — а это происходит при любых изменениях выше или ниже по цепочке. Стоимость изменений зависит от того, насколько далеко по цепи они находятся. 

• Изменение схемы источника означает проигрывание Bronze через Silver и Gold. 
• Изменение бизнес‑определения (например, новое правило выручки или другой интервал агрегации) означает только пересборку Gold из уже провалидированного Silver.

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

Это также означает, что можно менять определение метрики без повторного инжеста — практическая причина, по которой команды с множеством потребителей Gold держат слои раздельно.

Как медальонная архитектура вписывается в data lakehouse?

A data lakehouse сочетает дешёвое объектное хранилище озера данных с транзакционными гарантиями хранилища. Он ничего не говорит о том, как упорядочить таблицы внутри. Этот пробел и закрывает медальон: lakehouse — это субстрат хранения, а Bronze, Silver и Gold — это способ разделить его на каталоги, схемы и таблицы с разными гарантиями качества.

На практике разделение обычно физическое. В Databricks это могут быть три схемы в каталоге Unity Catalog, а в Microsoft Fabric — lakehouse с таблицами Bronze и Silver, питающими склад Gold. Паттерн один, «сантехника» разная.

Открытые форматы таблиц обеспечивают устойчивость слоёв при параллельных чтениях и записях. Delta Lake, Apache Iceberg и Apache Hudi предлагают комбинации из:

• ACID‑транзакций
• Эволюции схемы
• Версионирования состояния таблицы
• Контроля конкуренции
• Эволюции партиционирования
• Путешествия во времени

Версионирование особенно важно для поведения с переигрыванием, о котором мы уже говорили. Сырые файлы Parquet прекрасно сохраняют исходные данные, но не дают транзакционной истории для отката, поэтому неудачный прогон Silver перезапишет удачный, и сравнивать будет не с чем. Delta Lake отслеживает изменения в журнале транзакций, а Apache Iceberg представляет состояния таблиц как снимки.

Ничего из этого не обязательно. Медальон — логический паттерн, и многие команды запускают его на схемах Postgres или простых префиксах S3 с dbt сверху. Вы просто теряете дешёвый откат.

Медальонная архитектура и data mesh

Их часто сравнивают, предполагая конкуренцию. Но они отвечают на разные вопросы: data mesh решает, кто владеет данными, а медальонная архитектура — как этот владелец их дорабатывает.

Data mesh передаёт ответственность за данные доменным командам — продажам, финансам, цепочке поставок — которые публикуют свои данные как продукты и отвечают за их качество, обнаружимость, происхождение и управление. Эту модель держат вместе две вещи: самообслуживаемая инфраструктура с единым инструментарием для всех доменов и федеративное управление, задающее общекорпоративные стандарты без изъятия владения у доменов.

Медальонная архитектура — это то, что доменная команда запускает у себя. Команда цепочки поставок, владеющая данными о доставках, держит сырые события отгрузок в Bronze, валидированные записи — в Silver и публикует аналитически готовые наборы Gold для потребления другими доменами. Mesh определяет контракт на границе Gold; всё, что выше по течению, — зона ответственности той команды.

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

Преимущества и ограничения медальонной архитектуры

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

Задержку легче всего недооценить. Каждый слой — это обычно отдельная плановая задача, поэтому трёхслойный пакетный пайплайн, запущенный раз в час, может оставить Gold на два часа позади источника. Для еженедельного отчёта по выручке это нормально, а для операционного алёрта — нет. Поэтому команды часто позволяют алёртам читать напрямую из Silver, не дожидаясь Gold.

Хранилище — это то, о чём вспоминают первым, но обычно это меньшая проблема. Bronze лежит в дешёвом объектном хранилище, дублирование реально, но ограничено. Больнее бьёт количество пайплайнов: три слоя на двадцать исходных таблиц — это шестьдесят потенциальных падений в 3 часа ночи.

На этом фоне низкое качество данных тоже выставляет счёт. IBM сообщила в 2026 году, что 43% COO назвали качество данных своим главным приоритетом, основываясь на исследовании 2025 года Института ценности бизнеса. Более четверти организаций в этом исследовании сообщили о ежегодных потерях из‑за плохого качества данных свыше $5 млн.

Так что вопрос не в том, стоит ли внедрение медальонной архитектуры дороже одного пайплайна (да, дороже). Вопрос в том, не платите ли вы уже за альтернативу — встречами по сверке и дашбордами, которым никто не доверяет.

Когда стоит использовать медальонную архитектуру?

Медальон окупается, когда одни и те же очищенные данные обслуживают более одного потребителя. Это лучший предиктор — важнее объёма данных, размера команды или числа источников.

Используйте медальонную архитектуру, когда:

• Несколько команд или нагрузок читают одни и те же данные. Один раз очистите и стандартизируйте в Silver, затем стройте столько наборов Gold, сколько нужно для BI, отчётности или обучения моделей.
• Разные бизнес‑вопросы требуют разных «форм» одних и тех же данных. Финансам нужен ежемесячный признанный доход, а продажам — ежедневные бронирования по менеджерам. Оба варианта получаются из одной таблицы Silver без дублирования логики инжеста.
• Ваши источники противоречат друг другу. В Silver вы сопоставляете ID аккаунта в Salesforce с ID клиента в биллинге, прежде чем кого‑то внизу заставят гадать, какой из них «истинный».
• Нужно обосновать показатель. Разделение сырых, валидированных и курируемых данных позволяет проследить спорную цифру через каждую трансформацию, а не вычислять заново.
• Логика трансформации часто меняется. Как уже говорилось, сохранённые данные Bronze позволяют пересобирать без возврата к источнику.

Пропустите, если:

• У вас маленькая команда данных и низкая сложность пайплайнов.
• Данные поступают из одного источника и требуют минимума очистки или трансформации.
• Данные потребляет только одно приложение или одна команда.
• Требования к отчётности простые и не оправдывают поддержку нескольких слоёв обработки.

Когда двух слоёв достаточно

Трёхслойная схема — это умолчание, а не требование. При одном бизнес‑кейсе Bronze плюс объединённый слой часто лучший выбор: сохраняйте сырьё для переигрывания, а очистку и бизнес‑логику делайте в один шаг.

Подберите форму под своих потребителей. Сливать Bronze не стоит — это слой, который нельзя воссоздать.

Если вы на распутье и честно не уверены — начните с двух слоёв, а третий добавьте, когда появится второй потребитель. Добавить Gold потом куда дешевле, чем задним числом вводить Bronze после полугода перезаписи сырья.

Типичные ошибки при внедрении медальонной архитектуры

Большинство проблем медальона — не архитектурные. Это небольшие компромиссы под давлением сроков, которые незаметно лишают смысла слоистый подход.

Трансформации данных в Bronze

Вся идея переигрывания держится на том, что Bronze хранит нечто близкое к тому, что прислал источник. Если применить бизнес‑логику до приземления, вы теряете исходное состояние — значит, ни перепроцессинга, ни аудита.

Обычно это делается по веским причинам. Кто‑то удаляет «ненужный» столбец ради экономии места или преобразует «кривое» время на инжесте, потому что оно ломает следующий джоб. Через полгода оказывается, что столбец был нужен, а исходные значения утеряны. Держите Bronze как можно ближе к источнику, а правки переносите в Silver.

Смазывание границы между Silver и Gold

Silver очищает и стандартизирует. Gold отвечает на бизнес‑вопросы. Когда логика метрик просачивается в Silver, каждый набор Gold наследует определение, о котором не просил — и вы возвращаетесь к проблеме, которую медальон должен был решить.

Тест прост: если бизнес‑пользователь спорит о числе — это Gold. Дедупликация — забота Silver. Что считать активным клиентом — нет.

Воспринимать три слоя как обязательные

Медальонная архитектура — логический паттерн, а не требование, чтобы каждый пайплайн имел ровно три физических слоя. Bronze, Silver и Gold — это логические стадии уточнения данных, и каждый слой можно реализовать по‑разному в зависимости от нагрузки. 

Например, слой может использовать материализованные таблицы, представления или другие подходящие абстракции, а не требовать отдельной физической копии. Суть — создать осмысленные границы по мере движения данных от сырого состояния к тому, чему бизнес доверяет и что использует, а не воспроизвести классическую трёхслойную картинку в точности. 

Оставлять Gold «свалкой»

Это встречается чаще всего и обсуждается реже всего. Наборы Gold дёшевы в создании, и их никто не удаляет, поэтому через год у вас может быть сорок таблиц, одиннадцать из них — вариации ежемесячной выручки, и никто не помнит, на какую смотрит CFO.

У Silver дисциплина естественная — задача определена. У Gold её нет, поэтому нужен владелец на каждый набор и готовность удалять. Иначе вы придёте к нескольким конкурирующим версиям одной и той же метрики — именно того, чему слои должны были помешать.

Итоги

По сути, медальон даёт вам место, на которое можно указать, когда спросят, откуда взялась цифра, и копию исходных данных, к которой можно вернуться, если ответ окажется неверным. Это стоит дополнительных хранилищ и задач, когда одни и те же данные читают несколько команд. Если читает одна — два слоя могут быть лучшим решением и сэкономят поддержку.

Если нужен более широкий контекст, наш курс Understanding Modern Data Architecture охватывает платформы и технологии современного дата‑стека. Карьерный трек Data Engineer глубже погружается в построение и поддержку продакшн‑пайплайнов.