Почему компании переходят на Lakehouse

Взрывной рост объемов данных и пользователей заставляет бизнес пересматривать требования к аналитическим платформам.

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

Эволюция аналитических платформ‍

Появление lakehouse обусловлено эволюцией аналитических систем. В 1980-х Teradata представила программно-аппаратный комплекс для анализа данных, ставший лидером на годы. В 1992 году Walmart создала на Teradata первое терабайтное хранилище. Крупные российские компании активно используют программно-аппаратные комплексы Teradata. Расцвет ПАКов пришелся на 2000-е с появлением Oracle Exadata и Netezza.

Улучшение сетевых интерфейсов позволило использовать недорогие серверы для массивно-параллельной обработки. В 2005 году появился Bizgress (позже Greenplum) и C-Store Майкла Стоунбрейкера (основа Vertica).

Высокая сложность работы с Hadoop и Spark значительно сужала аудиторию пользователей, что стимулировало развитие независимых SQL-движков, способных работать напрямую с HDFS. Компания Google создала движок Dremel, который сегодня составляет основу Google BigQuery. Dremel послужил inspiration для появления нескольких известных open-source проектов, включая Apache Drill и Dremio.

Параллельно развивались и другие решения: сначала появился Hive, а затем более совершенный движок для ad-hoc аналитики — Presto. В 2018 году от Presto отделился форк под названием Trino, который в настоящее время стал наиболее популярным движком для построения lakehouse в России. Активная миграция в облачную среду предоставила дополнительный импульс для развития этого класса SQL-движков.

Сложность разработки на Hadoop/Spark привела к появлению SQL-движков, работающих с HDFS: Google Dremel (основа BigQuery), вдохновивший Apache Drill и Dremio; был создан Hive и Presto, от которого в 2018 году отделился Trino — сейчас самый популярный движок для lakehouse в России.

В результате, к рубежу 2015-2020 годов сформировались два основных подхода к обработке больших массивов структурированных данных:

1. Корпоративные хранилища данных, построенные на архитектуре shared-nothing. Такие системы, как Greenplum и Vertica, оптимально подходили для работы с умеренными объемами информации и преимущественно использовались в on-premises-инфраструктуре.
2. Системы с разделением вычислительных ресурсов и хранилища. В этой архитектуре в качестве хранилища применялись S3 или HDFS, а для вычислений использовались Spark и массивно-параллельные SQL-движки.

Именно тогда появились ключевые для lakehouse технологии — табличные форматы.

Возникновении концепции Lakehouse

В середине 2010-х годов крупные технологические компании столкнулись с необходимостью повышения производительности и обеспечения консистентности данных, хранящихся в распределенных системах хранения HDFS и S3. В ответ на эти потребности в 2017 году Uber представила проект Hudi, обеспечивающий эффективную вставку данных в HDFS, а годом позже Netflix разработала Iceberg — решение для консистентного обновления крупных таблиц в data lakes. Оба проекта представляли собой табличные форматы — спецификации, определяющие методы записи данных в озеро для гарантии их целостности.

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

В этот же период пользователи классических хранилищ столкнулись с растущей стоимостью владения:

• Неравномерное масштабирование compute и storage в shared-nothing архитектурах вело к неэффективному использованию ресурсов.
• Проприетарные форматы хранения затрудняли обмен данными между системами, приводя к дублированию и замедлению разработки.

Компания Databricks предложила решение: перенос данных в открытые форматы озер с использованием табличных форматов и подключением разнородных вычислительных движков (Spark, Trino и др.). Это обеспечило:

• транзакционность и консистентность данных при параллельном доступе;
• единое пространство данных без избыточного копирования;
• независимое масштабирование вычислительных ресурсов и хранилища.

Databricks разработала собственный формат Delta Lake и ввела термин "lakehouse" для обозначения архитектуры, сочетающей преимущества data lakes и data warehouses.

Последующие годы прошли под знаком "войны форматов", где различные вендоры продвигали свои решения. К концу 2024 года Apache Iceberg стал де-факто стандартом благодаря открытой модели разработки и универсальности. Apache Hudi и Apache Paimon заняли нишу streaming-решений, а Delta Lake сохранил положение формата, тесно связанного с экосистемой Databricks.

Lakehouse на российском рынке

Внедрение технологических инноваций в России часто происходит с запозданием, и концепция lakehouse подтверждает эту тенденцию.

На конец 2024 года большинство отечественных компаний продолжают использовать традиционную связку Greenplum и ClickHouse, организованную по следующему принципу:

• Операционные данные переносятся из источников в хранилище Greenplum.
• В Greenplum осуществляются расчеты витрин данных, которые затем перемещаются в ClickHouse.
• Пользователи работают с готовыми витринами через ClickHouse.

Данная архитектура демонстрирует растущее несоответствие потребностям современного бизнеса, приводя к завышенной стоимости владения и создавая существенные операционные риски.

Ключевые проблемы устаревшего подхода:

1. Множественность технологических платформ. Greenplum подходит для сложных вычислений, но не справляется с пиковыми нагрузками. ClickHouse эффективен для простых запросов, но не поддерживает сложные расчеты. Это ведет к дублированию данных, сложным процессам преобразования и проблемам управления многочисленными витринами.
2. Совмещение вычислений и хранения. Обе системы не поддерживают современную архитектуру с разделением compute/storage, что приводит к неэффективному использованию ресурсов и дополнительным затратам.
3. Длительный цикл разработки. Внедрение новых аналитических сценариев требует создания отдельных витрин, увеличивая время ожидания бизнес-пользователей до нескольких месяцев.

Ситуация усугубилась после закрытия исходного кода Greenplum компанией Broadcom, что остановило развитие платформы. Хотя проект Apache Cloudberry предлагает открытую альтернативу, решение пока не готово для промышленной эксплуатации.

Эти вызовы стимулировали активный интерес к архитектуре lakehouse. Российские компании рассматривают её как возможность:

• Ускорить разработку аналитических решений.
• Полностью реализовать потенциал корпоративных данных.
• Оптимизировать инфраструктурные расходы.
• Перейти с устаревающих технологий на современную платформу.

В настоящее время наблюдается ускоренный переход организаций из различных отраслей на архитектуру lakehouse, что свидетельствует о растущей актуальности этого подхода в России.

Технологический стек

Ключевым вопросом при построении lakehouse становится выбор технологического стека. В отличие от монолитных хранилищ, архитектура lakehouse обычно представляет собой комбинацию независимых компонентов.

Технически lakehouse состоит из трех основных элементов:

1. распределенная файловая система;
2. один или несколько вычислительных движков;
3. технический каталог, обеспечивающий корректное взаимодействие между компонентами.

Для распределенного хранения данных могут использоваться HDFS или различные S3-совместимые решения.

После выбора системы хранения необходимо определить формат данных. Наиболее популярным табличным форматом является Apache Iceberg, а для хранения чаще всего используется Apache Parquet.

Среди вычислительных движков лидирует open-source проект Trino, обеспечивающий высокоскоростную обработку данных в озере и поддержку архитектуры data fabric. Trino, вместе с Apache Spark и Apache Flink, составляет основу экосистемы Apache Iceberg, что обеспечивает тесную интеграцию и постоянное улучшение функциональности.

В качестве технического каталога традиционно применяется Hive Metastore, хотя его производительность часто не удовлетворяет современным требованиям. Многие российские компании активно ищут более эффективные альтернативы.

Примером современного решения является платформа CedrusData, включающая:

• CedrusData Engine – движок на основе open-source проекта Trino, который позволяет эффективно выполнять запросы к данным в озере, а также объединять данные из разных источников.
• CedrusData Catalog – современный высокопроизводительный технический каталог для Apache Iceberg.

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

MinIO как распределенная файловая система имеет ограничения лицензии, препятствующие его доработке российскими поставщиками.

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

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

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

Внедрение lakehouse

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

Для повышения вероятности успешного построения эффективной платформы lakehouse организациям необходимо ответить на ключевые вопросы:

Выбор между open-source и коммерческими решениями
Open-source продукты часто содержат существенные недостатки, замедляющие интеграцию lakehouse. Хотя некоторые компании рассчитывают на внутреннюю доработку таких решений, на практике бизнес редко имеет достаточные стимулы для развития необходимой экспертизы. Использование коммерческих продуктов вендоров часто представляет более надежную альтернативу.

Оценка возможностей вендора
Критически важно оценить способность поставщика обеспечивать развитие и поддержку продукта. Например, вендоры Trino имеют возможности для создания нового функционала, в то время как поставщики MinIO и Starrocks ограничены в возможностях полноценной поддержки.

Наличие экспертизы в России
Следует учитывать присутствие в стране сообществ и специалистов по выбранным технологиям. В России активно развиваются сообщества вокруг Trino и Apache Iceberg, а также доступны коммерческие версии Trino.

После выбора технологического стека компании необходимо разработать стратегию миграции нагрузок. Многие организации уже имеют в своей инфраструктуре озеро данных и вычислительные движки, что позволяет осуществлять постепенный перенос существующих сценариев в lakehouse. Примером успешного подхода может служить опыт компании Avito, которая планомерно переносит нагрузку из хранилища на Vertica в новую платформу на основе Trino.

Заключение

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

Многие российские компании уже активно внедряют архитектуру lakehouse, и в 2025 году ожидается усиление этой тенденции. Руководителям data-офисов крупного и среднего бизнеса рекомендуется уделить повышенное внимание данной архитектуре в предстоящем году.