Что такое Lakehouse?

Название Lakehouse сложилось из Data Lake и Data Warehouse. Идея в том, чтобы хранить данные как в Data Lake, но работать с ними почти как в DWH.

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

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

Data Lake устроен иначе. Данные лежат в S3 в открытых форматах вроде Parquet. Хранилище масштабируется отдельно, а одни файлы могут использовать разные инструменты.

Но просто сложить Parquet-файлы в S3 недостаточно.

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

Lakehouse добавляет этот недостающий слой управления.

Из чего он состоит?

1. Объектное хранилище

S3, MinIO или другой storage хранит файлы с данными.

2. Табличный формат

Iceberg, Delta Lake или Hudi управляет схемой, версиями и изменениями файлов. Этот слой даёт транзакции, конкурентную запись, time travel и rollback.

3. Каталог

Хранит информацию о таблицах и указывает движкам, где находятся их актуальные метаданные. В этой роли могут использоваться Hive Metastore, AWS Glue, Nessie или Iceberg REST Catalog.

4. Вычислительные движки

Spark выполняет обработку, Trino запускает SQL-запросы, Flink работает с потоками. Все они могут обращаться к одним таблицам.

Зачем отделять хранение от вычислений?

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

Если storage и compute масштабируются отдельно, не нужно держать большой вычислительный кластер только ради хранения. Ресурсы можно добавлять под конкретную нагрузку.

Также не обязательно создавать отдельную копию данных для Spark, вторую для SQL и третью для ML. Разные инструменты могут работать с общей таблицей.

Когда Lakehouse действительно нужен?

Не каждой компании нужен Lakehouse.

Если данных немного, ими занимается одна команда, а аналитика помещается в одной СУБД, Lakehouse может только добавить сложности.

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

Одной команде нужен SQL и BI, другой - Spark, третьей - машинное обучение, четвёртой - потоковая обработка. Хранить для каждой команды отдельную копию данных становится дорого и неудобно.

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

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

Почему это стало возможным именно сейчас?

Хранить файлы отдельно умели и раньше. Но старым Data Lake не хватало управления таблицами, а работа с файлами уступала DWH по удобству и надёжности.

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

А что с DWH?

Lakehouse не обязательно заменяет DWH. Современные облачные DWH тоже разделяют хранение и вычисления, поэтому граница между подходами размывается.

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

Если коротко, Lakehouse - это Data Lake, которому добавили управление таблицами и часть возможностей DWH. Но оправдан он обычно тогда, когда масштабы и зрелость компании требуют собственной data-платформы.
————
Как же нейронки стали хорошо генерить картиночки))

it пингвин | data engineer 🐧