Data Lakehouse: архитектура, применение, плюсы и минусы единого озера данных

Data Lakehouse — архитектура хранения данных, которая объединяет гибкость озера данных и надёжность классического корпоративного хранилища. Проще говоря, «озеро данных» больше не противопоставляется Data Warehouse, а срастается с ним в единую платформу — именно так родился термин Lakehouse.

Data Warehouse даёт быструю и предсказуемую аналитику, но плохо работает с неструктурированными данными и обходится дорого при росте объёма. Data Lake, наоборот, дёшево хранит данные любого формата — от логов до видео, — но без строгой структуры быстро превращается в «болото данных», где сложно что-либо найти и обработать.

Lakehouse решает эту дилемму: организации получают единое хранилище, способное работать и с сырыми данными, и со структурированной отчётностью, без необходимости дублировать инфраструктуру. Такой подход становится всё более востребованным по мере роста объёма данных, которыми оперируют компании, — от логов IoT-устройств до транзакционных записей и результатов работы ML-моделей.

В статье разберём, что такое Lakehouse простыми словами, из чего состоит его архитектура, чем он отличается от Data Warehouse и Data Lake, а также какие преимущества и недостатки стоит учитывать при выборе платформы.

Простыми словами, Lakehouse — это дата-платформа, которая хранит данные в исходном, «сыром» формате, как озеро данных, но при этом поддерживает те же гарантии качества и управляемости, что и корпоративное хранилище.

Термин появился как ответ на ограничения классических подходов. Организации, которые работали с Data Warehouse, сталкивались с высокой стоимостью хранения больших объёмов и невозможностью загружать неструктурированные данные — видео, изображения, JSON-логи. Те же, кто строил Data Lake, получали дешёвое и гибкое хранилище, но теряли в скорости аналитических запросов и в контроле качества данных.

Lakehouse убирает необходимость выбирать. Ключевая идея — добавить в архитектуру озера данных слой метаданных и транзакционности. Например, мы используем как основной табличный формат Apache Iceberg плюс связку StarRocks и Lakekeeper, они приносят в Data Lake возможности, ранее доступные только в DWH:

• поддержку ACID-транзакций;
• версионирование данных;
• контроль схемы (schema enforcement);
• быстрые SQL-запросы поверх сырых файлов.

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

Прежде чем переходить к архитектуре, стоит выделить, чем Lakehouse принципиально отличается от привычного «озера данных» по своим рабочим характеристикам.

Ключевые особенности Data Lakehouse:

• Единый источник данных. Все структурированные и неструктурированные данные организации хранятся в одном месте, что убирает дублирование и рассинхронизацию между системами.
• Поддержка разных форматов. Платформа работает как с таблицами и структурированными записями, так и с логами, изображениями, текстами и потоковыми данными.
• Транзакционная надёжность. Благодаря ACID-транзакциям несколько процессов могут одновременно читать и записывать данные без риска их повреждения.
• Разделение хранения и вычислений. Данные хранятся отдельно от вычислительных ресурсов, что позволяет масштабировать эти компоненты независимо друг от друга и экономить на инфраструктуре.
• Открытые форматы данных. Использование открытых табличных форматов снижает зависимость от конкретного поставщика и упрощает интеграцию с разными инструментами аналитики.
• Governance и безопасность. Централизованное управление доступом, аудит и контроль качества данных на уровне всей платформы, а не отдельных хранилищ.

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

Архитектура Lakehouse строится по слоям, каждый из которых отвечает за свою задачу. Условно её можно разделить на четыре уровня:

1. Слой хранения (Storage Layer). Данные хранятся в объектном хранилище S3 в открытых файловых форматах (например, Parquet или ORC). Это самый дешёвый и масштабируемый уровень, способный вмещать петабайты информации любого типа.
2. Слой метаданных и транзакций (Metadata / Table Format Layer). Поверх файлов добавляется табличный формат — у нас это Apache Iceberg — который отвечает за схему данных, версионирование, ACID-транзакции и историю изменений.
3. Слой вычислений (Compute / Query Engine Layer). Здесь работают движки обработки данных: SQL-аналитика, batch- и потоковая обработка, инструменты для машинного обучения. Благодаря разделению с хранением этот слой можно масштабировать независимо. При этом высокая скорость запросов и вычислений обеспечивается движком с кэшированием, а не только форматом. У нас за эти задачи отвечает наш форк Starrocks — MWS Data Engine.
4. Слой управления и доступа (Governance & Consumption Layer). Отвечает за права доступа, каталогизацию данных, аудит и предоставляет интерфейсы для BI-инструментов, дата-сайентистов и бизнес-пользователей. На этом слое работает открытый REST-каталог Lakekeeper, представляющий собой стандартизированный интерфейс для контроля доступа и управления учётными данными в Iceberg.

Такая многоуровневая архитектура — то, что отличает Lakehouse от обычного озера данных: вместо единого «плоского» хранилища организация получает управляемую платформу с чётким разделением ответственности между слоями.

Чтобы понять, чем Lakehouse отличается от предшественников, стоит рассмотреть все три подхода по отдельности.

Warehouse

Data Warehouse (DWH) — классическое корпоративное хранилище данных, предназначенное для структурированной аналитики и отчётности. Данные в DWH загружаются по строгой схеме (ETL-процесс), проходят предварительную очистку и трансформацию перед попаданием в хранилище.

Такой подход обеспечивает высокую скорость и точность запросов, но плохо масштабируется под неструктурированные данные и требует значительных затрат при росте объёма.

Lake

Data Lake — озеро данных, которое хранит информацию в исходном формате без предварительной структуризации. Сюда можно загружать любые данные: таблицы, файлы, изображения, видео, логи устройств.

Главное преимущество — низкая стоимость хранения больших объёмов и гибкость. Главный недостаток — без должного управления Data Lake быстро теряет структуру, и найти нужные данные становится сложно.

Lakehouse

Data Lakehouse объединяет сильные стороны обоих подходов: хранит данные так же гибко и дёшево, как Data Lake, но добавляет транзакционность, контроль схемы и производительность запросов, характерные для Data Warehouse.

Для наглядности — сравнение трёх подходов в таблице:

Как и любой архитектурный подход, Lakehouse решает одни задачи бизнеса лучше, чем другие. Разберём его сильные и слабые стороны.

Преимущества Data Lakehouse:

• Единая платформа для всех типов данных — не нужно поддерживать отдельно DWH и Data Lake.
• Снижение затрат на инфраструктуру за счёт разделения хранения и вычислений и использования недорогого объектного хранилища.
• Более быстрый доступ к актуальным данным для аналитики, BI и машинного обучения без задержек на перенос между системами.
• Гибкость масштабирования — объём хранения и вычислительные мощности растут независимо друг от друга.
• Открытые форматы снижают зависимость от одного поставщика технологий.
• Улучшенное качество данных благодаря контролю схемы и транзакционности на уровне озера.

Недостатки Data Lakehouse:

• Сложность внедрения. Переход на Lakehouse требует пересмотра существующих процессов работы с данными и может занять значительное время.
• Требования к экспертизе команды. Для настройки и поддержки архитектуры нужны специалисты, разбирающиеся и в дата-инженерии, и в аналитике.
• Зрелость инструментов. Экосистема вокруг открытых табличных форматов продолжает развиваться, поэтому требуют экспертизы по настройке compute-движка и кэширования.
• Риск накопления неструктурированных данных без должного governance, если процессы управления данными выстроены недостаточно строго.

При грамотном подходе к внедрению преимущества, как правило, перевешивают сложности перехода — особенно для организаций, которые работают с большими и разнородными объёмами данных.

Lakehouse-подход находит применение в самых разных отраслях — везде, где бизнесу нужно объединять данные из множества источников и оперативно превращать их в решения.

• Ритейл. Объединение данных о продажах, поведении покупателей на сайте, остатках на складах и рекламных кампаниях в одной платформе позволяет строить персонализированные рекомендации и точнее прогнозировать спрос.
• Финансовый сектор. Банки и финтех-компании используют Lakehouse для анализа транзакций в реальном времени, скоринга клиентов и выявления мошеннических операций — здесь критична и скорость обработки, и надёжность данных.
• Телеком. Операторы связи консолидируют логи сетевого оборудования, данные биллинга и обращения клиентов, чтобы прогнозировать нагрузку на сеть и снижать отток абонентов.
• Промышленность и IoT. Данные с датчиков оборудования поступают в огромных объёмах и в разных форматах — Lakehouse позволяет хранить их централизованно и применять для предиктивного обслуживания техники.
• Машинное обучение и AI. Дата-сайентисты получают доступ к сырым данным напрямую, без промежуточных выгрузок, что ускоряет обучение и обновление моделей.

На российском рынке организации всё чаще выбирают готовые платформенные решения для развёртывания Lakehouse-архитектуры — например, MWS Data Lakehouse, — вместо того чтобы собирать инфраструктуру из отдельных компонентов самостоятельно. Это позволяет сократить время на запуск и снизить нагрузку на внутреннюю команду дата-инженеров.

Подход к хранению и обработке данных продолжает меняться, и Lakehouse-архитектура развивается вместе с рынком. Среди основных тенденций можно выделить следующие.

1. Рост популярности открытых табличных форматов. Delta Lake, Apache Iceberg и Apache Hudi становятся отраслевым стандартом, что снижает зависимость организаций от конкретных вендоров.
2. Сближение с AI-инфраструктурой. Lakehouse всё чаще становится основой не только для BI-аналитики, но и для обучения и запуска моделей машинного обучения и генеративного AI напрямую поверх единого хранилища.
3. Усиление governance и управления качеством данных. По мере роста объёма данных организации инвестируют в каталогизацию, контроль доступа и отслеживание происхождения данных (data lineage).
4. Развитие managed-решений в облаке. Всё больше компаний переходят на управляемые облачные платформы, которые берут на себя администрирование инфраструктуры, оставляя команде фокус на работе с данными, а не на поддержке серверов.
5. Стандартизация метаданных между платформами. Развитие открытых каталогов метаданных упрощает перенос данных между разными вычислительными движками без потери контроля над структурой.

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