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

Рис. 1. Архитектура без общего доступа (shared-nothing)

Прогресс в развитии сетевых интерфейсов позволил получить приемлемую производительность обработки данных на нескольких независимых компьютерах, что привело к всплеску интереса к массово-параллельным аналитическим системам на базе недорогих серверов. В 2005 году появился продукт Bizgress, представляющий собой массово-параллельный движок для обработки больших данных на основе СУБД Postgres. В дальнейшем эта система уже под названием Greenplum займет важное место в российском бизнесе. В том же 2005 году Майкл Стоунбрейкер [1] представил C-Store — одну из первых массово-параллельных СУБД, специально предназначенную под аналитические запросы. В дальнейшем наработки C-Store были коммерциализированы в продукте Vertica.

Greenplum и Vertica обеспечивали масштабируемость за счет архитектуры без общего доступа (shared-nothing), в которой отдельный узел отвечает и за хранение, и за обработку данных (рис. 1). По мере роста объемов данных такой подход перестал отвечать требованиям бизнеса — потребность в CPU обычно растет непропорционально потребности в дисковом пространстве. Такая тесная связь компонентов приводит к интенсивному росту стоимости владения по мере увеличения объемов данных.

Рис. 2. Архитектура общего хранилища (shared storage)

К середине нулевых годов крупнейшие технологические компании накопили сотни терабайт и петабайты данных, обработка которых требовала новых подходов. Появление HDFS позволило надежно хранить большие объемы данных на дешевых серверах — были созданы эффективные колоночные форматы хранения Parquet и ORC, а для обработки очень больших объемов данных стали использовать Hadoop, Spark. Решения на основе этих технологий позволили крупным компаниям эффективно обрабатывать практически неограниченные объемы информации. Благодаря Hadoop и Spark был реализован новый принцип обработки данных — shared storage (архитектура общего хранилища), согласно которому независимые вычислительные узлы работают с общим хранилищем (рис. 2). К 2020-м годам shared storage станет фактическим стандартом для аналитических продуктов.

Вместе с тем высокая сложность разработки на Hadoop и Spark существенно ограничивала круг пользователей, что предопределило появление отдельно стоящих SQL-движков, работающих непосредственно с HDFS. Компания Google разработала движок Dremel, который стал ядром Google BigQuery и вдохновил появление ряда известных открытых проектов, таких как Apache Drill и Dremio. Затем появился движок Hive, а потом был предложен более продвинутый движок Presto для аналитики ad-hoc. В 2018 году в результате внутреннего конфликта от Presto откололся форк Trino [2], который сегодня стал самым популярным движком для построения lakehouse в России. Активный переход в облако придал дополнительный стимул для дальнейшего развития подобных SQL-движков.

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

  • корпоративные хранилища на основе архитектуры shared-nothing (Greenplum, Vertica) для обработки умеренных объемов информации, преимущественно в конфигурации on-premises;
  • системы с разделением вычислений и хранения. В качестве хранилища использовались AmazonS3 или HDFS, а роль вычислителя выполняли Spark и массово-параллельные SQL-движки.

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

Рождение lakehouse

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

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

Как раз в этот момент пользователи хранилищ столкнулись с ростом стоимости владения:

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

В сложившейся ситуации компания Databricks усмотрела уникальную возможность, предложив перенести все данные организации из проприетарных хранилищ в озеро данных, добавить к ним табличный формат и направить к этим данным вычислительные движки (Spark, Trino и т. д.), что позволило пользователям получить ряд преимуществ:

  • поддержка транзакций и эволюции схемы в озере данных. Пользователи могут получать консистентные срезы данных даже в случае их параллельного обновления в другой системе;
  • уменьшение числа копий данных: все потребители могут работать с одними и теми же данными, хранящимися в озере в открытых форматах (Parquet, ORC, Avro);
  • эластичное масштабирование вычислительных мощностей отдельно от хранения.

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

Рис. 3. Принципиальная схема lakehouse

Компания Databricks предложила собственный табличный формат Delta Lake и ввела в обиход термин 'lakehouse' для обозначения архитектуры на основе открытых форматов хранения и табличных форматов, совмещающей преимущества и озер, и хранилищ данных (рис. 3).

Последующие годы ознаменовались «войной форматов» — попытками разных крупных производителей продвинуть собственный табличный формат. В итоге победителем стал Apache Iceberg благодаря своей универсальности и открытой модели разработки. Apache Hudi и Apache Paimon paimon.apache.org заняли место нишевых решений, ориентированных на решение задач стриминга. Формат Delta Lake заслужил славу табличного формата с противоречивой моделью разработки, которая слишком сильно зависит от Databricks.

Lakehouse в России

Рис. 4. Стандартная архитектура аналитической платформы

По состоянию на конец 2024 года наиболее популярной архитектурой аналитической платформы остается связка Greenplum и ClickHouse, работающая следующим образом (рис. 4): операционные данные переносятся из источников в хранилище Greenplum, где происходит расчет витрин, которые далее переносятся в ClickHouse, к витринам которого и обращаются пользователи. Однако такая архитектура не отвечает реальным потребностям современных организаций, приводит к существенному завышению стоимости владения и накладывает на организации серьезные стратегические риски.

Во-первых, компании вынуждены одновременно поддерживать несколько движков обработки данных. Greenplum хорошо справляется со сложными расчетами, но быстро теряет стабильность при обработке произвольной пользовательской нагрузки. ClickHouse, напротив, хорошо справляется с большим количеством простых пользовательских запросов, но не может быть использован для сложных регламентных расчетов. Все вместе это приводит к необходимости дублирования данных в Greenplum и ClickHouse, разработки сложных ETL-процессов и каталогизации многочисленных витрин.

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

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

Наконец, в середине 2024 года компания Broadcomm закрыла исходный код Greenplum и пользователи оказались в ситуации, когда развитие продукта фактически оказалось остановлено.

Все вместе это привело к всплеску интереса к lakehouse — у компаний появился шанс решить сразу несколько актуальных задач:

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

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

В отличие от монолитных хранилищ, lakehouse состоит из нескольких независимых продуктов:

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

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

Хранение

В качестве распределенной файловой системы можно использовать одно из представленных на российском рынке решений на основе протокола S3: решение on-premises, облако от местного провайдера, программно-аппаратный комплекс. Например, компания VK предоставляет решение VK Cloud Storage, доступное как в облаке, так и on-premises.

В качестве хранилища можно выбрать объектную систему хранения MinIO, однако использовать данный продукт необходимо осторожно — лицензионная модель запрещает поддержку продукта российскими поставщиками. Кроме того, публичные заявления от MinIO указывают на рост финансовых вложений компании в смежные отрасли (например, в ИИ), что грозит риском поглощения компании в обозримом будущем, если ей не удастся занять существенную долю рынка. Как результат, пользователи MinIO потеряют поддержку в России и столкнутся с ситуацией, аналогичной Greenplum.

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

После выбора распределенной файловой системы компании необходимо определить, как хранить данные. Самый популярный табличный формат — Apache Iceberg, а наиболее востребованный формат хранения — Apache Parquet.

Вычисления

Работа с данными lakehouse происходит с помощью SQL-движков, которые могут быть интегрированы с любыми пользовательскими приложениями: инструментами бизнес-аналитики, ноутбуками Python, средами разработки и т. д.

Самый востребованный SQL-движок для lakehouse — проект Trino категории Open Source, позволяющий не только быстро обрабатывать данные в озере, но и объединять данные между системами, реализуя архитектуру Data Fabric. Наряду с Apache Spark и Apache Flink, Trino является одним из ключевых проектов в экосистеме Apache Iceberg. Это позволяет сообществам Trino и Apache Iceberg обмениваться идеями, обеспечивая высокий уровень интеграции, что положительно сказывается на потребительских характеристиках продукта. Важным преимуществом Trino является наличие в России технической экспертизы по его доработке и поддержке, а также наличие активного сообщества пользователей и разработчиков Trino.

Кроме этого имеются SQL-движки Apache Impala и StarRocks.

Apache Impala была популярным SQL-движком в экосистеме Hadoop, но сейчас этот продукт практически не используется за пределами пользовательской базы Cloudera. Как следствие, в Сети имеется минимум документации и описаний опыта использования продукта. Продукт развивается достаточно неспешно, так как он не является приоритетным для Cloudera, а других значимых контрибьюторов у проекта нет, например, за 2024 год Apache Impala получила в семь раз меньше улучшений работы lakehouse, по сравнению с Trino. Кроме этого, техническая архитектура Apache Impala не подходит для реализации типичных сценариев lakehouse — в продукте отсутствует современный оптимизатор запросов, необходимый для эффективного выполнения сложных аналитических задач. В результате пользователи вынуждены тратить время на тонкую настройку каждого отдельного запроса.

StarRocks — китайский проект для аналитики реального времени, созданный на основе Open Source проекта Apache Doris и изначально призванный конкурировать с ClickHouse. Для StarRocks ведется агрессивная информационная кампания с обещаниями многократного роста производительности по сравнению с другими системами, однако этот продукт пока нестабилен, что обусловлено высокой скоростью добавления новых функций без должного тестирования. Например, ежемесячно поступают десятки жалоб пользователей на неожиданную остановку работы сервиса. Вместе с тем StarRocks лишь условно можно отнести к категории Open Source — значительная часть ядра закрыта и распространяется в виде бинарного файла, что не вселяет уверенности в отсутствии закладок и уязвимостей. Наконец, интенсивность разработки StarRocks за 2024 год упала вдвое по сравнению с 2023 годом, что означает перенос фокуса основного разработчика StarRocks — компании CelerData — в пользу коммерческих продуктов.

Метаданные

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

Самый популярный сегодня технический каталог для lakehouse — Hive Metastore, хотя он и не предназначался для сценариев lakehouse. Популярность Hive Metastore обусловлена размером активной пользовательской базы Hadoop в России благодаря его вхождению в сборку Hadoop. Однако на практике пользователи Hive Metastore регулярно сталкиваются с низкой производительностью при выполнении запросов в lakehouse. Имеется также российское решение CedrusData Catalog — высокопроизводительный каталог для lakehouse. Кроме этого можно использовать такие решения категории Open Source, как Apache Polaris и Nessie.

Безопасность

В основе архитектуры lakehouse лежит озеро данных, которые в России традиционно строили на основе стека Hadoop, за безопасность в котором отвечает отдельный продукт Apache Ranger — каталог правил безопасности. Если какой-либо компонент Hadoop хочет авторизовать пользователя, он запрашивает политики доступа у Apache Ranger и самостоятельно их применяет.

Может возникнуть желание переиспользовать Apache Ranger и для lakehouse, но, к сожалению, это плохая практика, так как ответственность за принятие авторизационных решений переносится на другие компоненты платформы (SQL-движки, Apache Spark, Apache Kafka и т. д.). Таким образом, управление безопасностью оказывается «размазанным» по большому количеству независимых систем. Более того, часть таких систем, например Apache Spark, не поддерживают работу с Apache Ranger.

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

В России данный подход осуществлен в каталоге CedrusData Catalog, который реализует механизмы discretionary access control (DAC) и role-based access control (RBAC) для всех систем, взаимодействующих с данными lakehouse.

Архитектура

Успешное развертывание lakehouse потенциально позволяет компаниям получать дополнительную пользу от своих данных благодаря более оперативной аналитике на основе качественной информации. Однако процесс перехода на архитектуру lakehouse усложняется из-за разнообразия продуктов на рынке. Может быть два варианта реализации: на основе решений Open Source и на основе интегрированного коммерческого стека.

Lakehouse на базе Open Source

В качестве слоя хранения в этом случае обычно используется MinIO или HDFS, для вычислений комбинация SQL-движков — Trino, Impala и StarRocks, а в качестве каталога — Hive Metastore. За безопасность отвечает Apache Ranger.

Рис. 5. Реализация lakehouse на решениях Open Source

Такое решение (рис. 5) может быть сконструировано из бесплатных компонентов, однако оно имеет ряд серьезных недостатков: некоторые компоненты дублируют друг друга; часть компонентов устаревшие, обладают посредственными характеристиками и не имеют реальной технической поддержки, а некоторые вовсе закрыты. Например MinIO — де-факто коммерческий продукт, который не предполагает предоставление технической поддержки сторонними компаниями или силами самой организации, а HDFS демонстрирует плохую производительность при работе с характерными для lakehouse нагрузками. Hive Metastore обладает низкой производительностью при работе с большими таблицами или одновременной работе большого количества пользователей. Кроме этого, дублирование SQL-движков приводит к усложнению архитектуры, перерасходу средств и росту затрат на обучение пользователей. Impala не может эффективно обрабатывать произвольно сложные SQL-запросы, а StarRocks содержит закрытые части ядра, что делает невозможной его техническую поддержку. Наконец, использование Apache Ranger приводит к фрагментации ландшафта безопасности, где за авторизацию действий пользователей отвечает множество несвязанных программных компонентов, часть которых не имеет средств разграничения прав доступа.

Таким образом, развертывание lakehouse на основе несвязанных друг с другом продуктов Open Source несет риски усложнения архитектуры, отсутствия технической поддержки и нарушения информационной безопасности.

Lakehouse на основе коммерческих решений

Рис. 6. Пример реализации lakehouse на основе коммерческих решений

Альтернативный способ построения lakehouse — стек интегрированных коммерческих продуктов. В этом случае компания получает решение, состоящее из небольшого количества систем, за каждой из которых стоит команда инженеров с глубокой экспертизой, гарантирующая не только оперативную техническую поддержку, но и развитие функционала. Пример такой платформы — интегрированное решение от CedrusData и VK (рис. 6):

  • хранилище VK Cloud Storage, которое может быть развернуто в облаке или on-premises;
  • SQL-движок CedrusData Engine на основе проекта Trino, позволяющий выполнять запросы к данным в озере и объединять данные из разных источников;
  • технический каталог CedrusData Catalog для Apache Iceberg, поддерживающий безопасный доступ к данным на основе ролей (RBAC) и управляющий метаданными lakehouse;
  • подсистема централизованного применения политик безопасности средствами CedrusData Catalog для всех потребителей данных lakehouse, обеспечивающая интеграцию в платформу других внешних систем работы с данными (Apache Spark, Apache Kafka и пр.).

Данный подход предполагает относительно простую архитектуру платформы, высокий уровень безопасности при наличии технической поддержки всех компонентов. Использование SQL-движка на основе Trino позволяет обеспечить итеративную миграцию пользовательских задач с устаревших технологий, например с Greenplum.

Что делать?

Для повышения шансов на успешное построение эффективной платформы lakehouse компании должны ответить на следующие вопросы:

  • использовать Open Source или коммерческое решение? Первый вариант несет ряд рисков, способных замедлить скорость интеграции lakehouse в компании, некоторые из которых считают, что смогут самостоятельно доработать продукты Open Source. Однако в реальности этого не происходит — бизнес обычно не имеет достаточных стимулов для развития полноценной внутренней экспертизы в сфере разработки ПО. Использование коммерческих продуктов часто оказывается более надежной альтернативой;
  • имеется ли у производителя реальная возможность развития и поддержки продукта? Например, коммерческие решения на базе Trino могут без ограничений расширять функционал, в то время как вендоры, работающие с MinIO и StarRocks, лишены возможности полноценной поддержки своих продуктов;
  • имеется ли в России экспертиза по выбранным продуктам? Например, в России есть активные сообщества пользователей и разработчиков Trino и Apache Iceberg, а также коммерческие версии Trino.

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

***

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

Литература

1. Дмитрий Волков. СУБД: вчера, сегодня и завтра // Открытые системы.СУБД. — 2024. — № 3. — С. 12–19. URL: https://www.osp.ru/os/2024/03/13058759 (дата обращения: 21.03.2025).

2. Владимир Озеров. Открытая технология анализа корпоративных данных // Открытые системы.СУБД. — 2023. — № 2. — С. 8–11. URL: https://www.osp.ru/os/2023/02/13057251 (дата обращения: 21.03.2025).

Владимир Озеров (vozerov@querifylabs.com) — генеральный директор, «Кверифай Лабс» (Москва).

Статья подготовлена на основе материалов выступления на форуме DATA&AI 2024.