Недавно CEO Starburst опубликовал манифест о будущем открытого озера данных. В манифесте он говорит об Icehouse, архитектуре озера данных нового поколения на базе Trino и Iceberg. Глядя на нее, многие разработчики недоумевали: «А чем она отличается от любой другой архитектуры Data Lakehouse?». Команда VK Cloud перевела статью о концепции Icehouse. Вы поймете, почему в ней нет необходимости и почему она подходит далеко не всем, кто работает с открытыми архитектурами озера данных.
Архитектура Icehouse: шаг назад в развитии открытых архитектур
CEO компании Starburst Джастин Боргман продвигает Icehouse как революционное решение. Представляя эту концепцию, Боргман убеждает нас, что речь идет о шестой современной платформе данных. На самом же деле в ней нет ничего нового. Для многих предприятий эта архитектура объективно хуже, чем альтернативы. Язык не поворачивается назвать ее революционной. Это быстро заметили даже разработчики из Databricks, объяснившие, почему концепция Icehouse от Starburst — это просто менее открытый формат Data Lakehouse.
Почему бы не назвать это просто Lakehouse? Trino тоже отличается отличной интеграцией с OSS Delta Lake. Не вижу, какое отношение этот паттерн имеет к реализации Iceberg. И странно говорить об открытости, когда все сводится к одному формату Lakehouse.
Так что такое Icehouse? Это просто очередное модное словечко, направляющее рынок в сторону ИТ-продуктов Starburst. О многом говорит уже тот факт, что впервые пост об этой идее опубликовали в блоге CEO компании Starburst, а не в сообществе Trino. Коммерческие решения Starburst созданы на базе Trino. И в результате внедрения Icehouse эта компания выиграет больше, чем кто-либо другой.
Получается, что Icehouse — это просто архитектура Lakehouse, рекомендованная Starburst. Можно ли считать это достаточно надежным фундаментом для разработки Lakehouse? Конечно, можно. Но это никакая не «революция» и тем более не «шестая» платформа данных.
А можно ли считать архитектуру Lakehouse от Starburst шагом назад в развитии открытой архитектуры данных Lakehouse? Так просто на этот вопрос не ответить.
В качестве компонентов де-факто для своей архитектуры Starburst выбрали Trino и Iceberg. Это предполагает, что оптимальный путь к открытой архитектуре Lakehouse уже предопределен. Такой подход заметно сужает свободу выбора, оттесняя другие технологии, которые отличаются альтернативными преимуществами или больше соответствуют потребностям той или иной компании.
Смысл открытости — в выборе. Если изначально включить в архитектуру определенные решения, то исчезает свобода выбора и открытость. В какой момент заканчивается открытость? Два изначально заданных решения? Пять? Десять? Да, можно выбрать два компонента для архитектуры, особенно той, что славится своей гибкостью при замене компонентов. Но это не приводит к созданию принципиально новой архитектуры, которая заслуживает собственного названия. Архитектуру Starburst нужно воспринимать как вариацию более широкой концепции открытой архитектуры Lakehouse, а не как блестящее будущее Open Lakehouse.
Какие альтернативы Starburst оставили без внимания
Apache Iceberg и Trino — отличные компоненты для Lakehouse, но далеко не единственные. В этом прелесть открытой архитектуры: можно выбирать технологии, которые подходят именно для ваших сценариев использования. Вот несколько табличных Open-Source-форматов и вычислительных решений, которые, возможно, лучше подойдут вам.
Табличные форматы
Apache Hudi. Это мощный фреймворк, который за минуты выполняет инкрементную обработку аналитических данных с низкой задержкой. Он отлично подходит для передачи потоковых данных из CDC-источников данных.
Delta Lake. Оптимизированный уровень хранилища, который обеспечивает основу для хранения данных и таблиц в Lakehouse от Databricks.
Apache Paimon. Формат озера данных, в котором с помощью Apache Flink и Apache Spark можно создать архитектуру Lakehouse, в реальном времени выполняющую потоковые и пакетные операции.
Apache Spark. Унифицированный Open-Source-фреймворк обработки больших объемов данных. Spark отлично подходит для тех, кому стабильность продолжительных рабочих нагрузок ETL важнее времени задержки при выполнении запроса.
Presto. Быстрый и надежный Open-Source-механизм обработки SQL-запросов, хорошо справляющийся с большими масштабами работы. Presto отлично подходит для выполнения интерактивных и оперативных запросов в открытом озере данных.
StarRocks. Высокопроизводительный механизм обработки SQL-запросов в Lakehouse, способный выдерживать максимальные рабочие нагрузки в озере данных. Если вы имеете дело с рабочими нагрузками SQL с небольшой задержкой и высокой степенью параллелизма, которые выполняются прямо в открытом Lakehouse и ориентированы на конечного пользователя, то обратите внимание на StarRocks. (Комментарий от редакции: Статья первоначально была опубликована в блоге StarRocks, поэтому нужно аккуратно относится к этому хвалебному определению).
Выводы
На самом деле важно не то, какое название звучит круче. Важно, насколько архитектура, будь то Lakehouse или что-то другое, отвечает вашим задачам. Помните, что при выборе решения для работы с данными не стоит следовать моде. Нужно просто не ограничивать себя в выборе и подобрать сочетание технологий, которые подходят именно для вашей ситуации.