В 2021 году Databricks ввели в моду термин «lakehouse», и индустрия дружно решила, что это и есть будущее. Аналитики писали восторженные статьи о том, что классические DWH мертвы. Вендоры спешно проводили ребрендинг своих продуктов, а на конференциях обещали единую архитектуру, которая решит вообще любые проблемы с данными.
Некоторые обещания Lakehouse сбылись. Другие оказались лишь маркетингом. А еще всплыли проблемы, которых никто не ожидал.
В этой статье разберем честный опыт внедрения Lakehouse к 2025 году: какие обещания оказались маркетингом, почему расходы на вычисления часто растут вместо экономии, и как на самом деле выглядит прагматичная работа с Delta Lake, Iceberg и Hudi в современных проектах. Что выжило в продакшене, что тихо скончалось, а о чем принято помалкивать?
Дисклеймер
Возможности вендоров меняются быстро: то, что сломано сегодня, завтра может заработать или будет окончательно заброшено. Поэтому к тому моменту, когда вы читаете эту статью, реальность уже может быть другой.
Что на самом деле обещал Lakehouse
Оригинальная концепция выглядела крайне заманчиво: объединить гибкость дата-лейков с производительностью и надежностью классических хранилищ. Больше никакой поддержки двух раздельных систем. Никакого ETL между слоями хранения. Единая архитектура для всех аналитических задач.
Ключевые обещания (2021–2022)
ACID-транзакции в объектных хранилищах:
Delta Lake, Iceberg и Hudi должны были принести гарантии полноценных баз данных в S3/GCS.
Конец кошмарам с согласованностью в конечном счете.
Табличные форматы должны были «просто работать» как в обычных СУБД.
Производительность BI на уровне дата-лейка:
Скорость выполнения запросов, сопоставимая со специализированными хранилищами.
Аналитики смогут запрашивать данные напрямую из лейка.
Отдельный слой DWH больше не требуется.
Единая обработка батчей и стриминга:
Одни и те же таблицы для обоих типов нагрузки.
Стриминговая запись, батчевое чтение и никаких барьеров.
Лямбда-архитектура наконец-то мертва.
Экономия за счет конвергенции:
Устранение дублирования данных в DWH и лейке.
Одна платформа вместо двух.
Разделение compute и storage по ценам обычного объектного хранилища.
Безболезненная эволюция схем:
Добавление колонок без необходимости перезаписывать все данные.
Автоматическая обработка дрейфа схемы.
Встроенная обратная совместимость.
Что произошло на самом деле: светлая сторона
ACID-транзакции в целом состоялись
Это действительно работает. Delta Lake, Iceberg и Hudi обеспечивают надежные ACID-гарантии поверх объектных хранилищ. Три года использования в проде подтвердили, что это не пустышка. Ритейл-компания обрабатывает по 500 миллионов транзакций в день через Delta Lake на S3. Параллельное чтение и запись работают стабильно. Ролбэки спасают от кривых записей. Time travel запросы позволяют обращаться к историческим версиям. Обещания соблюдаются.
Один финтех перешел с ночных загрузок в хранилище на непрерывные обновления в Delta Lake. Аналитики работают с актуальными данными и не видят промежуточных состояний записи. ACID здесь - свершившийся факт.
Где всё ломается: Высокочастотные обновления все еще даются с трудом. Попытки обновлять отдельные записи тысячи раз в секунду быстро упираются в лимиты. Накопление мелких файлов становится головной болью для администрирования. Задачи по компакции данных - это неизбежные накладные расходы, которые классические хранилища обычно берут на себя незаметно для пользователя.
В одном стриминговом приложении генерировалось больше 100 тысяч мелких Parquet-файлов в день. Скорость запросов падала, пока не внедрили агрессивную компакцию. ACID работает, но за «гигиеной» данных нужно следить.
Вердикт: ✅ Базовый функционал доставлен. Не идеально, но для продакшена годится.
Экономия на больших объемах «холодных» данных
Объектные хранилища обходятся значительно дешевле, чем хранение внутри DWH. Для исторических данных, которые запрашиваются редко, лейкхаусы действительно позволяют прилично сэкономить.
Цифры:
Хранение в Snowflake: ~$40/ТБ/месяц (со сжатием)
S3 Standard: ~$23/ТБ/месяц
S3 Intelligent-Tiering: ~$15/ТБ/месяц (через 30 дней)
S3 Glacier Instant Retrieval: ~$4/ТБ/месяц
Для компании с 500 ТБ исторических данных:
Только DWH: $20 000 в месяц за хранени��
Lakehouse (горячие + холодные уровни): $8 000 в месяц за хранение
Экономия: $144 000 в год
Например: Один e-commerce проект перенес историю заказов старше трех лет в Delta Lake. Расходы на DWH упали на 40%. Скорость выполнения запросов для исторического анализа осталась на приемлемом уровне. Финансовый отдел был в восторге.
Где это не работает: Если данные нужны часто, затраты на вычисления «съедают» всю экономию на хранении. Запросы к данным в лейкхаусе обходятся дороже аналогичных в DWH из-за оверхеда на ввод-вывод в объектном хранилище и специфики форматов.
Одна компания перевела вообще все данные в лейкхаус в надежде сэкономить. В итоге их счета за вычисления выросли в 2.5 раза. Было неловко, но горячие данные пришлось возвращать обратно в классическое хранилище.
Вердикт: ✅ Реальная экономия на холодных данных. ⚠️ Обратный эффект на горячих данных.
Эволюция схем стала лучше (но есть нюансы)
Добавление колонок без полной перезаписи таблиц теперь действительно работает. Delta Lake и Iceberg изящно справляются с аддитивными изменениями схемы. Это заметный шаг вперед по сравнению с традиционными дата-лейками.
Что улучшилось:
Раньше: добавление колонки означало либо перезапись всей таблицы, либо создание новой партиции.
Сейчас: добавление колонки — это операция на уровне метаданных. Существующие файлы просто возвращают NULL для новой колонки.
Например: Рекламная компания ежемесячно добавляет по 5–10 новых свойств для событий. Эволюция схем позволяет им делать это, не переписывая пайплайны обработки данных.
Где наступает разочарование: Смена типов данных в колонках все еще доставляет боль. Переименование колонок реализовано коряво. Удаление колонок оставляет «данные-призраки». А изменения в сложных вложенных схемах — это вообще отдельный вид мучений.
Одна команда пыталась сменить тип колонки со STRING на INTEGER в проде. «Бесшовная» миграция на деле потребовала:
Создания новой колонки
Бэкфилла данных
Обновления всех запросов
Объявления старой колонки устаревшей
Ручной зачистки
Не совсем та легкая эволюция, которую нам обещали.
Вердикт: ✅ Стало лучше, чем было. ⚠️ Но это не магия.
Производительность BI так и не сравнялась с хранилищами
Это было ключевое обещание, которое в итоге не сбылось. Производительность BI в лейкхаусах отстает от специализированных хранилищ настолько, что это действительно имеет значение.
Сравнение производительности (один и тот же запрос, таблица фактов на 1 ТБ и 100 млн строк):
Snowflake (хранилище): 2.3 секунды BigQuery (хранилище): 1.8 секунды Databricks (лейкхаус): 8.7 секунды Athena (лейкхаус): 12.4 секунды Trino на Iceberg: 15.2 секунды
Этот разрыв сохраняется на самых разных типах нагрузки. Агрегации, джойны, сложная аналитика - хранилища стабильно побеждают.
Почему сохраняется этот разрыв Хранилища оптимизированы именно под BI-нагрузки:
Проприетарные колоночные форматы, заточенные под паттерны запросов.
Кэширование результатов на нескольких уровнях.
Материализованные представления и автоматическая оптимизация.
Компиляция запросов и эвристики оптимизации, которые оттачивались десятилетиями.
Лейкхаусы же запрашивают обычный Parquet в объектном хранилище:
Оверхед формата при каждом запросе.
Задержки объектного хранилища (даже на высокопроизводительных уровнях).
Менее зрелая оптимизация запросов.
Ограниченные возможности кэширования.
Например: Медиа-компания попыталась перевести свои BI-задачи на лейкхаус Databricks. Время загрузки дашбордов выросло с 3 до 12 секунд. Пользователи начали жаловаться. Финансовый отдел подготовил расчеты, и в итоге они вернулись на Snowflake для горячих данных, оставив лейкхаус только для холодных.
Многие компании пошли по тому же пути: хранилище для BI, лейкхаус для всего остального.
Вердикт: ❌ Разрыв в производительности BI остается значительным.
Обещания про единый стриминг и батчинг оказались преувеличены
Стриминговая запись в таблицы лейкхауса работает. Но та самая «единая» часть остается скорее мечтой, чем реальностью.
Что происходит на практике: Системы стриминга постоянно пишут мелкие файлы. Это порождает:
Взрыв метаданных (тысячи файлов на одну таблицу).
Деградацию производительности запросов.
Потребность в агрессивной компакции данных.
Рост расходов на хранение из-за оверхеда мелких файлов.
Стандартная схема работы:
Стриминг событий в Kafka (или Kinesis, Pub/Sub).
Использование Spark Structured Streaming для записи в Delta Lake.
Запуск ежечасных задач компакции для объединения мелких файлов.
Мониторинг количества файлов и запуск экстренной компакции при необходимости.
Еженедельная оптимизация таблиц для поддержания скорости запросов.
Это работает, но это не «единый процесс». Это два разных паттерна, требующих тщательной координации.
Где всё ломается: Аналитические запросы с низкой задержкой к стриминговым таблицам даются с трудом. Свежие данные разбросаны по множеству мелких файлов. Запросы вынуждены сканировать их все. Производительность падает линейно в зависимости от количества файлов.
Одно приложение для real-time аналитики пыталось запрашивать Delta Lake с задержкой данных менее 5 минут. Время выполнения запросов выросло с 2 до 45 секунд по мере накопления мелких файлов. В итоге разработчики добавили PostgreSQL в качестве сервисного слоя для быстрых запросов, что убило саму идею «единой архитектуры».
Вердикт: ⚠️ Работает при тщательной настройке. Но это не та бесшовная унификация, которую обещали.
Мечты о полной замене DWH разбились
Лишь единицы компаний реально избавились от своих классических хранилищ. Большинство пришло к связке «хранилище + лейкхаус», а не к замене одного другим.
Типичная архитектура в продакшене (2025):
Лейкхаус (Delta, Iceberg, Hudi): - Исторические данные (старше 6 месяцев). - Задачи Data Science и ML. - Ад-хок исследования. - Сырые и стейджинг-данные. Хранилище (Snowflake, BigQuery, Redshift): - Актуальные данные (последние 6 месяцев). - BI-дашборды и отчеты. - Селф-сервис запросы аналитиков. - Отчетность для руководства.
Почему конвергенция не случилась: Разрыв в производительности критичен для бизнес-задач. Экосистемы вендоров (особенно BI-инструменты) лучше оптимизированы под коннекторы к хранилищам. Перенос работающих дашбордов требует слишком много ресурсов и политической воли. Организации, избегающие рисков, предпочитают придерживаться проверенных решений.
Реальная история миграции: Медицинская компания планировала полный переход на лейкхаус Databricks. Спустя 18 месяцев:
Успешно мигрировали 80% задач дата-инженерии.
Перенесли 30% задач BI (в основном новые дашборды).
Оставили 70% существующего BI в Snowflake.
Приняли гибридную архитектуру как постоянную.
«Миграция» превратилась в «интеграцию».
Вердикт: ❌ Массового отказа от DWH не произошло.
Проблемы, которых никто не ожидал
Сложность управления данными и контроля доступа
Управление доступом в лейкхаусе оказалось сложнее, чем в классическом хранилище. У файлов в объектном хранилище просто нет встроенного контроля доступа на уровне базы данных.
Управление в DWH (просто):
GRANT SELECT ON sales_data TO analyst_role;
Управление в лейкхаусе (сложно):
IAM-политики для доступа к бакетам S3 или GCS.
Разрешения на уровне таблиц в каталоге лейкхауса.
Безопасность на уровне строк через вьюхи или фильтры.
Маскирование колонок с помощью сторонних инструментов.
Логирование аудита на нескольких уровнях сразу.
Постоянная проверка: совпадают ли права в каталоге с правами на физическое хранилище.
Реальный случай: Компания внедрила права на уровне таблиц в Unity Catalog. Аналитики не могли делать запросы. Расследование показало:
Права в каталоге настроены верно.
IAM-политики бакета S3 не давали доступа.
Учетные данные для доступа к хранилищу требовали обновления.
На решение проблемы ушло две недели и куча тикетов в поддержку.
Более того, пользователи с прямым доступом к S3 могли вообще обходить права каталога, просто читая Parquet-файлы напрямую. В модели безопасности зияли дыры.
Реакция вендоров: Unity Catalog от Databricks и похожие инструменты пытаются унифицировать управление. Это помогает, но добавляет новые слои сложности. Чтобы все настроить правильно, нужно разбираться в устройстве сразу нескольких систем.
Вердикт: ⚠️ Сложнее, чем ожидали. Ситуация улучшается, но до окончательного решения еще далеко.
Накопление мелких файлов
Это превратилось в операционный кошмар, о котором на старте предупреждали недостаточно часто.
Стриминговая запись постоянно генерирует мелкие файлы. Эволюция схем создает новые группы файлов. Упавшие задачи оставляют после себя фрагменты данных. В итоге количество файлов растет лавинообразно.
На что это влияет:
Увеличивается время планирования запроса (нужно получить список из тысяч файлов).
Растут расходы на объектное хранилище (из-за минимального объема тарификации за файл).
Замедляются операции с метаданными.
Задачи компакции начинают потреблять слишком много ресурсов.
Реальные цифры: Таблица с 10 ТБ данных может содержать:
Идеал: 10 000 файлов по 1 ГБ каждый.
Реальность через полгода: 500 000 файлов средним размером 20 МБ.
Листинг 500 тысяч файлов занимает больше 30 секунд. В итоге планирование запроса начинает занимать больше времени, чем само его выполнение.
Стратегии борьбы:
Агрессивные графики компакции (дополнительные расходы на вычисления).
Прунинг партиций (ограничивает гибкость запросов).
Регулярные операции OPTIMIZE (риски блокировок).
Мониторинг метрик количества файлов.
Экстренная компакция при превышении пороговых значений.
Подход одной из компаний:
Ежечасная компакция (уплотнение) для стриминговых таблиц.
Ежедневная оптимизация для батчевых таблиц.
Еженедельная полная оптимизация всех таблиц.
Алерт, если количество файлов превышает 10 тысяч на одну партицию.
Этих операционных накладных расходов не было в оригинальных маркетинговых обещаниях лейкхауса.
Вердикт: ⚠️ Значительная операционная нагрузка. Требует отдельного внимания и ресурсов.
Фрагментация совместимости между движками
Обещание: пишем один раз через Delta Lake, а читаем через Spark, Trino, Presto, Athena, Dremio и что угодно еще. Реальность: совместимость действительно есть, но поддержка конкретных функций сильно разнится от движка к движку. Матрица совместимости (начало 2025 года):
✅ = полная поддержка, ⚠️ = частичная, ❌ = отсутствует
Функция | Spark | Trino | Athena | Dremio |
|---|---|---|---|---|
Базовое чтение | ✅ | ✅ | ✅ | ✅ |
ACID-запись | ✅ | ⚠️ | ❌ | ⚠️ |
Time travel | ✅ | ✅ | ❌ | ✅ |
Эволюция схем | ✅ | ⚠️ | ⚠️ | ⚠️ |
Merge и Upsert | ✅ | ❌ | ❌ | ⚠️ |
Векторы удаления | ✅ | ❌ | ❌ | ❌ |
Реальные проблемы: Компания использовала Spark для записи данных, так как там есть полная поддержка Delta Lake, а для ad-hoc запросов выбрала Athena в целях экономии. Выяснилось, что Athena не может читать таблицы, использующие новые фичи Delta Lake. В итоге пришлось либо отказываться от свежих возможностей формата, либо смириться с несовместимостью. Другая команда использовала Trino для кросс-платформенных запросов. Операции MERGE в Delta Lake там не поддерживались. Им пришлось писать кастомные Spark-задачи для апсертов, а Trino переводить в режим «только чтение». Реакция вендоров: Для решения этих проблем в Delta Lake создали «универсальный формат» (UniForm). У Iceberg поддержка со стороны разных движков шире, но меньше продвинутых функций. У Hudi на данный момент самая узкая экосистема. Обещание открытого табличного формата сбылось лишь частично: базовая переносимость данных работает, но до паритета функций между движками еще далеко.
Вердикт: ⚠️ Базовая переносимость работает. Продвинутые функции фрагментированы.
Нестыковка dbt и рабочих процессов
dbt стал стандартом для аналитической инженерии, но его подходы плохо ложатся на архитектуру лейкхаусов.
В чем проблема dbt ожидает:
Материализованные представления или таблицы внутри хранилища.
Быстрые инкрементальные модели с операциями merge.
Стабильную производительность запросов.
Простые DDL-операции.
Лейкхаусы предлагают:
Файлы в объектном хранилище со слоем метаданных.
Медленные операции merge (особенно на больших объемах).
Плавающую производительность запросов.
Сложные требования к оптимизации.
Основные точки трения
Медленная работа инкрементальных моделей: они полагаются на merge и upsert. В архитектуре лейкхаусов эти операции обходятся дорого: нужно прочитать всю таблицу, найти обновления и перезаписать партиции.
Пример одной команды: инкрементальная модель в Snowflake отрабатывала за 45 секунд, в лейкхаусе Databricks - за 8 минут.
Конфликты оптимизации: dbt часто пересобирает таблицы целиком. Для производительности лейкхауса критически важна стабильная структура файлов, а постоянные пересборки сводят все попытки оптимизации на нет.
Тестирование и качество данных: тесты dbt запускают множество повторных запросов. Каждый из них платит «налог» на ввод-вывод в объектном хранилище. В итоге тестовые наборы, которые летали в классических хранилищах, становятся медленными и дорогими.
Как выкручиваются компании:
Используют классическое хранилище для dbt-моделей, а лейкхаус только для сырых данных.
Пишут специфичные для лейкхаусов dbt-макросы и паттерны.
Смиряются с более медленными циклами разработки.
Гибридный подход: dbt живет в хранилище, а в лейкхаусе выстраивают медальонную архитектуру.
Databricks добавили специфические оптимизации под dbt, а в dbt-core подтянули производительность адаптеров для лейкхаусов. Разрыв сократился, но не исчез.
Вердикт: ⚠️ dbt работает, но требует адаптации. Это не тот бесшовный опыт, к которому привыкли пользователи классических хранилищ.
Войны табличных форматов
Концепция лейкхаусов разделилась на три конкурирующих формата: Delta Lake, Apache Iceberg и Apache Hudi. Спустя три года на рынке сформировались четкие паттерны.
Delta Lake: привязка к Databricks
Позиция на рынке, что это самый зрелый набор функций, мощная поддержка со стороны вендора, но более узкая экосистема.
Преимущества:
Самые продвинутые фичи: векторы удаления, liquid-кластерирование, UniForm.
Лучшая интеграция со Spark.
Отличная документация и большое сообщество.
Интеграция с Unity Catalog для управления доступом.
Недостатки:
Экосистема зациклена на Databricks (несмотря на статус open source).
Поддержка другими движками слабее, чем у Iceberg.
Медленное внедрение за пределами среды Spark и Databricks.
Выбирают компании, которые уже сидят на Databricks или для которых продвинутый функциона�� важнее переносимости. Типичная цитата: «Мы и так платим за Databricks. Delta Lake у нас отлично работает, а совместимость с другими движками нам не особо важна».
Apache Iceberg: ставка на открытую экосистему
Позиция на рынке: широчайшая поддержка движков, растущая популярность, независимость от конкретных вендоров.
Преимущества:
Лучшая совместимость между разными движками.
Независимое управление через Apache Foundation.
Растущая экосистема: поддержка в Snowflake, BigQuery, Starburst и Dremio.
Четкое разделение между форматом данных и движком для их обработки.
Недостатки:
Меньше продвинутых функций по сравнению с Delta Lake.
Инструментарий в некоторых областях еще не до конца созрел.
На определенных нагрузках может уступать в производительности Delta Lake.
Кто выбирает: компании, которые используют несколько разных движков, ценят переносимость или избегают привязки к одному вендору. Типичная цитата: «Мы используем Spark, Trino и Flink. Iceberg — единственный формат, который нормально работает со всеми тремя».
Apache Hudi: специалист по стримингу
Позиция на рынке: нишевый, но сильный игрок для задач с частыми обновлениями.
Преимущества:
Отлично подходит для CDC (захвата изменений данных) и стриминговых апсертов.
Мощные возможности для инкрементальной обработки.
Хорош для создания дата-лейков в реальном времени.
Недостатки:
Экосистема меньше, чем у Delta или Iceberg.
Порог входа выше.
Меньше готовых инструментов и поддержки сообщества.
Кто выбирает: компании с большой нагрузкой по CDC из операционных баз данных или те, кому нужны очень частые апсерты. Типичная цитата: «Мы синхронизируем 50 баз данных через CDC. Режим merge-on-read в Hudi идеально для этого подходит».
Как распределился рынок
Примерные доли рынка на начало 2025 года (на основе метрик GitHub, докладов на конференциях и вакансий):
Delta Lake: ~45–50%
Iceberg: ~35–40%
Hudi: ~10–15%
Iceberg активно набирает долю благодаря поддержке в Snowflake и среди пользователей нескольких движков. Delta Lake сохраняет доминирование в мире Databricks. Hudi уверенно держит свою нишу в стриминге и CDC.
Самый частый сценарий, что компании выбирают один формат и придерживаются его. Архитектуры с использованием нескольких форматов встречаются редко, так как их поддержка то еще удовольствие.
Как продакшен выглядит на самом деле
Медальонная архитектура победила
Схема Bronze → Silver → Gold стала стандартом де-факто для лейкхаусов.
Bronze (сырой слой):
Данные в том виде, в котором они получены из источника.
Минимальные трансформации.
Схема определяется при чтении.
Сохранение полной истории.
Silver (очищенный слой):
Валидированные и очищенные данные.
Приведение к единым форматам.
Удаление дубликатов.
Применение бизнес-ключей.
Gold (агрегированный слой):
Агрегаты на уровне бизнес-логики.
Модели данных по предметным областям.
Оптимизация для конечн��го потребления.
Иногда данные отсюда выгружаются обратно в классическое хранилище.
Почему этот паттерн прижился Он хорошо ложится на этапы зрелости данных. Разные команды могут работать с разными слоями. Любую ошибку легко отследить по цепочке слоев, а ролбэки происходят естественным образом.
Альтернативные подходы, которые провалились:
Подход «одного большого озера»: когда все данные сваливаются в одну кучу без разделения по уровню готовности. Это быстро стало невозможно поддерживать.
Мечты о «виртуализации»: попытки запрашивать сырые данные напрямую через вьюхи с трансформациями. Производительность оказалась неприемлемой.
Вера в «отказ от стейджинга»: попытки трансформировать сырые данные сразу в финальные витрины. Отладка в такой схеме превратилась в ад.
Вердикт: ✅ Медальонная архитектура — это стандарт индустрии.
Гибридные архитектуры стали нормой
Почти ни одна архитектура в проде не является «чистым» лейкхаусом. Прагматичная реальность — это гибрид хранилища и лейкхауса.
Паттерн №1: Разделение по «температуре» данных
Горячие данные (0–6 месяцев): классическое хранилище.
Теплые данные (6–24 месяца): лейкхаус (запрашиваются время от времени).
Холодные данные (старше 2 лет): лейкхаус (редкие запросы, архив).
Паттерн №2: Разделение по типу нагрузки
BI и дашборды: классическое хранилище.
ML и Data Science: лейкхаус.
Ад-хок аналитика: и то, и другое (в зависимости от глубины данных).
Дата-инженерия: лейкхаус.
Паттерн №3: Репликация золотого слоя
Слой Bronze и Silver: только в лейкхаусе.
Слой Gold: копируется и в хранилище, и в лейкхаус.
Копия в хранилище для скорости BI.
Копия в лейкхаусе для исследовательской аналитики и Data Science.
Почему победил гибрид? Требования к производительности сильно зависят от конкретного кейса. Ресурсы на миграцию всегда ограничены, а риск сломать работающий продакшен слишком велик. Прагматизм оказался важнее чистоты архитектуры.
Компании, которые пытались построить «чистый» лейкхаус, в большинстве случаев откатывались назад в течение 12–18 месяцев. Некоторые оставляли лейкхаус для новых проектов, сохраняя старое хранилище для текущих задач. Лозунг «выкинем хранилище» сменился на «интегрируем его в общую экосистему».
Вердикт: ✅ Гибридный подход — это прагматичный выбор по умолчанию.
Расходы на вычисления «съели» экономию на хранении
Маркетинг лейкхаусов во многом строился на дешевизне хранения. Реальность, что для большинства нагрузок затраты на вычисления перекрыли всю выгоду.
Пример структуры расходов (средняя компания, 200 ТБ данных):
Только хранилище (Snowflake):
Хранение: $8 000/мес
Вычисления: $45 000/мес
Итого: $53 000/мес
Гибрид лейкхауса и хранилища:
Хранение в лейкхаусе: $3 000/мес
Хранение в DWH: $2 000/мес
Вычисления в лейкхаусе: $35 000/мес
Вычисления в DWH: $15 000/мес
Итого: $55 000/мес
Экономия: -$2 000/мес (расходы выросли)
Почему вычисления обходятся дороже:
Оверхед на ввод-вывод в объектном хранилище.
Менее эффективная оптимизация запросов.
Частые полные сканирования таблиц (меньше индексов и статистики).
Затраты ресурсов на задачи по уплотнению и оптимизации данных.
Накладные расходы на разработку и тюнинг системы.
Когда экономия действительно заметна:
Преимущественно холодные данные (запрашиваются редко).
Тяжелые батчевые нагрузки (а не интерактивный BI).
Масштабное обучение ML-моделей (где DWH просто непрактичен).
Задачи архивирования.
Вердикт: ⚠️ Экономия на хранении реальна, но часто нивелируется расходами на вычисления.
Экосистема инструментов три года спустя
Что созрело за это время
Системы каталогов:
Unity Catalog (Databricks)
AWS Glue Data Catalog
Polaris (от Snowflake, на базе Iceberg REST)
Nessie (проектный каталог)
Все они предлагают вполне рабочее управление метаданными. Unity Catalog лидирует по количеству фич, но в вопросах совместимости систем друг с другом все еще есть пробелы.
Движки запросов:
Spark: полнофункциональный, нативный для Delta Lake.
Trino/Presto: мощная поддержка Iceberg, подтягивают работу с Delta.
Athena: годится для ад-хок запросов, но слабовата для продакшена.
Dremio: хорошая производительность, но меньшая доля рынка.
Совместимость между движками улучшилась, но паритет функций все еще остается труднодостижимой целью.
Инструменты загрузки данных (Ingestion):
Fivetran добавил коннекторы для лейкхаусов.
Airbyte поддерживает все основные форматы.
dlt предлагает отличную open-source альтернативу.
Spark остается вариантом для самых тяжелых задач.
Большинство инструментов сейчас поддерживают запись в лейкхаус, хотя качество реализации везде разное.
Что осталось на зачаточном уровне
Инструменты качества данных: Great Expectations работает, но требует кастомной настройки. Тесты в dbt справляются, но работают медленно. Специализированные решения для качества данных в лейкхаусах всё еще остаются нишевыми.
Интеграция с BI: большинство BI-инструментов обзавелись коннекторами для лейкхаусов, но производительность всё еще ниже, чем у коннекторов для классических хранилищ. Возможности кэширования и оптимизации ограничены, поэтому многие команды по-прежнему предпочитают DWH для задач BI.
Observability: базовый мониторинг (логи запросов, метрики таблиц) есть, но продвинутые возможности data lineage, анализ влияния изменений, поиск аномалий — фрагментированы. Monte Carlo, Datafold и другие инструменты работают, но они не являются нативными для лейкхаусов.
Data discovery: каталоги дают базовый поиск, но полноценная документация, аналитика использования и «социальные» фичи развиты слабо. В классических хранилищах поиск данных организован всё еще лучше.
Уроки трех лет в проде: советы командам
Не ждите, что лейкхаус заменит хранилище. С первого дня планируйте гибридную архитектуру. Четко определите, какие задачи куда отправятся.
Инвестируйте в обслуживание таблиц со старта. Уплотнение, оптимизация и зачистка данных - это необходимость. Заложите бюджет и время на вычисления и «гигиену» данных.
Выбирайте формат таблицы исходя из экосистемы, а не фич. Delta Lake, если вы живете в мире Databricks. Iceberg, если вам нужна работа с разными движками. Hudi, только если у вас специфические задачи по CDC.
Для BI нужна производительность уровня DWH. Если дашборды критически важны для бизнеса, держите их в хранилище. BI в лейкхаусах становится лучше, но пока не дотягивает.
Управление данными сложнее, чем кажется. Unity Catalog и аналоги помогают, но готовьтесь потратить в 2-3 раза больше усилий, чем на настройку доступа в обычном хранилище.
Маниакально следите за количеством файлов. Накопление мелких файлов убьет производительность. Настраивайте алерты и автоматизацию до того, как это превратится в кризис.
Заложите бюджет на специалистов по лейкхаусам. Хранилища скрывают сложность, лейкхаусы выставляют ее напоказ. Вам нужны инженеры, которые понимают форматы, процессы уплотнения и оптимизацию.
Что сработало лучше, чем ожидалось
Экономия на холодных данных: реальная и ощутимая. Задачи архивирования - это победа лейкхаусов.
Рабочие процессы ML и Data Science: здесь лейкхаус раскрывается во всей красе. Дата-сайентистам нравится работать с Parquet напрямую в объектном хранилище.
Гибкость дата-инженерии: подход schema-on-read и гибкость обработки отлично подходят для разработки ETL/ELT процессов.
Снижение вендор-лока: открытые форматы действительно дают возможность переезда, пусть и с оговорками. Это в любом случае лучше, чем полная привязка к проприетарному хранилищу.
Что сработало хуже, чем ожидалось
Производительность BI: так и не догнала хранилища. Разрыв сокращается, но он всё еще есть.
Операционные расходы: оказались гораздо выше, чем обещали маркетологи. Управление файлами, уплотнение, оптимизация и мониторинг требуют постоянного внимания.
Сроки миграции: частичная миграция обычно занимает 18-24 месяца. Случаи полного отказа от DWH всё еще редки.
Фрагментация экосистемы: совместимость была обещана, но на деле мы получили сильный разброс доступных функций в разных движках.
Честный вердикт
Архитектуры Lakehouse полностью готовы к работе в продакшене. Компании успешно запускают масштабную аналитику на Delta Lake, Iceberg и Hudi.
Но они не заменили классические хранилища, а дополнили их. Само противопоставление «лейкхаус против хранилища» всегда было ложным. Настоящий вопрос в том, какие именно задачи и где стоит решать.
Идеальная аналитическая архитектура 2025 года:
Лейкхаус для:
Исторических и архивных данных.
Задач Data Science и ML.
Разработки пайплайнов данных.
Исследовательского анализа.
Задач, где критически важна стоимость хранения.
Хранилище для:
Бизнес-критичного BI.
Отчетов для руководства.
Высоконагруженной аналитики.
Селф-сервис аналитики.
Запросов, чувствительных к скорости выполнения.
Вместо вывода
Сейчас мы находимся на этапе плато. Лейкхаус - это проверенный паттерн с понятными сценариями использования, а не универсальное решение всех проблем. Компании, которые выбрали гибридный подход, оказались в выигрыше. Те, кто поставил всё на «чистый» лейкхаус, в большинстве своем были вынуждены сменить курс.
Три года спустя архитектура Lakehouse не стала ни революцией, ни провалом. Это зрелый инструмент с изученными сильными и слабыми сторонами. Именно так и должна заканчиваться история любой новой технологии.
На этом всё. Если вам близок такой прагматичный подход к технологиям, то заходите к нам, в ИнженеркаТех. Больше интересных материалов по архитектуре данных, DWH, dbt, Iceberg и всему современному дата-стеку мы публикуем в нашем телеграм-канале
