Что такое 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 🐧
Название 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 🐧