Data Lakehouse как новая основа платформ данных.

Еще относительно недавно архитектура корпоративной работы с данными выглядела достаточно понятной и предсказуемой. Для аналитики, отчетности и BI использовались классические Data Warehouse, которые хорошо подходили для хранения структурированных данных и выполнения сложных SQL-запросов. Параллельно развивались Data Lake, ориентированные уже на совершенно другой класс задач: накопление больших объемов сырых данных, хранение логов, событий, файлов, телеметрии, данных IoT, ML-наборов и любых других типов информации, которые плохо вписывались в жесткие схемы традиционных хранилищ.

Долгое время такая модель считалась практически эталонной. Она действительно работала. Но по мере роста объемов данных и усложнения инфраструктуры начали проявляться ограничения, которые становилось все сложнее игнорировать. Причем проблема заключалась даже не в производительности отдельных компонентов, а в самой архитектурной модели, где данные постоянно перемещаются между разными системами, а каждая новая задача требует появления очередного слоя интеграций, ETL-процессов и специализированных инструментов.

Именно на этом фоне начал формироваться подход Data Lakehouse, который сегодня постепенно превращается из «интересной современной концепции» в одну из базовых моделей построения data-платформ.

Любопытно, что в центре этой трансформации оказался не новый тип СУБД и даже не очередной вычислительный движок, а объектное S3-совместимое хранилище, которое еще несколько лет назад многие воспринимали скорее как относительно простой storage для файлов и бэкапов.

На практике почти любая крупная data-платформа последних лет выглядела как комбинация нескольких независимых систем, каждая из которых отвечала за свою часть жизненного цикла данных. В одном месте находилось озеро данных, куда складывались сырые данные из различных источников. В другом — аналитическое хранилище, подготовленное для BI и отчетности. Поверх этого работали ETL-процессы, стриминговые пайплайны, витрины данных, ML-контуры и многочисленные интеграции.

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

Данные приходится постоянно перемещать между системами. Сырые события сначала попадают в Data Lake, затем агрегируются, нормализуются, преобразуются и отправляются в warehouse. Потом часть данных копируется в отдельные витрины, часть — в ML-контуры, часть — в streaming-системы. Каждое такое перемещение увеличивает задержки, создает риски рассинхронизации и требует вычислительных ресурсов.

При этом появляются организационные последствия. Одна команда занимается озером данных, другая поддерживает DWH, третья отвечает за Spark-кластеры, четвертая — за ML-инфраструктуру. В результате вместо единой платформы формируется набор относительно автономных технологических зон со своими релизными циклами, форматами данных и внутренними правилами.

На определенном масштабе это начинает превращаться в системное ограничение.

Особенно хорошо это заметно в современных сценариях, связанных с real-time аналитикой, машинным обучением, обработкой телеметрии, IoT-нагрузками и AI-платформами, где объемы данных измеряются уже не терабайтами, а петабайтами, а требования к скорости доступа и универсальности использования становятся принципиально другими.

Иногда Lakehouse описывают как «гибрид Data Lake и Data Warehouse», но это определение довольно поверхностное. На практике речь идет о гораздо более серьезном изменении архитектурной модели.

Основная идея Lakehouse заключается в том, что данные перестают существовать в нескольких независимых системах одновременно. Вместо этого появляется единый storage-layer, поверх которого работают разные вычислительные движки и разные типы нагрузки.

Фактически происходит разделение хранения и вычислений, которое в последние годы стало одним из ключевых принципов современной data-инфраструктуры.

Данные хранятся в объектном S3-совместимом хранилище, а поверх них могут параллельно работать Spark, Trino, Flink, ClickHouse, Presto, ML-фреймворки и любые другие системы обработки. Причем речь идет не о копировании данных между ними, а о работе с единым набором данных.

Именно это делает Lakehouse настолько привлекательным для современных платформ.

Вместо множества разрозненных слоев появляется единая среда хранения, которая одновременно подходит и для BI-аналитики, и для Data Science, и для потоковой обработки, и для AI-нагрузок.

По сути, Data Lakehouse становится попыткой превратить объектное хранилище в универсальную основу платформы данных.

Если посмотреть на развитие Lakehouse-подхода, довольно быстро становится понятно, что объектное хранение здесь не случайно.

Во-первых, именно S3-модель хранения наиболее естественно решает проблему масштабирования. Когда речь идет о хранении огромных массивов исторических данных, классические подходы к storage начинают становиться слишком дорогими и сложными в эксплуатации. Объектное хранилище, напротив, позволяет практически линейно масштабировать объемы без радикального усложнения инфраструктуры.

Во-вторых, S3 идеально подходит для концепции разделения compute и storage. Хранение существует отдельно от вычислений, а значит вычислительные ресурсы можно масштабировать независимо от объема данных. Это особенно важно для аналитических и ML-сценариев, где нагрузка может быть крайне неравномерной.

Но, пожалуй, самое интересное заключается в том, что современный Lakehouse фактически вырос вокруг open table formats, архитектура которых изначально проектировалась под объектное хранение.

Когда разговор заходит о Lakehouse, многие сначала воспринимают его как просто набор parquet-файлов в S3. На определенном уровне это действительно так, но реальная архитектура значительно сложнее.

Parquet сам по себе — очень мощный формат. Он предоставляет колоночное хранение, поддерживает эффективное сжатие, dictionary encoding, predicate pushdown и range get, благодаря чему аналитические движки могут читать только необходимые части данных, а не весь файл целиком.

Кроме того, Parquet отлично подходит для модели Write Once Read Many, что делает его естественным форматом для работы поверх S3.

Но проблема в том, что Parquet все еще остается просто файлом.

Он не умеет обеспечивать транзакционность, не поддерживает безопасные UPDATE и DELETE, не решает проблему конкурентной записи, не умеет эволюционировать схемы данных на уровне таблицы и не предоставляет механизмов управления версиями.

А значит для построения полноценного Lakehouse требуется дополнительный слой абстракции.

Именно здесь начинается самое интересное.

Такие форматы, как Apache Iceberg, Delta Lake и Hudi, по сути добавляют поверх объектного хранения свойства полноценной СУБД.

Iceberg особенно интересен тем, как именно он это делает.

Вместо попытки модифицировать файлы напрямую он строит многослойную систему метаданных, снапшотов, manifest-файлов и каталогов, которые описывают текущее состояние таблицы.

Фактически таблица перестает быть просто набором parquet-файлов и превращается в согласованное состояние данных, управляемое через metadata layer.

Это позволяет реализовать ACID-транзакции, MVCC, snapshot isolation, time travel, schema evolution и атомарные коммиты даже поверх среды, которая изначально не поддерживает подобных возможностей.

Причем архитектурно это выглядит довольно элегантно.

Вместо изменения существующих данных создаются новые версии файлов, а затем атомарно переключается ссылка на актуальный snapshot таблицы. В результате пользователи всегда видят консистентное состояние данных, а сама платформа получает поведение, очень похожее на классическую СУБД.

Именно благодаря этому Lakehouse перестал быть просто “озером файлов” и начал восприниматься как полноценная data-платформа.

На этом этапе становится понятно, что объектное хранилище в архитектуре Lakehouse — уже далеко не просто пассивный слой хранения.

От его характеристик начинает зависеть работа всей платформы.

Количество metadata-операций резко возрастает. Появляются сложные сценарии параллельного чтения и записи. Вычислительные движки начинают активно использовать range get, читать manifests, snapshots и metadata layers. Возрастает количество небольших операций и параллельных запросов.

Именно поэтому для современных Lakehouse-платформ уже недостаточно просто «поддерживать S3 API».

Важно, насколько само хранилище способно эффективно работать как storage-layer для аналитических и транзакционных нагрузок нового поколения.

На практике это означает, что если раньше storage воспринимался как инфраструктурный слой, который «просто хранит файлы», то теперь объектное хранилище становится полноценным архитектурным фундаментом data-платформы.

ЗАКРОМА.Хранение в этой модели можно рассматривать не просто как корпоративное объектное S3-хранилище, а как полноценный storage-layer для построения современных Data Lakehouse-платформ. Платформа обеспечивает единое пространство хранения данных для аналитики, Data Science, ML, потоковой обработки и AI-сценариев, поддерживая работу с S3 API, большими историческими массивами данных, parquet-форматами и современными open table formats вроде Apache Iceberg.

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

При этом ЗАКРОМА.Хранение поддерживает механизм S3 Select, который позволяет выбирать и фильтровать данные прямо внутри объектного хранилища без полного скачивания файлов. Это снижает нагрузку на сеть и ускоряет работу аналитических систем.

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

По сути, мы наблюдаем постепенный переход от мира специализированных хранилищ к миру универсальных платформ данных, построенных поверх объектного storage и главное изменение заключается в том, что объектное S3-хранилище перестало быть второстепенной инфраструктурой и превратилось в базовый слой современной архитектуры данных.

И похоже, именно вокруг этого слоя в ближайшие годы будет строиться значительная часть новых data-платформ.