Проект Trino (ранее PrestoSQL) изначально разработан в Meta, чтобы аналитики могли выполнять интерактивные запросы по широкому спектру хранилищ данных на базе Apache Hadoop. Благодаря эффективной обработке крупных наборов и сложных запросов, а также гибкому подключению к множеству источников данных, Trino быстро стал предпочтительным инструментом аналитики для крупных организаций.

Со временем потребности пользователей в аналитике эволюционировали. С ростом мобильного интернета и SaaS-приложений критически важной стала оперативная (в том числе потоковая) аналитика. Компаниям потребовались более производительные движки, поддерживающие большое число одновременных запросов и обеспечивающие низкие задержки. На этом фоне всё больше пользователей стали искать альтернативы.

StarRocks как новый аналитический движок получил широкое признание отрасли. Он демонстрирует заметные преимущества по производительности, поддержке высокой степени параллелизма и низкой задержке, привлекая внимание крупных компаний, В чём его сходства и различия с Trino? Ниже — подробный разбор.

Сходства StarRocks и Trino

1. Масштабно‑параллельная (MPP) архитектура

Оба движка используют MPP в качестве распределённого фреймворка выполнения: один запрос разбивается на множество логических и физических единиц и исполняется параллельно на нескольких узлах. В отличие от модели ‘scatter‑gather’, применяемой во многих других аналитических системах, MPP позволяет задействовать больше ресурсов для обработки запроса. Благодаря этой архитектуре оба движка работают с данными масштаба PB; сотни крупных пользователей применяют их в продакшене.

2. Оптимизатор на основе стоимости (CBO)

Оба движка имеют встроенный эффективный оптимизатор на основе стоимости (CBO), особенно важный для многотабличных запросов с JOIN. Благодаря CBO движки поддерживают широкий спектр возможностей SQL, включая сложные запросы, JOIN и агрегирование. Trino и StarRocks проходят бенчмарки TPC‑H и ещё более сложный TPC‑DS, демонстрируя выдающуюся производительность.

3. Конвейерная (pipeline) модель выполнения

Оба движка используют конвейерную (pipeline) модель выполнения, главная цель которой — повысить эффективность использования многоядерных систем на одном узле. Ключевые эффекты:

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

• повышение загрузки CPU за счёт одновременной обработки запросов;

• автоматическая настройка степени параллелизма выполнения для максимального использования многоядерности и роста производительности.

4. Поддержка ANSI SQL

Оба движка соответствуют ANSI SQL, поэтому аналитики могут использовать привычный язык запросов без дополнительных затрат на обучение. Популярные BI‑инструменты легко интегрируются как со StarRocks, так и с Trino.

Отличия StarRocks и Trino

1. Векторизованный движок запросов

StarRocks — нативный векторизованный движок на C++ с полной векторизацией критических путей загрузки и выполнения запросов. Trino реализован на Java и использует ограниченные приёмы векторизации. Векторизация позволяет StarRocks эффективнее задействовать вычислительную мощность CPU и имеет следующие преимущества:

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

• Использование SIMD‑инструкций CPU: больше вычислений за меньшее число тактов; применение векторных инструкций обеспечивает рост общей производительности в 3–10 раз.

• Более эффективное сжатие данных и значительное снижение потребления памяти, что улучшает обработку запросов по большим объёмам данных.

Trino также развивает векторизацию: в кодовой базе есть SIMD‑участки, но по глубине и охвату они уступают StarRocks. Проект Velox от Meta нацелен на ускорение запросов Trino за счёт векторизации, однако пока немногие компании используют Velox в продакшене.

2. Материализованные представления

У StarRocks есть несколько возможностей материализованных представлений, которых нет у Trino. Оба движка позволяют создавать материализованные представления как средство ускорения запросов, но StarRocks дополнительно:

• автоматически переписывает запросы (query rewrite), выбирая подходящее материализованное представление — пользователю не нужно менять SQL;

• поддерживает обновление материализованных представлений на уровне разделов (partition‑level refresh), снижая потребление ресурсов и повышая производительность и масштабируемость;

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

В Trino отсутствуют:

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

• запись материализованных представлений на локальные диски.

3. Система кэширования

StarRocks, опираясь на собственную библиотеку кэширования данных, предоставляет эффективные возможности кэша:

• двухуровневый кэш (память + диск), более гибкий и управляемый по сравнению с чисто дисковым кэшированием;

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

• валидация кэша на основе информации об обновлениях файлов, исключающая рассогласование локального кэша и удалённого источника;

• проверка контрольных сумм (checksum) для данных дискового кэша, предотвращающая чтение повреждённых данных при сбоях диска и т. п.;

• адаптивный кэшируемый I/O: при высокой пропускной способности I/O часть запросов автоматически маршрутизируется к удалённому источнику, максимально используя пропускную способность локальных дисков и сети и повышая общий I/O‑трафик;

• прогрев кэша: с помощью оператора CACHE SELECT можно однократно или по расписанию прогревать данные указанных объектов, избегая проблем производительности при первом «холодном» чтении.

В версии 3.3 планируется:

• адаптивная настройка объёма кэша: динамическое изменение размера кэша в зависимости от свободного места на диске, оперативное освобождение пространства для приоритетных модулей при дефиците и автоматическое увеличение кэша при избытке для повышения коэффициента попаданий (hit rate);

• приоритеты и TTL для заданных кэш‑объектов: кэширование разных объектов с разными приоритетами в зависимости от потребностей.

По сравнению с этим, кэш Trino пока не получил широкого распространения. У StarRocks в 3.3 функциональность кэша зрелая и включена по умолчанию.

4. Производительность JOIN

Оба движка поддерживают сложные операции JOIN, однако StarRocks обеспечивает более высокую производительность. Помимо векторного движка, он использует расширенные алгоритмы переупорядочивания JOIN (Join Reorder), позволяющие найти более эффективный порядок соединений с учётом размеров таблиц и порядка выполнения.

Переупорядочивание JOIN может выполняться оптимизатором или задаваться пользователем. Обычно оптимизатор стремится минимизировать стоимость запроса. В StarRocks реализованы, в частности:

• жадный алгоритм (Greedy algorithm): итеративный выбор пары таблиц с минимальной стоимостью JOIN и их объединение;

• алгоритм динамического программирования (Dynamic programming algorithm): построение таблицы стоимостей для пар таблиц и поиск оптимального плана JOIN;

• алгоритм исчерпывающего перебора (exhaustive search): разбиение JOIN на более мелкие управляемые задачи, что позволяет обрабатывать соединения, не помещающиеся целиком в память;

• переупорядочивание левоглубоких планов (Left‑deep join reordering): эвристика, рекурсивно строящая левоглубокое дерево JOIN, начиная с наименьшей таблицы;

• ассоциативность JOIN (Join Associativity algorithm): применение свойства ассоциативности к многотабличным соединениям; поддерживаются Inner/Semi/Cross/Anti/Outer JOIN; при больших различиях в размерах таблиц‑измерений и неодинаковой селективности предикатов связи с фактовой таблицей порядок JOIN автоматически изменяется для повышения эффективности;

• коммутативность JOIN (Join Commutativity algorithm): использование свойств коммутативности для перестановки операндов без изменения результата.

StarRocks выбирает стратегию Join Reorder в зависимости от числа узлов JOIN: при малом числе — перебор вариантов; при количестве до 10 — динамическое программирование и жадный алгоритм; свыше 10 — только жадный алгоритм. Такая диверсификация позволяет находить оптимальные планы при небольшом числе JOIN и быстро генерировать эффективные планы при большом.

Чтобы план был оптимален и в распределённой среде, StarRocks сохраняет порядки JOIN, сгенерированные разными алгоритмами, и затем в структуре Memo выбирает оптимальный план для распределённого выполнения.

5. Высокая доступность (HA)

В StarRocks есть два типа узлов, и каждый обеспечивает высокую доступность по своим правилам:

• фронтенд‑узлы (FE) без состояния — HA достигается развёртыванием нечётного числа FE‑узлов с выборами лидера по протоколу Raft;

• бэкенд‑узлы (BE) поддерживают репликацию, гарантирующую, что сбой отдельного узла не влияет на работу системы.

Благодаря этому StarRocks поддерживает «горячие» обновления — онлайн‑сервисы не прерываются при апгрейде.

Trino не имеет встроенной HA‑поддержки: координатор Trino — единственная точка отказа, и при его сбое система недоступна. Это означает, что при каждом апгрейде онлайн‑сервис Trino нужно останавливать. На данный момент проект Trino не предложил решение этой проблемы.

6. Источники данных и открытые форматы таблиц

Как сторонник концепции Data Mesh, сообщество Trino активно интегрирует новые источники данных. Сегодня доступно более 60 коннекторов к реляционным СУБД, озёрам данных и т. п., что позволяет использовать Trino как единый движок запросов и выполнять федеративную аналитику данных из разных источников — особенно актуально для крупных предприятий с разнообразными источниками данных. StarRocks в настоящее время сфокусирован на запросах к открытым озёрам данных, и коннекторов к иным источникам у него меньше.

StarRocks поддерживает чтение из Apache Iceberg, Apache Hudi, Apache Hive, Apache Paimon и Delta Lake и имеет определённые возможности записи в Apache Iceberg/Hive. Как видно из бенчмарков ниже, StarRocks как движок запросов к озеру данных работает быстрее. Trino поддерживает чтение и запись в Apache Iceberg, Apache Hudi, Apache Hive и Delta Lake. Согласно Roadmap StarRocks, возможности записи в открытые озёра данных будут скоро расширены.

Бенчмарки

На наборе данных TPC‑DS 1TB проведены тесты: StarRocks и Trino выполняли запросы к одному и тому же набору данных в формате таблиц Apache Iceberg с файлами Parquet. В сумме StarRocks выполнял запросы в 5,54 раза быстрее, чем Trino.

Построение Lakehouse на базе StarRocks

Опираясь на архитектуру с разделением хранения и вычислений (storage–compute separation), на материализованные представления и возможности сверхбыстрой аналитики по озеру, StarRocks помогает проще строить архитектуру Lakehouse. Используя единое открытое хранилище озера данных и выполняя прямые запросы к озеру через StarRocks, можно добиться производительности, сопоставимой с классическим хранилищем данных (DWH), и строить множество бизнес‑приложений напрямую на озере — без загрузки данных в DWH.

В сценариях, ориентированных на конечного пользователя, где требуются минимальные задержки и большое число одновременных запросов, материализованные представления StarRocks играют ключевую роль, обеспечивая моделирование «по требованию». Они не только ускоряют запросы за счёт локального хранилища на вычислительных узлах, но и автоматически обновляются — без вмешательства человека. Кроме того, автоматическое переписывание запросов позволяет получать ускорение без изменений исходного SQL.
Подробнее: «化繁为简｜中信建投基于StarRocks构建统一查询服务平台».