Хранилища данных в 2026: четырёхзонная архитектура и почему классические методологии сдают позиции

Когда инженер слышит «нам нужно хранилище данных», задача редко звучит однозначно. Кто-то задыхается на боевой OLTP-базе под аналитической нагрузкой. Кто-то впервые строит BI и не понимает, с какого края подходить. У кого-то накопились данные из десятка систем-источников, и существующих средств уже не хватает.

У всех «хранилище». А правильный технический ответ зависит от условий задачи.

За годы работы в банках, ритейле и системной интеграции мы пришли к простой картине: для среднего и крупного бизнеса большинство DWH-проектов сводится к четырёхзонной архитектуре поверх двух специализированных движков. Расскажу подробно - сначала про устройство, потом про то, чем эта схема лучше Inmon, Kimball и Data Vault 2.0 для типичного бизнес-сценария. И в конце - про несколько вещей, которые в этой архитектуре делать не надо.

Архитектура DWH в четырёх зонах

Pre-stage и Stage - разные схемы внутри одного формата хранения, Apache Iceberg в объектном хранилище. Trino - SQL-движок поверх обеих зон. ClickHouse - последний быстрый слой под пользовательскую нагрузку. BI-инструмент (Apache Superset, Metabase или эквивалент) - сверху.

Stage в этой схеме - источник правды (на схеме обозначен сплошной обводкой). Все остальные зоны можно перевыгрузить из stage. Pre-stage - копия источников, ClickHouse - копия stage. Если что-то ломается - восстанавливается из stage за счёт перезаливки.

Разберу каждую зону.

Зона 1. Pre-stage

Pre-stage - это сырьё. Точная или почти точная реплика данных из систем-источников в формате Iceberg, без бизнес-логики, без обогащения, без человеческой оценки.

Зачем именно Iceberg, а не реляционная СУБД? Несколько причин, и каждую стоит назвать отдельно.

Дешёвое горизонтально масштабируемое хранение. Iceberg-таблицы лежат как Parquet-файлы в объектном хранилище: S3, SeaweedFS, любое S3-совместимое решение. Стоимость хранения отличается от хранения тех же данных в OLTP-базе на порядок-два. Когда речь о петабайтах истории - разница экономики решающая.

Schema evolution из коробки. Источник изменил структуру своей таблицы: добавил колонку, убрал, переименовал. Iceberg переживает такие изменения без миграционной паники: старые данные читаются по старой схеме, новые по новой, движок сам справляется с разрешением. В реляционной СУБД это вылилось бы в координированную миграцию миллиардов строк.

Метаданные и сами данные физически разделены. Каталог Iceberg-таблицы (snapshots, manifests, schema-versions) живёт отдельно от Parquet-файлов с фактическими данными. Каталог можно повредить, потерять, восстановить из бэкапа - сами Parquet никуда не денутся. У файлов реляционной СУБД таких гарантий нет: повреждение служебной структуры тянет за собой потерю данных целиком.

Parquet портабелен. Файл можно прочитать любым движком, который понимает формат - DuckDB, Trino, Spark, Pandas, ClickHouse. Никакой привязки к версии конкретного коммерческого движка, никаких лицензионных ограничений на чтение собственных файлов.

Нет привязки к специалисту по конкретной СУБД. Iceberg обслуживается через Trino, и инженер, умеющий работать с Trino, переносится между проектами без переучивания. Сравните с наймом отдельного DBA Greenplum или Vertica - ставка такого человека сегодня сильно выше, чем универсального дата-инженера.

И пара организационных причин, про которые часто забывают.

Pre-stage снимает нагрузку с команд продуктов-источников. Вместо привычного «разработчик 1С, сделай нам выгрузку под аналитическую задачу» у нас всё уже есть. Команды-источники остаются заняты своим продуктом, не отвлекаются на наши запросы.

CDC под нашим контролем. Что обновлять, что добавлять, как обрабатывать удаления, какой приоритет у разных таблиц - решаем мы. Источник просто отдаёт изменения, дальнейший маршрут наш.

Аналитики экспериментируют на pre-stage, а не на боевой OLTP. Это, может быть, главная организационная польза. Любой DBA знает цену того момента, когда любопытный аналитик запустил SELECT * без LIMIT на учётной системе в час пик. Pre-stage даёт ту же глубину доступа к данным, но боевую базу не трогает.

С чем работаем в pre-stage? С Trino. Его роль - независимый SQL-движок с горизонтально масштабируемым worker-pool’ом. Один coordinator плюс N workers, число workers подбирается под нагрузку. Запросы аналитика на терабайтных таблицах из Iceberg исполняются за минуты, а не часы.

На схеме - как именно Trino работает поверх lakehouse. Координатор принимает SQL-запрос, читает каталог Iceberg (snapshots, manifests, schema-versions) чтобы понять какие Parquet-файлы и в каком разрезе нужны, а затем раздаёт чтение параллельно по worker-pool’у. Воркеры читают Parquet из S3-совместимого хранилища напрямую, минуя координатор - поэтому пропускная способность растёт линейно с числом воркеров.

Здесь же видна важная архитектурная инвариантность lakehouse: каталог метаданных и сами данные физически разделены. Каталог можно потерять и восстановить из бэкапа без затрагивания собственно данных. Воркеры stateless - можно добавлять и убирать на лету. Это та же модель и для pre-stage, и для stage - меняется только содержимое схем.

Зона 2. Stage

Здесь начинается самая интересная инженерная работа.

Stage - результат труда аналитика и инженера над конкретной задачей бизнеса. Большие денормализованные таблицы, специально подготовленные под определённый набор дашбордов или продуктовых сценариев. Со всей бизнес-логикой, со всеми SCD2-историями, со всем обогащением справочниками.

Физически stage живёт в том же Iceberg, но в отдельной схеме (или namespace каталога, если терминологически точнее). Это важный момент. Stage - не отдельная инфраструктура, а вторая зона того же lakehouse, со своими правилами и циклами обновления.

Как наполняется? Trino-запросами, которые формирует аналитик под конкретную задачу. Например: бизнесу нужна аналитика продаж по магазинам. Аналитик пишет запрос, который берёт кассовые ленты из pre-stage, джойнит с товарным справочником, со справочником магазинов, со справочником промоакций, со справочником сегментации клиентов - и формирует одну широкую таблицу «Продажи по магазинам». Эта таблица сохраняется в stage и становится источником правды для соответствующего набора дашбордов.

ETL-планировщик (Apache Airflow с Trino-оператором, Apache SeaTunnel, Dagster, или любая другая система оркестрации - конкретный выбор обычно зависит от того, что уже стоит у клиента) запускает Trino-запрос периодически. Раз в сутки, раз в час, раз в минуту - в зависимости от требований к свежести.

Тонкий момент, который часто упускают. Что хранится в широкой таблице stage?

Не текущее состояние справочника. Состояние на момент совершения транзакции. Если вчера товар назывался «Хлеб», а сегодня его в справочнике переименовали в «Хлеб ржаной» - запись о вчерашней продаже в stage останется с «Хлеб», ровно так, как было фактически. Дополнительно хранится ключ товара, который позволяет при необходимости подтянуть актуальное название.

Это не баг, а сознательное решение. Stage хранит факты, а не дата-атрибутику в её последней редакции. Отчёт «как было на момент продажи» строится без всяких пересборок. Отчёт «по текущей классификации» решается через отдельный справочник актуальных значений, который джойнится при выгрузке. Никаких ретроспективных пересборок широкой таблицы при изменении справочника не требуется.

Почему stage - самый ценный слой DWH? Потому что в ней материализована вся работа, которую сделал аналитик и инженер. Бизнес-логика обогащения, правила отнесения к сегментам, SCD2-истории, расчёт промежуточных метрик. ClickHouse дальше получит только копии этих таблиц. Если ClickHouse сломается, упадёт, потребует пересоздания - ничего критичного: stage цел, перевыгрузим. А если потеряется stage - это потеря исторических срезов, потеря правил расчёта, потеря месяцев работы аналитической команды.

Поэтому stage обкладывается всем что положено: полные снапшоты Iceberg, time-travel-возможность откатиться к любой исторической версии, репликация в другой регион при необходимости.

Зона 3. ClickHouse-витрина

ClickHouse - копия stage-таблиц, специально подготовленная под обслуживание дашбордов.

Зачем нужен отдельный движок поверх Iceberg, если Trino уже умеет читать stage? Простая инженерная причина: Trino - универсальный SQL-движок для трансформаций, ClickHouse - специализированный колоночный движок под аналитическую нагрузку. Под BI-нагрузкой, где сотни конкурентных пользователей одновременно тыкают дашборды и ждут отклика за миллисекунды, ClickHouse выигрывает с большим отрывом. Trino при такой нагрузке начнёт упираться в координатор и в очередь воркеров.

Как наполняется? Stage-таблицы периодически копируются в ClickHouse. У ClickHouse под это есть специальный тип таблицы - ReplacingMergeTree. Он естественным образом дедуплицирует строки по ключу при фоновом merge: загружаем upsert-партию, движок сам разбирается какие строки актуальные.

Принципиально: ClickHouse не источник истины. Он быстрая витрина-копия. Это снимает с него часть инженерных требований: бэкап, persistence, recovery становятся проще, потому что в случае проблемы данные перевыгружаются из stage. Стратегия восстановления простая - снести и перелить.

Кстати, про моду последних месяцев. Появилось много шума про то, что ClickHouse 25.x умеет читать Iceberg напрямую, и поэтому Trino становится «опциональным». Прочитал документацию внимательно. Реальность скромнее: чтение Iceberg из ClickHouse работает для V1/V2 базовых случаев, но equality deletes не поддерживаются (а это базовая V2-фича для CDC-сценариев), запись помечена как experimental, distributed reads через worker-pool отсутствует. В прод как замена Trino это пока не идёт. Для ad-hoc-запросов аналитика «посмотреть, что лежит в stage» - вариант рабочий. Для основного контура - нет.

Зона 4. BI

Apache Superset, Metabase, Power BI Report Server (там, где он лицензионно доступен) или любой другой инструмент визуализации, привычный команде. Дашборды строятся на широких таблицах ClickHouse без runtime-джойнов, поэтому работают с приличной скоростью.

С BI-инструментом обычно меньше всего архитектурных дискуссий - выбирается тот, что уже есть в компании или с которым удобнее работать аналитической команде.

Где здесь место классических методологий

Если вы читали учебники по DWH в нулевых-десятых, в голове осели три имени: Билл Инмон, Ральф Кимбалл, Дэн Линстедт. Каждый предложил свою методологию, каждая была своевременной для своей эпохи. И каждая в 2026-м году сдала позиции - где-то полностью, где-то частично.

Inmon: Corporate Information Factory

Инмон в девяностых предлагал жёсткое сверху-вниз. Сначала рисуем enterprise-data-model в третьей нормальной форме. Потом из неё нарезаются предметные витрины. Долго, дорого, методично.

Что устарело?

Сама постановка задачи. Допущение, что предприятие можно полностью смоделировать перед началом работы, в современных условиях не выдерживает критики. Бизнес-требования меняются быстрее, чем заканчивается фаза моделирования. Проекты «полгода рисуем enterprise-модель, потом начинаем писать ETL» сегодня просто не закажут.

Плюс физика. 3NF в аналитической нагрузке на современных колоночных движках - катастрофа. Каждый JOIN превращается в лишний overhead, который можно было бы устранить заранее, на этапе подготовки stage.

Где Инмон ещё жив? В банках и регулируемых отраслях с огромным наследием enterprise-моделирования. Там это уже не методология, а инвестиция в моделирование, которую невыгодно списывать.

Kimball: dimensional modeling и star schema

Кимбалл в те же годы зашёл с другой стороны. Снизу-вверх, инкрементально. Conformed data marts. Звёздная схема: факты + измерения. Surrogate keys, slowly changing dimensions.

Тут картина более тонкая. Кое-что от Кимбалла остаётся живым, кое-что - нет.

Звёздная схема как физический паттерн под колоночные движки устарела. Она была вылеплена под row-based реляционные DWH (Oracle, Teradata, MS SQL Server до Columnstore-индексов), где runtime-джойн был дешевле, чем хранить дубли. На колоночных движках выигрыш звёздной схемы либо отсутствует, либо отрицательный. Поэтому в современных архитектурах stage отдаёт уже широкие денормализованные таблицы, движок не делает runtime-джойны вообще.

Но dimensional modeling как способ думать совершенно жив. SCD2-история, surrogate keys, разделение фактов и измерений как логических сущностей - всё это здравый смысл, который никуда не делся. У нас в stage SCD2 присутствует, разделение факт/измерение присутствует. Просто физическое развёртывание - не звёздная схема, а денормализованная wide-таблица.

Так что точнее говорить так: Кимбалл-как-методология-моделирования жив, Кимбалл-как-физический-паттерн устарел.

И отдельная проблема Кимбалла, про которую обычно молчат - conformed dimensions как организационная дисциплина. Они работают пока команда дата-инженеров маленькая и сидит в одном офисе. Как только над разными доменами работают разные команды - conformity начинает плыть. Через год у вас три разных определения «активный клиент» в трёх разных витринах. Это не вина Кимбалла. Это вина реальности, в которой бизнес меняется быстрее, чем dimension governance.

Data Vault 2.0

Линстедт в десятые предложил радикально иное. Hubs (бизнес-ключи). Links (связи между хабами). Satellites (атрибуты с историей). Insert-only loads. Audit-trail из коробки. Параллельная загрузка как архитектурный принцип.

Где DV 2.0 силён? В очень крупных предприятиях. Банки с десятками источников и регуляторными требованиями к полному audit-trail. Страховые с многолетней историей изменений полисов и претензий. Фарма с регуляторкой на уровне FDA. Там Hub/Link/Satellite-структура реально решает проблемы, которые без неё пришлось бы изобретать заново и менее системно.

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

Первое - сложность объектов. Каждое логическое понятие источника превращается в три-пять физических таблиц. Десяток источников превращается в две-три сотни таблиц в схеме. Поддерживать это - отдельная работа, которая никак не приближает к ответу на бизнес-вопрос.

Второе и более фундаментальное. DV 2.0 делает работу моделирования дважды. Сначала вы строите Raw Vault. Потом, поскольку запросы к Raw Vault для аналитика непригодны, вы строите Information Marts поверх него. А Information Marts - это, по сути, тот же Кимбалл в чуть свежей упаковке, или денормализованные wide-таблицы. То есть на каждый бизнес-сценарий вы делаете моделирование дважды, для двух слоёв.

Промис «agility» работает на масштабе огромных предприятий с параллельными ETL-командами. На меньших масштабах добавляет трения, не снижая.

Так что критика «избыточен и сложен» в среднем сегменте - справедлива. Везде - нет: в энтерпрайзе он на своём месте.

А наша четырёхзонная архитектура - откуда?

Стоит честно признать: то, что мы делаем - не «новая методология». Это сборка из правильных кирпичей под column-store-эру.

Похожие паттерны в индустрии называли по-разному. Databricks упаковали это как Medallion architecture: bronze (сырые данные) → silver (очищенные и обогащённые) → gold (готовые витрины). dbt-коммьюнити говорит про modern data stack: sources → staging → intermediate → marts. Логически очень близко к нашему pre-stage / stage / ClickHouse-витрина.

В чём специфика нашей реализации?

Во-первых, явный serving-layer на ClickHouse как отдельный движок. Medallion обычно остаётся внутри одной платформы - всё в Spark или всё в Databricks. Мы выносим финальную BI-витрину в специализированный движок, потому что для пользовательской нагрузки колоночный engine с миллисекундным откликом качественно лучше, чем универсальный SQL-engine.

Во-вторых, обязательная SCD2-дисциплина в stage. Многие команды забывают про неё в Medallion-стеке и через год получают отчёты, которые «вдруг перестали биться» с историческими данными. Мы выносим SCD2 в обязательные требования к stage. Это, может быть, главное наследие Кимбалла, которое мы сохраняем.

В-третьих, Trino как обязательный SQL-движок, не Spark и не DuckDB. Spark тяжёлый и требует отдельной экспертизы JVM-стека. DuckDB single-node, не масштабируется. Trino даёт правильный баланс масштабируемости и операционной простоты для среднего сегмента.

Что не делать

Несколько типичных ошибок, которые мы наблюдали в проектах коллег и собственных пилотах.

Не строить lakehouse без serving-layer. Iceberg + Trino без ClickHouse сверху работают только для команды аналитиков 5-15 человек. Под пользовательской нагрузкой 100+ конкурентных дашбордеров одиночный Trino-кластер начинает захлёбываться. Если кто-то продаёт «дашборды прямо из Iceberg на тысячу пользователей» - закладывайте ClickHouse, иначе получите проблему.

Не строить аналитику прямо из боевой OLTP. Power BI или Apache Superset с прямым подключением к боевой MS SQL Server / Oracle / PostgreSQL - типичный «MVP», который потом годами не могут переделать на нормальную архитектуру. Под аналитической нагрузкой OLTP начинает терять перформанс, локи разрастаются, transaction log пухнет. Лечится только построением отдельного аналитического слоя.

Не использовать 3NF в аналитике. Если вы в 2026 году в stage держите нормализованные таблицы и собираете их в JOIN на лету для каждого дашборда - вы платите перформансом за привычку. Денормализация на этапе stage окупается на каждом запросе из ClickHouse.

Не путать pre-stage и stage. Pre-stage - сырьё для технических манипуляций, аналитики там экспериментируют, инженеры готовят данные. Дашборды строить напрямую из pre-stage - грубая ошибка: пользователи увидят сырые данные источника со всеми его странностями, без бизнес-обогащения, без SCD2-истории. Pre-stage не предназначена для бизнес-потребления.

Не строить Data Vault 2.0 для среднего бизнеса. Если у вас десяток-два источников и команда меньше пятидесяти человек, DV 2.0 - методология не вашего размера. Раздутые объёмы схем, двойная работа моделирования, повышенный порог входа для новых инженеров. Архитектура должна соответствовать размеру задачи.

Не пытаться использовать ClickHouse как замену Trino поверх Iceberg. В маркетинговых материалах ClickHouse 25.x подаётся как «можем читать Iceberg напрямую, больше не нужен Trino». На практике в этой роли ClickHouse не дозрел: чтение V1/V2 базовых случаев работает, equality deletes не поддерживаются, distributed reads нет, запись experimental. Для ad-hoc-запросов аналитика - годится. Для основного pipeline’а - нет.

Резюме

Шпаргалка для самопроверки, какой паттерн уместен в каком сценарии:

• Аналитический слой внутри существующей OLTP - если данные в одной системе, пользователей до сотни, нет требований к real-time. Большая часть среднего бизнеса в России - именно здесь. Колоночные индексы в MS SQL Server, In-Memory Column Store в Oracle, материализованные представления, выделенная схема analytics с агрегатными таблицами. Сроки - недели, не месяцы.

• Четырёхзонная архитектура с Iceberg + Trino + ClickHouse - если есть несколько источников, или нагрузка пользователей выше сотни, или real-time-аналитика. Наш «средний и крупный тир» Data Warehouse, типичный проект на 3-6 месяцев.

• Iceberg + Trino + ClickHouse + дополнительные движки (Spark, dbt) - крупный сегмент, десятки терабайт, multi-engine-сценарии. Корпоративный уровень, проект от 40 000 EUR.

• Data Vault 2.0 - очень крупные предприятия с регуляторными требованиями к audit-trail. В среднем сегменте не нужен.

Что мы стараемся не делать - это продавать клиенту lakehouse там, где можно решить задачу на его существующей базе. Или продавать классическую звёздную схему туда, где работает денормализованная stage. Или строить четырёхзонную архитектуру для бизнеса, у которого один источник и десять читателей.

Архитектура должна соответствовать масштабу задачи. Это, как сказали бы старые DBA, и есть здравый смысл.

Если у вас стоит вопрос «что строить» - расскажите про ваш кейс. Поговорим, что подходит именно вам.