Привет, Хабр! Выбор между lakehouse и классическим хранилищем остается проблемой не первый год, но к 2026-му накопилось достаточно опыта, чтобы говорить предметно. Разберём, как эти архитектуры устроены под капотом, где каждая реально сильна и почему универсального ответа до сих пор нет.
Как устроен warehouse изнутри
Классический warehouse — это вертикально интегрированная система. Хранение и вычисления живут вместе, данные лежат в проприетарном колоночном формате, оптимизированном под конкретный движок. Snowflake хранит данные в своём формате FDN, Redshift использует собственные колоночные структуры, BigQuery держит данные в Capacitor.
Такая связка даёт серьёзные фичи для аналитических запросов. Движок точно знает, как данные разложены на диске, какие есть статистики по колонкам, где лежат min/max значения для pruning. Query optimizer использует эту информацию на полную: пропускает ненужные партиции, читает только запрошенные колонки, применяет predicate pushdown до уровня отдельных блоков.
Отсюда же главный недостаток — vendor lock-in в чистом виде. Данные в проприетарном формате на инфраструктуре вендора. Хочешь переехать с Snowflake на BigQuery — выгружай всё через COPY INTO, перекладывай в GCS, загружай заново. На петабайтных объёмах это проект на месяцы.
Вторая проблема — стоимость хранения. Вендоры берут $20-40 за терабайт в месяц за managed storage. Звучит не страшно, пока данных мало. Но warehouse провоцирует хранить всё: сырые данные, промежуточные таблицы, версии витрин, исторические снапшоты. На 500 TB это уже $10-20K в месяц только за хранение, без учёта compute.
Как устроен lakehouse
Lakehouse разделяет storage и compute. Данные лежат на объектном хранилище (S3, GCS, ADLS) в открытых форматах — Parquet или ORC. Поверх работает табличный формат: Delta Lake, Apache Iceberg или Apache Hudi. Этот слой добавляет то, чего не хватает голому object storage — транзакции, схемы, версионирование.
Табличный формат — это по сути набор JSON/Avro-файлов с метаданными плюс манифесты, описывающие какие Parquet-файлы входят в текущую версию таблицы. Когда происходит запись, создаются новые data-файлы и новый манифест. Старые файлы не удаляются сразу — это даёт time travel и возможность отката.
Iceberg, например, хранит metadata tree: metadata file указывает на manifest list, тот на manifest files, а они уже на конкретные data files. При чтении движок сначала читает metadata, применяет partition pruning и min/max фильтры из манифестов, и только потом идёт в нужные Parquet-файлы. Схема работает, но требует аккуратного управления — слишком много мелких файлов убивают производительность.
Главный профит — данные ваши. Лежат на вашем S3 в открытом формате. Читать можно чем угодно: Spark, Trino, Athena, DuckDB, pandas через pyarrow. Вендор compute-слоя не устраивает — меняешь на другой без миграции данных. Databricks подорожал — переключаешься на EMR или Starburst.
Стоимость хранения на S3 — $23 за терабайт в месяц для Standard, $12.5 для Intelligent-Tiering, копейки для Glacier. Разница с managed warehouse storage в 10-20 раз. На больших объёмах это сотни тысяч долларов в год.
Где warehouse хорош
Warehouse бьёт lakehouse в сценариях интерактивной аналитики. Когда BI-аналитик дёргает дашборд или пишет ad-hoc запрос в SQL-редакторе, ему нужен ответ за секунды. Warehouse заточен под это: горячие данные в кэше, оптимизатор знает структуру до последнего байта, результаты частых запросов материализуются автоматически.
Попробуйте добиться того же на Trino поверх Iceberg. Можно, но придётся повозиться: настроить кэширование на воркерах, правильно разложить данные по партициям, сделать compaction чтобы файлы были нужного размера, возможно поднять отдельный слой типа Starburst Galaxy. В итоге получите сравнимую производительность, но потратите недели инженерного времени.
Второе преимущество — зрелость экосистемы для BI. Looker, Tableau, Power BI годами затачивались под работу с warehouse. Подключение к Snowflake — это ввести credentials и выбрать таблицы. Подключение к lakehouse часто требует промежуточного слоя, настройки драйверов, разбирательств с аутентификацией через IAM roles.
Третье — операционная простота. Warehouse это managed service в полном смысле. Не надо думать про размер файлов, compaction jobs, vacuum операции, количество манифестов. Вендор делает это за вас. Для команды из трёх человек, где нет выделенного platform engineer, это существенный аргумент.
Где lakehouse выигрывает
Lakehouse раскрывается на масштабе и в сценариях за пределами чистого SQL.
Типичная ситуация: данные приходят из Kafka в сыром JSON, их надо распарсить, обогатить, агрегировать, потом скормить ML-пайплайну для обучения модели, а результаты предсказаний положить обратно для аналитики. В warehouse это превращается в цепочку выгрузок: Kafka → S3 → Snowflake → S3 (для ML) → обратно в Snowflake. Каждый переход — это latency, деньги и точка отказа.
В lakehouse всё лежит в одном месте. Spark Streaming пишет в Delta-таблицу, ML-код читает оттуда же через pandas или Ray, предсказания пишутся в соседнюю таблицу, BI-инструмент читает через Trino. Одно хранилище, один формат, никаких перекладываний.
Второй сценарий — мультимодальные данные. Warehouse работает только с таблицами. А если нужно хранить эмбеддинги, feature store, артефакты моделей, сырые логи для дебага, изображения для CV-пайплайна? В lakehouse это просто разные папки на том же S3 с разными форматами. Единая точка доступа, единая система прав, единый каталог.
Третий аргумент — свобода выбора compute. Сегодня используете Databricks, завтра подняли собственный Spark на Kubernetes, послезавтра попробовали DuckDB для локальной разработки. Данные не трогаете вообще. В мире warehouse смена вендора — это миграционный проект.
Реальность 2026: границы размываются
Интересно, что вендоры с обеих сторон движутся навстречу друг другу. Snowflake умеет читать внешние Iceberg-таблицы через External Tables, фактически работая как query engine поверх вашего lakehouse. BigQuery с BigLake делает то же самое. Databricks, наоборот, добавляет Serverless SQL Warehouses, которые по UX неотличимы от классического warehouse.
Iceberg стал точкой конвергенции. Его поддерживают практически все: Snowflake, BigQuery, Athena, Databricks, Trino, Spark, Flink, Dremio. Можно держать данные в Iceberg на своём S3 и подключать к ним разные движки под разные задачи — Trino для интерактивных запросов, Spark для тяжёлых трансформаций, Athena для разовых исследований.
На практике многие приходят к гибридной схеме. Сырые данные и тяжёлые таблицы живут в lakehouse — дёшево, гибко, доступно для ML. Горячие витрины для дашбордов реплицируются в warehouse — быстро, удобно для аналитиков. dbt умеет работать с обоими типами источников, так что пайплайны строятся единообразно.
Как выбирать
Если основные потребители — BI-аналитики с дашбордами и ad-hoc запросами, данных меньше 50 TB, ML-пайплайнов нет или они изолированы, а команда небольшая — берите warehouse. Snowflake или BigQuery развернёте за день, через неделю будет работающая аналитика.
Если данных сотни терабайт, есть ML и data science, форматы разнородные, команда готова инвестировать в платформу — стройте lakehouse. Начните с Iceberg, он сейчас наиболее универсален. Delta Lake хорош, если всё равно планируете Databricks.
Если не уверены — начните с warehouse, но сразу выгружайте сырые данные в S3 в Parquet. Это страховка: если упрётесь в ограничения warehouse, данные уже будут лежать в открытом формате, миграция на lakehouse пройдёт проще.
Если после этой статьи захотелось выбирать архитектуру не по моде, а по ограничениям и SLA, стоит прокачать именно инженерную часть. На курсе Data Engineer разбираем пайплайны (batch/stream), Airflow/Spark/Kafka, хранилища S3/HDFS/ClickHouse и базовые практики качества данных и governance — на практике в облаке. Готовы к серьезному обучению? Пройдите вступительный тест.
Чтобы узнать больше о формате обучения и познакомиться с преподавателями, приходите на бесплатные демо-уроки:
9 февраля, 20:00. «Проектирование Data Vault по набору данных TPC-H с применением dbt и Trino». Записаться
18 февраля, 18:00. «Оркестрация data-pipelines с помощью Prefect». Записаться
Больше открытых уроков смотрите в посте.
