Что такое DATA LAKEHOUSE
Объясняю по-человечески — и почему это не просто «озеро + склад»
Автор: Александр Полоротов
Компания: Datanomix.pro
Время чтения: ~15 мин
Привет, меня зовут Полоротов Александр, co-founder datanomix.pro — и я из тех людей, которые последние несколько лет объясняют крупному бизнесу, зачем им ещё одна дата-платформа. Каждый второй разговор начинается примерно так: «У нас уже есть Oracle, Hadoop, ELK, три DWH и четыре data lake — зачем нам что-то ещё?» И каждый раз я вижу в глазах собеседника один и тот же взгляд — смесь усталости и надежды.
Недавно один CTO банка рассказал мне историю. Они два года строили «озеро данных». Потратили серьёзный бюджет, собрали команду из 12 инженеров, закупили железо. Результат? Данные туда льются — но никто не знает, что там лежит. Аналитики по-прежнему ходят в Oracle. ML-инженеры выгружают CSV-ки руками. А озеро тихо превращается в болото.
Спойлер: Data Lakehouse появился не потому, что маркетологи придумали красивое слово. Он появился потому, что data-инженеры устали чинить пайплайны в 3 часа ночи, а бизнес устал слышать «данные будут завтра». Если вы думаете, что достаточно скинуть все данные в S3 и назвать это «озером» — добро пожаловать в клуб разочаровавшихся. Здесь выдают кофе и чувство бессмысленности.Часть 1: Краткая и печальная история хранения данных
// маятник, который качается уже 30 лет
Вот что меня поражает в индустрии данных: мы каждые 10 лет переизобретаем одну и ту же идею. Серьёзно. Посмотрите на эту картину с расстояния — и вы увидите не линейный прогресс, а маятник, который качается между двумя крайностями: «давайте всё упорядочим» и «давайте всё свалим в кучу, разберёмся потом».
1990-е: Data Warehouse — элитный склад с каталогом
Идея была красивая: собрать все данные компании в одно место, навести порядок, построить схемы. Teradata, Oracle, IBM DB2 — это были Роллс-Ройсы мира данных. Дорогие, солидные и медленные в обслуживании.
Работало? Да. Для структурированных данных — прекрасно. Финансовые отчёты, продажи, клиентская база — всё чистенько, всё на полочках.
Проблема? Двойная. Во-первых, стоимость. Лицензия Teradata для крупного банка — это бюджет небольшого стартапа. Во-вторых — негибкость. Хотите добавить новый тип данных? Пожалуйста, оформите заявку, через 3 месяца DBA спроектирует схему. Данные поступают со скоростью бизнеса, а хранилище меняется со скоростью бюрократии.
И, что ещё важнее, — полуструктурированные данные (JSON, логи, картинки, видео) в Data Warehouse просто не помещались. Не физически — концептуально. Это как пытаться засунуть кота в аквариум: технически возможно, но все будут несчастны.2010-е: Data Lake — «кидай всё, разберёмся потом»
А потом пришёл Hadoop. И вместе с ним — идея, которая на бумаге выглядела гениально: зачем платить за дорогое хранилище? Давайте зальём все данные в дешёвое распределённое хранилище (HDFS, а потом S3). Структурированные, полуструктурированные, неструктурированные — всё в одну кучу. Потом разберёмся.
Знаете, что произошло? «Потом» так и не наступило.
Gartner в 2018 году подсчитал: 60% проектов Data Lake либо провалились, либо не дают заявленной ценности. Озера данных превращались в болота — data swamps. Данные заливались, но без каталога, без контроля качества, без схемы. Найти что-то конкретное было как искать нужную коробку в гараже, где всё свалено друг на друга.
Метафора, которую я использую на встречах с клиентами: Data Warehouse — это IKEA. Дорого, но всё расставлено по каталогу, есть указатели и ценники. Data Lake — это гараж-сейл. Дёшево, может попасться сокровище, но чтобы его найти — нужно перебрать три тонны хлама.2020-е: Data Lakehouse — третья попытка
И вот мы здесь. Индустрия данных, набив шишки на обоих подходах, пришла к вопросу: а что если можно взять дешёвое хранилище из озера и добавить порядок из хранилища? Не перекладывая данные туда-сюда, а прямо на месте?
Это и есть Data Lakehouse. Но — и это важно — это не просто «озеро + хранилище = дом у озера». Это принципиально другой подход к работе с данными. И чтобы понять, почему он важен, давайте разберёмся, что именно было сломано.
Часть 2: Что на самом деле сломалось
// проблема не в данных — проблема в архитектуре
Проблема не в том, что данных много. Проблема в том, что данные живут в разных мирах
К 2020-м годам типичная enterprise-компания выглядела примерно так:
- Oracle / PostgreSQL — транзакционная база, основа бизнеса
- Teradata / Vertica / Snowflake — DWH для аналитики
- Hadoop / S3 — Data Lake для «всего остального»
- Elasticsearch — для поиска и логов
- MongoDB — для полуструктурированных данных
- Kafka — для потоковых данных
- Ещё какой-нибудь Feature Store для ML
Семь систем. Семь команд. Семь бюджетов. И — самое болезненное — семь копий одних и тех же данных.
Боль №1: Двойная бухгалтерия данных
Это не просто вопрос стоимости хранения (хотя и это немало). Главная проблема — расхождения. Когда одни и те же данные копируются между озером и хранилищем через ETL-пайплайны, рано или поздно цифры начинают расходиться.
Вот реальный сценарий: CFO открывает отчёт в Power BI (данные из DWH), видит выручку за квартал. Маркетинг открывает свой дашборд (данные из Data Lake через Spark). Цифры не совпадают. Начинается расследование. Три дня data-инженеры ищут, где потерялись записи. Находят: пайплайн упал в среду ночью, 47 000 строк не долили.
Я видел, как такие расхождения приводили к задержке финансовых отчётов на неделю. В банке. С регулятором, который ждёт цифры.Боль №2: ETL-ад
По исследованию Anaconda (State of Data Science 2022), data-инженеры тратят около 40% рабочего времени на подготовку, очистку и перемещение данных. Не на анализ. Не на построение моделей. На перекладывание из одного формата в другой.
А ещё ETL-пайплайны — это хрупкие существа. Они ломаются при любом изменении схемы источника, при нагрузке, при обновлении библиотек. Каждый data-инженер с опытом знает ощущение, когда в 3 часа ночи приходит алерт: «Pipeline failed». И ты понимаешь, что утром бизнес останется без свежих данных.
Боль №3: Вчерашние данные для сегодняшних решений
Самая коварная проблема. Классический путь данных: источник → Data Lake → ETL → Data Warehouse → BI-дашборд. Каждый этап добавляет задержку. К тому моменту, когда данные появляются в дашборде, им уже несколько часов, а иногда и сутки.
Для квартального отчёта — терпимо. Для обнаружения фрода в реальном времени — катастрофа. Для рекомендательной системы — потеря денег.
Представьте, что у вас есть холодильник (warehouse) и кладовка (lake). Каждый раз, чтобы приготовить ужин, вам нужно сначала перенести продукты из кладовки в холодильник, разложить по полочкам, и только потом начать готовить. А к моменту готовки половина продуктов уже не свежая. Data Lakehouse — это когда кладовка сама становится холодильником.Часть 3: Data Lakehouse — по-честному
// не продукт, а архитектурный принцип
Вот что важно понять сразу: Data Lakehouse — это не конкретный софт, который можно купить и поставить. Это архитектурный подход. Как «микросервисы» — это не продукт, а способ строить системы.
Суть Lakehouse в трёх слоях:
- Дешёвое хранилище — данные лежат в объектном хранилище (S3, MinIO, HDFS, Azure Blob). Как в Data Lake — никуда не переносим, храним дёшево.
- Метаданные и порядок — поверх файлов добавляется слой, который обеспечивает схему, ACID-транзакции, версионирование. Как в Data Warehouse — но без копирования данных.
- Разделение вычислений и хранения — движок запросов (compute) работает отдельно от хранилища. Можно подключить любой движок к тем же данным.
Настоящий герой этой истории — Open Table Formats
А вот здесь самое интересное. Если вы читали другие статьи про Data Lakehouse, вам наверняка рисовали красивые архитектурные схемы. Но настоящая революция произошла не в архитектуре, а в одной конкретной технологии: open table formats.
Apache Iceberg, Delta Lake, Apache Hudi — вот кто реально изменил правила игры. Эти форматы добавили к обычным файлам в S3 то, чего им категорически не хватало:
- ACID-транзакции — никакого «файл записался наполовину»
- Эволюция схемы — можно менять структуру таблицы без пересоздания
- Time travel — возможность запросить данные на любой момент в прошлом
- Partition evolution — партиционирование меняется без перезаписи данных
- Snapshot isolation — чтение и запись одновременно, без конфликтов
Грубо говоря, open table formats превратили кучу файлов в объектном хранилище в полноценную базу данных. Без базы данных. Звучит как магия, но это просто хороший инжиниринг.
Аналогия: помните, как USB-C изменил мир кабелей? Раньше у каждого устройства был свой разъём: microUSB, Lightning, Mini-USB, проприетарные порты. USB-C — это один формат для всего. Open table formats — это USB-C для данных. Один формат, к которому можно подключить любой движок.Сравнение трёх подходов
| Критерий | Data Warehouse | Data Lake | Data Lakehouse |
|---|---|---|---|
| Типы данных | Структурированные | Любые | Любые |
| Стоимость хранения | $$$ (SSD, проприетарные) | $ (S3/HDFS, open) | $ (S3/HDFS, open) |
| ACID-транзакции | Да | Нет | Да (Iceberg/Delta/Hudi) |
| ML/AI-нагрузки | Плохо | Хорошо | Хорошо |
| BI/SQL-аналитика | Отлично | Плохо | Хорошо — Отлично |
| Свежесть данных | Задержка (ETL) | Real-time | Real-time |
| Vendor lock-in | Высокий | Низкий | Низкий (open formats) |
| Governance/аудит | Зрелый | Слабый | Растущий |
Часть 4: Пять неочевидных преимуществ
// о которых обычно молчат
Единая точка правды — конец корпоративных войн за цифры
В Lakehouse данные живут в одном месте. Аналитик строит отчёт, ML-инженер тренирует модель, маркетолог смотрит дашборд — все работают с одной и той же физической копией данных. Расхождения невозможны по определению.
Это не технический аргумент — это организационный. Количество конфликтов на тему «а у меня другие цифры» снижается до нуля.Data-инженер наконец-то спит по ночам
Меньше систем = меньше точек отказа. Меньше ETL-пайплайнов = меньше ночных алертов. Меньше копий данных = меньше рассинхронизации.
По моему опыту, переход на Lakehouse-архитектуру сокращает количество ETL-задач на 40-60%. Это не значит, что data-инженеры остаются без работы — это значит, что они наконец могут заняться инженерией, а не тушением пожаров.
AI/ML без отдельной инфраструктуры
В классической архитектуре данные для ML нужно выгрузить из DWH, преобразовать, загрузить в Feature Store, и только потом скормить модели. В Lakehouse ML-движок читает данные напрямую из того же хранилища, что и BI.
Результат: модель тренируется на актуальных данных, а не на позавчерашнем снимке. Для fraud detection и рекомендательных систем — это разница между «поймали мошенника» и «заметили через два дня».
Time travel — killer feature, о которой все забывают
Open table formats поддерживают time travel: возможность запросить данные на любой момент в прошлом.
- Аудит: регулятор спрашивает «покажите состояние на 15 марта 14:00» — один SQL-запрос
- Отладка: «Почему модель начала ошибаться?» — сравниваем данные до и после
- Compliance: для банков — требование закона
- Откат ошибок: залили битые данные? Откат за секунды
Свобода от вендора — и это не лозунг
Open table formats — это открытые стандарты. Данные в формате Iceberg может читать Apache Doris, Spark, Trino, Flink, DuckDB, Snowflake — десятки движков.
Вы не привязаны к одному вендору. Не нравится движок запросов? Меняете его, не трогая данные. Хотите один движок для BI, другой для ML? Пожалуйста. Данные — ваши, в вашем хранилище, в открытом формате.
Для контекста: миграция с Teradata — это обычно 12-18 месяцев и восьмизначный бюджет. Миграция между движками в Lakehouse — это смена конфига.Часть 5: Но есть нюансы
// честный взгляд на ограничения
Сложность начального входа
Собрать Lakehouse из open-source компонентов — это как собрать ПК из комплектующих. Можно. Мощно. Но требует компетенций. Вам понадобится:
- Объектное хранилище (MinIO / S3 / HDFS)
- Open table format (Iceberg / Delta Lake)
- Движок запросов (Apache Doris, Trino, Spark)
- Каталог метаданных (Hive Metastore, Nessie)
- Инструменты governance (Apache Atlas, OpenMetadata)
Зрелость экосистемы
Apache Iceberg — молодец, быстро развивается, стал стандартом де-факто к 2026 году. Но экосистема вокруг — governance, data quality, lineage — ещё догоняет.
Компетенции команды
Lakehouse требует людей, которые понимают и storage, и compute, и data governance. Это более широкий T-shaped профиль, чем классический DBA или ETL-разработчик.
Не каждому нужно
Если у вас 10 ГБ данных в PostgreSQL и три отчёта в Excel — Data Lakehouse вам не нужен. Серьёзно. Это как покупать фуру для перевозки одного дивана.
Часть 6: Кому и когда это нужно
// конкретные профили
🏦 Банк с 50+ ТБ данных
Текущая боль: логи — в ELK, аналитика — в Oracle Exadata, ML-модели (скоринг, антифрод) — в отдельном кластере. Три системы, три бюджета, три команды.
Lakehouse-решение: единое хранилище в S3/MinIO → Iceberg-таблицы → один движок (Apache Doris / VeloDB) для SQL-аналитики, полнотекстового поиска и ML-фичей.
Результат: сокращение TCO на 40-60%, аудит за секунды вместо часов, ML-модели на свежих данных.
📡 Телеком-оператор
Текущая боль: CDR в реальном времени, исторические данные для отчётности, fraud detection требует мгновенной реакции. Три разных системы.
Lakehouse-решение: потоковый ingestion (Kafka → Lakehouse) + историческая аналитика + ML-модели антифрода — всё на одной платформе.
Результат: обнаружение фрода в реальном времени вместо «через сутки», единый источник данных для регулятора.
🛒 E-commerce
Текущая боль: рекомендации (ML) живут отдельно от отчётов маркетинга (BI), а логи и observability — в третьей системе. Маркетинг не доверяет цифрам.
Lakehouse-решение: все данные в одном месте. Рекомендательная модель тренируется на тех же данных, по которым строятся маркетинговые отчёты.
Результат: рекомендации на актуальных данных, маркетинг доверяет цифрам, инфраструктурный бюджет — один.
🏛️ Госструктура
Текущая боль: требования закона «О персональных данных» (Казахстан — Закон РК №94-V, Узбекистан — Закон №ЗРУ-547), аудит, контроль доступа. Данные должны храниться на территории страны. Vendor lock-in — стратегический риск.
Lakehouse-решение: open-source стек на своих серверах (on-premise). Apache Iceberg + Apache Doris — всё открытое, всё под контролем.
Результат: полный контроль над данными, соответствие законодательству, независимость от западных вендоров.
Формула: нужен ли вам Lakehouse?
Если хотя бы 3 из 5 — «да», стоит серьёзно задуматься:
- ☐ Данных больше 1 ТБ (и растут)
- ☐ Больше одного типа нагрузки (BI + ML, или BI + поиск)
- ☐ Несколько команд работают с пересекающимися данными
- ☐ Тратите >30% бюджета data-команды на перемещение данных
- ☐ Есть требования к аудиту, compliance или data governance
Итого, без воды
Что такое Data Lakehouse: архитектурный подход, который объединяет дешёвое хранение данных (как Data Lake) с порядком и транзакционностью (как Data Warehouse) — без копирования данных между системами.
Зачем: единая точка правды, меньше пайплайнов, свежие данные, BI и ML на одной платформе, time travel для аудита, свобода от vendor lock-in.
Когда нужно: если данных >1 ТБ, несколько типов нагрузок, несколько команд, требования к compliance.
Когда НЕ нужно: если данных мало, одна команда, один тип задач, и текущее решение справляется.
Что делать дальше: начните с аудита текущей архитектуры. Посчитайте, сколько копий одних и тех же данных живёт в разных системах. Если больше двух — у вас есть бизнес-кейс для Lakehouse.
FAQ
Чем Data Lakehouse отличается от Data Warehouse?
Data Warehouse хранит структурированные данные в дорогом проприетарном формате с жёсткой схемой. Data Lakehouse хранит любые данные в дешёвом объектном хранилище (S3) с open table formats, которые обеспечивают те же гарантии: ACID, схему, governance. Главное отличие — Lakehouse не требует копирования данных и не привязывает к одному вендору.
Чем Data Lakehouse отличается от Data Lake?
Data Lake — это просто хранилище файлов без порядка: нет транзакций, нет схемы, нет версионирования. Data Lakehouse добавляет поверх тех же файлов metadata layer (Iceberg, Delta, Hudi), который превращает «кучу файлов» в полноценную управляемую систему с ACID-транзакциями, time travel и контролем доступа.
Нужно ли выбрасывать существующий DWH?
Нет. Переход на Lakehouse — это чаще всего эволюция, а не революция. Можно начать с новых данных и нагрузок, постепенно мигрируя существующие. Многие компании какое-то время работают в гибридном режиме.
Какой open table format выбрать?
К 2026 году Apache Iceberg стал стандартом де-факто: его поддерживают AWS, Google, Snowflake, Databricks, Apache Doris и десятки других систем. Delta Lake — сильный второй вариант, особенно в экосистеме Databricks. Hudi — нишевое решение для специфичных сценариев с тяжёлым upsert.
Сколько стоит переход на Lakehouse?
Зависит от масштаба. Пилот на 5-10 ТБ данных можно развернуть за 2-4 недели с командой из 2-3 инженеров. Но экономия на инфраструктуре обычно окупает инвестиции за первый год.
ХОТИТЕ ПОНЯТЬ, КАК LAKEHOUSE РАБОТАЕТ В ВАШЕЙ СИТУАЦИИ?
> Консультация бесплатная, обязательства нулевые
./ЗАПРОСИТЬ_КОНСУЛЬТАЦИЮ.shАрхитектура, сценарии использования, ключевые возможности. 5000+ компаний в production.
SuperSet, PowerBI, Tableau тормозит? Sub-100ms, Auto Query Rewrite, бесплатный пилот.
MySQL Protocol, три паттерна DAG, Stream Load. Job Scheduler vs Airflow.
Kafka -> Doris: standalone/distributed, SSL, DLQ, schema evolution и best practices.
Источники и дальнейшее чтение
- Armbrust, M. et al. "Lakehouse: A New Generation of Open Platforms" — оригинальная статья Databricks, 2021
- Apache Iceberg — документация — open table format, ставший стандартом
- State of Data Science 2022 — Anaconda — исследование о времени data-специалистов
- Zhamak Dehghani, "Data Mesh" — альтернативный взгляд на организацию данных
- Ben Stancil, benn.substack.com — один из самых честных блогов о data-индустрии