Слои DWH: лучшие практики

Хранилище данных без слоёв — это не хранилище, а свалка. Если у вас двести таблиц лежат в одной куче и никто уже не помнит, где «сырое», а где «можно смело тащить в отчёт», — поздравляю: вы построили архитектуру «как-нибудь само рассосётся». А она, как водится, не рассасывается. Она приходит на планерку и показывает три разные цифры по одному и тому же показателю.

Слои в DWH нужны не для красоты на схеме в Confluence. Это конвейер, где каждый участок делает свою работу и не лезет в чужую. Разберём, как устроены классическая схема и медальон-архитектура, и соберём список практик, которые реально спасают проект от хаоса.

Зачем делить хранилище на слои

Аргумент «зачем плодить сущности» обычно звучит из уст тех, кто потом полгода разгребает последствия. Слои решают три проблемы разом:

1. Доверие. Потребитель знает: беру данные из такого-то слоя — и они уже проверены, пересчитаны и согласованы. Не «ну, вроде бы».
2. Переиспользование. Один раз очистил и привёл к порядку — используй сто раз. А не сто раз очищай по-разному.
3. Жизнеспособность. Меняется источник — правится один слой, а не все отчёты компании разом.

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

Классика: Staging → Core → Витрины

Классическая схема пришла из мира, где DWH жил в отдельной БД, а ETL-джобы крутились по ночам. Она до сих пор работает — просто в каждой школе называется чуть по-своему.

flowchart LR
  A[Источники: CRM, 1С, БД, API] --> B[Staging<br/>данные как есть]
  B --> C[Core<br/>интеграция, 3NF / Data Vault]
  C --> D[Витрины<br/>звёзды, денормализация]
  D --> E[BI, аналитики]

Staging — слой «как есть». Сюда льём данные из источников почти без трансформаций: переименовали колонки, привели типы к переносимому виду — и хватит. Никакой бизнес-логики. Staging — это слепок реальности, который можно перезалить без последствий: пришёл новый дамп — лёг поверх старого.

Core — слой правды. Здесь данные интегрируются: склеиваются из разных источников, нормализуются (3NF) или раскладываются по Data Vault, ведётся история изменений (SCD), живут справочники. Core отвечает на вопрос «что в компании произошло на самом деле» — без оглядки на то, как это удобнее показать на дашборде.

Витрины — слой «для людей». Денормализованные звёзды и агрегаты, заточенные под вопросы бизнеса: выручка по регионам, активность по каналам. Тут уже можно смело JOINить и строить отчёты — больно не будет.

Называйте таблицы по слоям, чтобы не гадать по содержимому: stg_orders, core_dim_customers, mart_revenue_by_region. Через месяц вы скажете себе спасибо.

Медальон-архитектура: бронза, серебро, золото

Databricks популяризировала ту же идею под именем медальон-архитектуры (medallion architecture). Слоёв три, и названы они благородными металлами — потому что ценность данных растёт от слоя к слою.

flowchart LR
  A[Источники] --> B[Bronze<br/>сырьё, append-only]
  B --> C[Silver<br/>чистые данные]
  C --> D[Gold<br/>бизнес-модели и витрины]
  D --> E[BI / ML / ИИ-агенты]

Bronze — исходники как есть, но с одним важным отличием от классического staging: записи только добавляются (append-only), ничего не перезаписывается. Оригинал хранится вечно — это страховка на случай, если «чистка» в следующем слое вдруг окажется слишком агрессивной. В лейкхаусе bronze — это, как правило, паркет поверх озера данных.

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

Gold — бизнес-модели: витрины, агрегаты, метрики. Именно gold кормит дашборды, отчёты и, что модно сейчас, ИИ-агентов.

Разница с классикой — не в количестве слоёв, а в акцентах: медальон-архитектура жёстко требует не трогать сырьё (immutability) и живёт преимущественно на открытых форматах поверх объектного хранилища. По духу это та же staging → core → витрины, только без религии про «обязательно в реляционной БД».

Лучшие практики

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

Сырьё неприкосновенно

Никогда не переписывай bronze/staging. Только долив. Потому что «исправить» сырьё — значит потерять возможность воспроизвести прошлые расчёты и понять, что именно сломалось. Пришёл новый дамп с исправленными данными — залей его новым срезом, а не перезаписью.

Идемпотентность — закон

Перезапуск пайплайна должен давать тот же результат. Запустили витрину дважды — получили одинаковые цифры, а не «почему-то 12, а не 11». Достигается это полной перезаписью партиций или срезов за период и отсутствием хрупких зависимостей вроде «сначала вставь, потом обнови».

Приводи к порядку как можно раньше

Типы, схемы, имена колонок — фиксируй уже в silver. Каждый слой, который работает с сырым JSON без схемы, — это слой, где ошибки плодятся как кролики. Чем раньше данные становятся строгими, тем меньше сюрпризов наверху.

Тесты данных — на каждом слое

Данные — это код, и их нужно тестировать. Как минимум: not_null и unique на ключах, accepted_values на статусах, проверки свежести на staging. Инструменты вроде dbt делают это родным способом:

version: 2 models:  - name: silver_orders    columns:      - name: order_id        tests:          - not_null          - unique

Упал тест — пайплайн встал, пока не разобрались. Дешёвая цена за то, чтобы не разбираться в цифрах на планерке.

Одна логика — одно место

Каждая метрика считается один раз — в gold. Не «примерно так же» в пяти отчётах. Если аналитики сами досчитывают выручку в Excel поверх витрины — считайте, что золотого слоя у вас нет. А если метрики расходятся между отделами — вам прямая дорога в семантический слой, но об этом чуть позже.

Инкремент там, где нужно, полный пересчёт — где можно

Для маленьких таблиц полный пересчёт — это просто и надёжно. Для больших — инкрементальная загрузка по watermark'ам или по партициям. Главное правило: не делай инкремент ради инкремента. Сложность оправдана только тогда, когда полный пересчёт реально начал тормозить.

Документируй и рисуй lineage

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

Права доступа по слоям

Bronze видят узко (инженеры), gold — широко (все, кому нужно). Но раздавать доступ к gold напрямую в BI — путь в хаос. Правильный вход для бизнеса — семантический слой поверх gold, где метрики определены один раз, а не пересобираются в каждом дашборде. Подробнее — в посте про архитектуру семантического слоя.

Грабли

Быстро пробежимся по граблям, на которые наступают почти все.

Витрины из staging. «Зачем ждать, пока core прогонится, если можно быстро склеить прямо из сырья?» Затем, что через месяц у вас пять вариантов одной витрины и ни одного доверия. Правило простое: отчёт читает только gold (или семантический слой поверх него).

Всё в одном слое. Таблицы-помойки, где перемешаны и сырьё, и бизнес-логика, и агрегаты. Выглядит «гибко», чинится мучительно. Слои — это не про бюрократию, а про предсказуемость: каждый слой отвечает на свой вопрос.

Семь слоёв там, где нужны три. Обратная крайность — архитектура ради архитектуры. Если на схеме слоёв больше, чем инженеров в команде, — вы строили не хранилище, а музей. Три слоя закрывают 95% задач, всё остальное оправдано только реальной потребностью.

Нет тестов и документации. Самая дорогая экономия. Данные без тестов — это код без компиляции: работает, пока не сломается, а ломается всегда в самый неподходящий момент.

Метрики считаются в BI. Дашборд с формулами внутри — это спрятанная бизнес-логика, которую никто не версионирует и не тестирует. Вынесите расчёты в gold и семантический слой — и перестанете гадать, почему утром цифры одни, а к вечеру другие.

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

Всеволод Миронович Директор по данным @ Далее

Сухой остаток

• Слои — это конвейер: сырьё → правда → удобные витрины. Не умножай сущности без нужды, но и не сливай всё в одну кучу.
• Классика (staging → core → витрины) и медальон (bronze → silver → gold) — одна идея в разных декорациях. Выбирай по своему стеку, а не по моде.
• Сырьё неприкосновенно, пайплайны идемпотентны, данные протестированы, логика — в одном месте.
• Метрики должны жить выше хранилища — в семантическом слое. Иначе «единая версия правды» останется мемом, а не практикой.

Если хочется копнуть глубже: что такое семантический слой, архитектура данных и семантика и лейкхаус на Iceberg — там та же слоистость, только на уровне файлов и метаданных.