Lakehouse: архитектура хранилища без выбора меньшего из зол
Что такое lakehouse-подход и когда он решает реальную проблему выбора между data warehouse и data lake.
Когда компания начинает строить аналитическую инфраструктуру, рано или поздно возникает один и тот же выбор: data warehouse или data lake. Первый - структурированный, управляемый, дорогой в изменениях. Второй - гибкий, дешёвый в хранении, но склонный превращаться в болото, если нет строгой дисциплины.
Оба варианта несут свои компромиссы. Lakehouse - это попытка снять этот выбор, взяв лучшее из обоих подходов. В 2024 году этот подход перешёл из категории концептуального к массово доступному. Но как и с любой архитектурной идеей - важно понимать, что именно он решает и когда он нужен.
Где возникает напряжение между warehouse и lake
Data warehouse хорошо работает с хорошо структурированными данными и понятными аналитическими запросами. Он надёжен, управляем, даёт стабильное время запросов. Но он дорог при работе с неструктурированными данными, медленно адаптируется к изменениям схем, и хранить в нём "сырые" данные для будущих задач - дорогостоящее удовольствие.
Data lake позволяет хранить данные в исходном формате, дёшев, гибок. Но без управления превращается в хаос, где никто не понимает, что где лежит, данные дублируются, схемы не согласованы, а производительность аналитических запросов страдает.
На практике многие компании в итоге строили оба: lake для хранения, warehouse для аналитики, и ETL между ними. Это удвоение инфраструктуры, удвоение стоимости, удвоение точек сбоя.
Что такое lakehouse
Lakehouse объединяет хранение данных в открытых форматах (как в lake) с возможностями управления, ACID-транзакций и производительности аналитических запросов (как в warehouse). Ключевые технологии - открытые форматы хранения таблиц вроде Delta Lake, Apache Iceberg, Apache Hudi - позволяют реализовать это поверх обычного облачного хранилища.
Практически это означает: данные хранятся один раз, в открытом формате, но к ним можно применять структурированные операции с транзакционными гарантиями. Аналитический движок, ML-фреймворк и стриминговый процессор могут работать с теми же данными без копирования.
Ключевые возможности, которые это открывает: время путешествия по данным (можно запросить состояние таблицы на любой момент в прошлом), откат изменений, управление схемами с эволюцией без пересоздания.
Когда это решает реальную проблему
Lakehouse имеет смысл в нескольких ситуациях.
Первая: компания платит за два слоя инфраструктуры - lake и warehouse - и хочет их объединить без потери возможностей.
Вторая: данные нужны одновременно для аналитики и для ML-моделей, и сейчас их приходится синхронизировать между двумя местами.
Третья: схемы данных меняются часто, и warehouse-подход создаёт постоянные трудоёмкие миграции.
Четвёртая: объём данных вырос до того уровня, где стоимость традиционного warehouse становится значимой статьёй бюджета.
Когда это ещё преждевременно
Если данных немного и аналитика работает нормально на PostgreSQL или простом cloud warehouse - усложнение не нужно. Lakehouse добавляет операционную сложность: новые форматы, новые инструменты, новые компетенции в команде.
Несколько проверочных вопросов:
- Есть ли у вас сейчас и lake, и warehouse - и вы платите за оба?
- Данные для аналитики и для ML используются из разных мест и синхронизируются вручную?
- Команда сталкивается с медленными или дорогостоящими миграциями схем?
- Есть ли в команде компетенции для работы с открытыми форматами таблиц и Spark/Flink?
Lakehouse - это хорошая архитектурная идея, созревшая до продакшен-готовности. Но хорошая идея без зрелой команды - это источник новых проблем, а не решение старых.