В сегодняшней, уже третьей по счету, публикации я продолжу делится результатами нагрузочных испытаний вычислительных технологий массивных параллельных вычислений (на Habr уже представлены мои материалы, посвященные сравнению Impala, Trino и Greenplum, в том числе по методике TPC-DS). В этот раз в список решений добавляется Spark, включая работающий с технологией нативных вычислений DataFusion Comet, и набирающий популярность StarRocks.

Мотивация

Нагрузочное тестирование является обязательной частью производственного процесса, через который проходят все вычислительные движки, представленные в Lakehouse-платформе данных Data Ocean Nova вендора Data Sapience. Тестирование позволяет пользователям сформировать правильное представление о возможностях технологий. Особенно это полезно при 

• Выборе движка внутри платформы для решения практических задач;

• Планировании аппаратного сайзинга (чтобы учитывать разницу);

• Выделении или перераспределении ресурсных мощностей внутри kubernetes-кластера.

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

Немного ретроспективы:

В первой публикации из цикла были: 

• сформулированы требования и подходы к правильному тестированию систем массивных параллельных вычислений; 

• предложена методика сравнения, которая хор��шо себя зарекомендовала на практике.

• выявлены сильные и слабые стороны решений в различных практических задачах;

Во второй статье:

• представлены результаты сравнения вычислительных движков Data Ocean Nova по стандартной отраслевой методике TPC-DS, которые могут являться дальнейшим эталоном;

• сопоставлены возможности современных технологий обработки с legacy-платформой Greenplum.

Конфигурация тестового окружения

С предыдущей итерации конфигурация стенда не менялась:

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

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

  • S3 Storage;

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

• TPC-DS scale-factor 10000 (~10 ТБ до сжатия);

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

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

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

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

Все запросы запускались as is из методики без внесения изменений в текст запроса. Процессинговые движки настраивались на максимальные производительность и утилизацию всех доступных аппаратных ресурсов. Между разными отдельными итерациями каждого отдельного движка система перезапускалась для сброса локального кэширования. Каждым движком индивидуально выполнялся сбор и анализ статистики. Отдельно взятый тест считался пройденным, если все 99/198/396 запросов завершились без ошибок и падений. Если падения происходили, то тестирование уходило на новую итерацию настроек и последующего запуска.

Вычислительные мощности выделялись, исходя из принципов, предъявляемых в первой публикации: объем оперативной памяти compute-кластера должен быть кратно меньше объема данных, так как такая ситуация приближена к промышленной эксплуатации.

Также мы по-прежнему не отступаем от своих принципов тестирования под нагрузкой: запросы запускались в трех итерациях:

• в 1 поток; 

• 2 конкурентных потока;

• 4 одновременных конкурентных потока.

*Вся информации, указанная ниже, актуальна на момент публикации (октябрь 2025 г.)

Результаты

Подобные системы корректно тестировать именно в массивно-параллельной нагрузке и, обязательно, кластерном варианте развертывания, а не формате “1 запрос на 1 узле”, как предлагают другие участники рынка, при этом выбирая себе самый удобный запрос для сравнения.

Признаться честно, нас приятно удивил Spark. Мы ожидали худшую производительность, так как уже имели опыт на версиях движка до 3.2 при работе в конкурентном доступе. В определенный момент убирали тесты TPC DS c использованием Spark. Очевиден огромный прогресс решения Spark от версий 2.4+.

Однако можно ли улучшить результаты Spark? Используем Lakehouse-платформу данных Data Ocean Nova в части Spark-вычислений по полной: включим нативные вычисления.

Apache DataFusion Comet — плагин-акселератор для Spark, позволяющий использовать Apache DataFusion. Это фреймворк для выполнения вычислений, предназначенный для  повышения эффективности и скорости выполнения запросов.

Упрощенно его работу можно описать следующим образом: когда Spark создает план запроса – Comet переводит его в физический план DataFusion. Как результат – часть вычислительной нагрузки ложится на нативные векторизированные вычисления вместо традиционной JVM в Spark. Сам DataFusion, написанный на Rust, использует Apache Arrow в качестве внутреннего формата обработки данных и, соответственно, благодаря процессорным SIMD-инструкциям обрабатывает данные эффективнее.

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

Текущие выводы

• Максимальную производительность при чтении данных в Lakehouse-платформе Data Ocean Nova демонстрирует движок StarRocks;

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

• StarRocks имеет схожие с Impala механизмы управления конкурентным доступом и ресурсами (workload management) с жестким разграничением. Изначально разработчики Doris/Starrocks, смотря на Impala, этим функционалом вдохновлялись и копировали, но, на мой взгляд, немного перестарались. Дело в том, что StarRocks при принятии решения о запуске запроса в ресурсном пуле, оценивает не память, зарезервированную другими запросами, а память, реально ими потребляемую. Казалось бы, благое дело, которое ведет к повышению утилизации памяти в кластере, но рано или поздно все работающие запросы достигают выделенного лимита, и происходит “пробитие” с падением по OOM. В наших планах тперь – изменить это поведение StarRocks, сделав обработку OOM, которую мы уже реализовали в Impala, и опцию учета резервированной другими запросами памяти, а не реально потребляемой (во многих сценариях работы стабильность лучше скорости!);

• Наше исследование показало, что StarRocks быстрее, чем Impala, за счет более продвинутого блочного кэширования, чтения данных с S3 и подхода оптимизации вычислений повторяющихся CTE;

• Trino при конкурентном доступе деградирует нелинейно и показывают худшую производительность при увеличении нагрузки в группе из-за местами не работающего гарантированного workload management, JVM-стека с GC под нагрузкой, отсутствия LLVM-компиляции запросов. На практике при использовании Trino при той же пропускной способности потребуется в 2-3 раза больше compute-мощностей (рассматривалось в более ранних публикациях);

• Использование Apache DataFusion Comet позволяет улучшить производительность Spark-вычислений. В платформе сейчас используется версия 0.9;

• Spark  3.5+ значительно улучшил работу при конкурентном доступе относительно предыдущих версий и релизов.

Чего мы не узнали из этого тестирования?

TPC-DS, хоть и является отраслевым стандартом, эталоном сравнения аналитических систем, имеет недостатки, о чем я упоминал в первой статье. Самый главный из них – факт, что все запросы только читают данные, но не изменяют и не пишут, нет Near Real-time, нет конкурентной нагрузки читателей-писателей. За скобками стоит все обслуживание: compaction Iceberg, сбор статистики, существенной нагрузки на метаданные и само их количество в кластере. Если не акцентировать на этом внимание, может сложиться впечатление, что StarRocks – очевидный фаворит. Однако StarRocks до сих пор не поддерживает операции Update Delete Merge при работе с табличным форматом Iceberg, поэтому область его применения все еще ограничена при режиме shared storage / open table formats.

Что дальше

Так как нагрузочное тестирование является частью релизного цикла Data Ocean Nova, мы будем продолжать публиковать результаты испытаний при их существенном изменении во время доработок движков и обновления core-части из Open Source сообщества.

Точно стоит ожидать:

• Сравнения сценариев обновления целевого объекта SCD1/SCD2 (Slow Changing Dimensions) на Trino, Impala, StarRocks и Spark (после добавления поддержки U/D/M DML-операций в StarRocks);

• Включения в сравнение Spark 4;

• Сравнения сценариев записи данных больших объектов всеми движками.

Статистика использования вычислительных движков Lakehouse-платформой Data Ocean Nova в промышленной эксплуатации показывает, что в среднем в каждой инсталляции платформы задействовано 2 и более вычислительных технологий. В строке “Число инсталляций, использующих только один движок” указан ожидаемо Spark.

Конечный пользователь или проектная команда выбирают ту технологию, которая им больше подходит для решения их задач, и не всегда она самая быстрая. В ландшафте данных в различных клиентских сценариях для разных доменов/групп пользователей используются разные движки, а иногда и сочетание движков в одной задаче. Ведь не секрет, например, что Trino имеет самые лучшие возможности гетерогенного доступа к данным из внешних источников. StarRocks пока не может изменять и обслуживать табличный формат Apache Iceberg, хоть и является самым производительным в операциях чтения. Spark – единственный движок, который эффективно выполняет полный цикл обслуживания Apache Iceberg.

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

Заключение

Осознанная политика нашей команды – максимальная открытость и прозрачность. Мы приветствуем любые объективные сравнения в публичной плоскости на аналогичной инфраструктуре и конфигурации.

Чтобы отслеживать все новости и публикации, подписывайтесь на Telegram-канал Data Sapience.

***

Справка о компании: 

Data Sapience — российский вендор, разработчик ИТ-решений для бизнеса. Разработкой продуктов занимается команда с 15-летним опытом работы в консалтинге и с ведущими вендорами. Продукты организации состоят в Реестре отечественного ПО: CM Ocean – платформа CVM-маркетинга; TALYS Ocean – платформа интегрированного управления рисками; Kolmogorov AI — платформа аналитики данных, машинного обучения и MLOps; Data Ocean Governance – платформа управления данными организации; Data Ocean – универсальная Lakehouse-платформа данных.