TPC-DS в 07.2026. Lakehouse: Spark, Trino, StarRocks, Impala и Doris. GreenPlum & Cloudberry vs StarRocks как MPP

Привет, Хабр! На связи команда Data Sapience. С последней публикации результатов тестирования MPP-движков прошло уже несколько месяцев. За этот период произошел ряд изменений в базовых версиях open source движков и фреймворков, а также наша команда разработки внесла ряд улучшений и доработок. Все это может повлиять расстановку сил в рейтинге. В сегодняшней публикации мы представим максимальное число претендентов, среди которых:

• Spark 3.5.*;

• Spark 3.5.* + DataFusion Comet;

• Spark 4.0.1;

• Spark 4.0.1 + DataFusion Comet;

• Nova StarRocks (core based 3.5+, 4.0+);

• Nova Impala (core based 4.5);

• Trino 459, 476, 479;

• Новичок нашего рейтинга — Apache Doris.

Статья поможет вам ответить на вопросы:

• Стоит ли переходить на Spark 4 в поисках производительности;

• Как нативные вычисления влияют на результаты Spark;

• Как улучшилась производительность Trino за последние полгода;

• Стоит ли присмотреться к Apache Doris, если вы ищете альтернативу Impala и StarRocks, и как эти проекты связаны между собой;

• Какие оптимизационные улучшения были добавлены нами в StarRocks и Impala за последнее время.

И на десерт мы покажем вам сравнение Greenplum, Cloudberry и StarRocks в режиме Shared-Nothing MPP.

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

Представленные вычислители являются частью Lakehouse-платформы данных Data Ocean Nova, которую мы, команда Data Sapience, разрабатываем продолжительное время. Тестирование проводится нами регулярно как часть релизной политики. Эта информация используется нами, нашими партнерами-интеграторами и клиентами для формирования правильных ожиданий по SLA, планирования аппаратного сайзинга, выбора вычислительной технологии или набора технологий для решения своих задач. Во все compute-движки команда разработки вносит изменения для улучшения производительности, поэтому публикуемые результаты вы можете использовать для оценки быстродействия своих сборок на базе pure open source. С актуальным накопленным списком изменений можно ознакомиться на сайте.

Особняком в сегодняшнем рейтинге стоит Apache Doris. Эта технология не является (и не планирует стать в будущем) частью платформы Data Ocean Nova и добавлена в текущий рейтинг отчасти по просьбе русскоязычного сообщества Data Engineers, и отчасти потому, что в русскоязычном пространстве среди поставщиков услуг и продуктовых компаний отсутствует сравнительные тестирования с участием Doris, либо участники этого сегмента не раскрывают результаты публично.

Также напомню: оценка всех движков проводится по следующим принципам:

• Только кластерная конфигурация. Никаких «тестирований на одном узле»;

• Адекватное соотношение объема набора данных относительно вычислительных ресурсов кластера. В нашем случае используется dataset TPC-DS объемом сырых данных в 10 Тб (2 Тб в сжатом виде) на ~1+ Тб суммарной оперативной памяти кластера;

• Конкурентная нагрузка. Никаких запусков запросов по очереди. Согласно методике TPC-DS, запуски происходят в четыре конкурентных потока, каждый из которых имеет индивидуальный набор последовательных SQL-запросов, построенный так, чтобы избежать попадания в кэш при повторном запуске запроса в конкурентном потоке. Однопоточный режим используется лишь как «квалификация» или эталон сравнения между версиями одного движка, чтобы оценить влияние изменений в оптимизаторе или других компонентах движка на отдельные виды операций.

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

Рекомендую ознакомиться с первой частью этой статьи, в которой детально описываются мотивация и предпосылки формирования требований к нагрузочному тестированию, обсуждается, какую методику следует выбирать и какие методики выявляют те или иные особенности работы MPP-движка, а также объясняется, когда следует максимально скептически отнестись к результатам и протоколу.

Тестовое окружение

Испытания проводились в Яндекс.Облаке:

• Использовались managed-сервисы:

  • S3 Storage;

  • Managed Kubernetes, в котором разворачивались compute-тенанты каждого движка Lakehouse-платформы Data Ocean Nova;

• Генерация данных выполнялась через Spark;

• Файловый формат Parquet, сжатие ZSTD (Compression Ratio 3), табличный формат Iceberg;

• Целевой объем данных в сжатом виде ~2+ ТБ;

• Данные секционированы.

Результаты

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

Spark

С переходом на 4-ю версию Spark не стоит ожидать прорывной производительности  относительно редакции 3.5+. Внедрение Spark 4 скорее стоит рассматривать, исходя из соображений новой функциональности — например, Spark SQL Scripting. 

Использование нативных вычислений DataFusion Comet при интенсивной нагрузке по-прежнему добавляет те же 30% к производительности, несмотря на обновленную версию Comet в сборке платформы.

Trino

Очевидное улучшение производительности при конкурентном доступе – ранее традиционно слабом месте Trino. Давайте попробуем отобрать все изменения за полтора года (с момента последней публикации), которые могли повлиять на результаты TPC-DS. 

В версиях 462 и 463 был изменен протокол внутренних коммуникаций,что ощутимо повлияло на любые запросы с интенсивным перемешиванием (shuffle) данных: агрегации, операции соединения и сканирования с exchange. Теперь протокол использует мультиплексирование запросов поверх одного соединения, устраняя лишние блокировки. В версии 465 улучшена производительность запросов Iceberg при многократном сканировании одной таблицы (в TPC-DS с CTE-выражениями в запросах это дает хорошую прибавку). В 476-й версии улучшена производительность селективных соединений (lookup-операции по справочникам, коих достаточно в базовом наборе TPC-DS).

StarRocks, Doris, Impala

Я не случайно объединил эти три движка в одной таблице. Уже на стадии инкубации из начального прототипа Palo компании Baidu проект Doris декларировал себя как объединение идей движка хранения Google Mesa и процессинга Impala (incubating proposal для тех, кому интересно). Оптимизатор, координатор и каталог были объединены в один компонент Front End (FE), и проект находился в поиске эффективного распределенного движка хранения (distributing engine), пока от него с теми же благородными идеями не «форкнулся» StarRocks.

В 2020 г. часть команды Apache Doris приняла решение покинуть проект и выделить отдельный форк. Цель состояла в том, чтобы решить нарастающие проблемы, которые Doris, по их мнению,  с текущими приоритетами и дорожной картой не был в состоянии решить.

Конкретно раскол произошел по классическому инженерному вопросу: инкрементальное развитие против переписывания с нуля. «Эволюционисты» считали, что нужно улучшать систему постепенно, сохраняя совместимость с действующими пользователями; «революционеры» настаивали на том, что старый код – это технический долг, и только переписывание движка с нуля позволит достичь настоящей производительности. При этом «революционеры» продолжали полагаться на distribution engine.

Пока «милые бранились», на рынке начали стремительно развиваться открытые табличные форматы (OTF), которые в принципе похоронили проекты, пытавшиеся решить проблему обновлений в реальном времени с эффективным изменением по ключу при сохранении колоночного формата хранения для быстрой аналитики: Google Mesa, Apache Kudu и другие.

Во время «войны OTF» разные команды делали ставку на разные форматы, и к тому моменту, когда триумф Iceberg стал очевиден, Impala, Doris и StarRocks оказались в разном состоянии в части поддержки его возможностей.

Мало того что Doris и StarRocks ввиду китайских корней изначально были ориентированы на Hudi, так и до появления OTF основным вектором их развития служил собственный бинарный формат хранения, в том числе рассчитанный на работу в конфигурации shared-nothing архитектуры. Поэтому к моменту победы Iceberg в части его поддержки Doris и StarRocks оказались в роли догоняющих, и если первый к весне 2026 г. все же догнал, то второй все еще в процессе.

*По состоянию на июль 2026 г. StarRocks все еще не поддерживает ряд операторов изменения на Iceberg, но на результаты TPC-DS это обстоятельство не повлияет, ввиду его специфики.

Doris показал себя в этой группе хуже всех при конкурентной нагрузке. Все три движка «под капотом» имеют немного разные принципы управления конкурентной нагрузкой. StarRocks и Doris следуют концепции soft limits, в отличие от Impala, где действует принцип жестких ограничений ресурсов (hard limits). Однако Doris «мапит» свои workload-группы на cgroups, и задача распределения «софт-лимитов» частично перекладывается на планировщик ядра ОС.

Пайплайн обработки StarRocks делит поток инструкций на «микрозадания» и распределяет их по рабочим потокам. На практике это дает StarRocks более предсказуемый и плавный soft limit по CPU, так как движку не нужно постоянно делать переключение контекста на уровне ОС.

Справедливости ради отмечу, что Apache Doris в данном тесте был представлен не самой последней версией, так как 4-я редакция движка вышла уже после проведения всех тестов. По заявлениям команды разработчиков Doris, они получили разницу в 19% в пользу 4й версии, поэтому мысленно мы можем сравнить и с четверкой.

StarRocks и Impala у нас далеки от «ванили», что, конечно, тоже влияет на результаты. В этой итерации тестирования для Impala была добавлена опция передачи runtime-фильтров в правую часть плана запроса. Подробнее о том, как это работает (с графическим планом и профилем запроса на примере Q1), я рассказывал в одной из публикаций ранее.Также был активирован новый механизм tuple cache, частично обновленный нами, в том числе для корректной работы вышеописанного изменения в оптимизаторе, а частично заимствованный из upstream версии. Tuple cache реализует кэширование результатов поддеревьев плана запроса на уровне отдельных узлов-исполнителей. При повторяющемся фрагменте запроса вместо повторного чтения из S3 (или, например, повторного выполнения операции агрегации) движок отдает данные из кэша. Кэширование выполняется на диск, а не в память.

Tuple cache помогает в сценарии повторного сканирования таблицы в рамках одного запроса через CTE или подзапросы. Эта функция очень полезна в инфраструктурных окружениях, где объектное хранилище значительно уступает в скорости дисковой подсистеме на узлах Kubernetes-кластера или, как в случае с Яндекс Облаком, вообще является внешним сервисом.

Для StarRocks нами была реализована доработка материализации на локальный диск кэша запросов (query cache) как при работе с внешними данными (parquet или iceberg в S3), так и для работы с внутренним каталогом StarRocks. Сам по себе механизм кэширования есть в open source, однако он доступен только для внутренних OLAP-таблиц и использует только оперативную память – самый ценный ресурс в условиях конкурентной нагрузки и ограниченности вычислительных мощностей. В нашем случае материализация query cache на локальные диски позволила повысить производительность в запросах, содержащих CTE. При этом на кластере отсутствовала повышенная утилизация оперативной памяти, что не приводило к ожиданиям в очереди других запросов в параллельных потоках из-за нехватки ресурсов. Кэш на диске также поддерживает механизм вытеснения LRU, что регулирует объем занимаемого пространства с учетом доступного места.

С полными изменениями относительно open source можно всегда ознакомиться на отдельной странице. 

Общее сравнение

Давайте теперь соберем все результаты последних релизных сборок вместе

Десерт. Сраниваем GreenPlum, Cloudberry и StarRocks в режиме Shared-Nothing

«Дом у озера» — это, конечно, хорошо, но не стоит забывать про отдельный сегмент рынка, на котором ввиду специфических функциональных задач и объемов данных востребован архитектурный подход shared-nothing MPP с локальным размещением данных, а не на объектном хранилище.

Условия теста:

• TPC-DS 10K RAW;

• Аренда мощностей в ЯО;

• Равная аппаратная конфигурация систем;

• Колоночное хранение, ZSTD Level 3;

• Типы дисков: SSD non-replicated с максимальной производительностью, доступной у оператора облака;

• Программно ускоренная сеть.

Оборудование

StarRocks FE / Greenplum & Cloudberry Master

StarRocks BEs / Greenplum & Cloudberry Segment hosts

Суммарные ресурсы кластера

Результаты

Стоимость вычислений рассчитывалась по стоимости аренды вычислительных мощностей, необходимых для конкурентного расчета, по биллинг-калькулятору облачного оператора на май 2026 г. 

“Вы все еще кипятите?”. Мы для вас уже коннектор StarRocks для Greenplum сделали.

*Расклад между Greenplum и Cloudberry будет меняться в пользу Cloudberry, потому что проект активно внедряет новый формат хранения PAX, который принесет долгожданную min max фильтрацию сканирования и эффективные блум-индексы.

Выводы

Давайте подведем промежуточные итоги на июль 2026 г.:

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

• StarRocks остается лидером тестирования по методике TPC-DS и прибавил незначительно с переходом на 4й релиз;

• Spark 4 в текущих релизах не добавил производительности;

• Doris в настоящий момент не выглядит предпочтительным вариантом не только относительно StarRocks, но и даже «примерной мамы» — Impala;

• Результаты Impala и StarRocks в конкурентной работе нам удалось улучшить за счет собственных изменений;

Чего стоит ожидать в следующих публикациях:

• Как на Trino повлияет завершенная нами переработка проектов Gluten и Velox в рамках перевода движка на нативные вычисления в будущем релизе;

• Как изменения, вносимые нами в StarRocks и Impala, будут влиять на дальнейшие результаты производительности;

• Что изменится в с точки зрения производительности Spark 4.1.

Спасибо, что дочитали до конца! Подписывайтесь на блог Data Sapience на Хабре и наш телеграм-канал.