CedrusData Engine: что Rust-ядро даёт бизнесу

Когда дашборды руководства, регламентные расчёты и ad‑hoc‑выборки стартуют одновременно, аналитическая платформа начинает проседать: пользователи ждут, отчёты опаздывают, команда задумывается о расширении кластера. CedrusData Engine — MPP‑движок (Massively Parallel Processing, массово‑параллельная обработка) для lakehouse с переписанным на Rust вычислительным ядром — позволяет получать больше полезной аналитики на той же инфраструктуре. С марта 2026 года движок развивается в составе дата‑сервисов VK Tech рядом с VK Object Storage, Tarantool и lakehouse‑платформой VK Data Platform.

Разберём, где Rust-ядро даёт выигрыш, какие цифры приводит разработчик и как проверить эффект на своей нагрузке. Все показатели производительности ниже — заявления и внутренние тесты CedrusData, мы приводим их с атрибуцией.

Что меняет Rust‑ядро

• Больше параллельных пользователей. На конкурентной нагрузке движок держит больше одновременных запросов — это подтверждается вендорским тестом TPC‑DS.
• Быстрее интерактивная аналитика. Перенос CPU‑bound‑вычислений в Rust даёт, по внутренним измерениям CedrusData, примерно двукратный прирост, а в отдельных запросах — до трёх раз.
• Меньше нагрузки на object storage. Асинхронное чтение S3, локальный кэш и data skipping снижают сетевые задержки и объём чтения.
• Запас по инфраструктуре. Та же мощность обслуживает больше аналитической работы, поэтому расширение кластера можно отложить.

CedrusData Engine: что это и где в стеке VK Tech

CedrusData Engine — высокопроизводительный MPP‑SQL‑движок для аналитики поверх lakehouse. Технически это глубокая доработка Apache Trino: движок сохраняет совместимость с ним по форматам, конфигурации и протоколам, но добавляет корпоративные функции и собственное вычислительное ядро. Он отделяет вычисления от хранения и работает с открытыми форматами через Apache Iceberg, поэтому данные остаются в lakehouse‑слое, а вычислительный контур масштабируется отдельно.

Ключевое изменение в ядре — проект Oxide. Часть вычислительного ядра Trino команда CedrusData переписала на Rust, и Rust‑компоненты выполняют операции, которые раньше проходили через Java‑часть движка. Перенос снимает часть ограничений Java‑рантайма — управление памятью, векторизацию — на участках, где движок занят вычислениями: сканами, фильтрацией, обработкой колонок, операциями над данными в памяти. Вместе с движком CedrusData принесла в стек VK Tech второй компонент — CedrusData Catalog, собственный REST‑каталог для Apache Iceberg, который отвечает за метаданные, управление доступом, обслуживанием Iceberg и другими функциями.

Логику объединения сформулировал лидер направления дата-сервисов VK-Tech:

«Глубокая экспертность объединённой команды разработчиков в каждом отдельном компоненте — storage, обработке данных InMemory, ETL‑инструментах и каталогизации метаданных — позволяет нам представить рынку качественно новый технологический продукт».

Преимущества CedrusData Engine

Больше параллельных пользователей

Главный выигрыш Rust-ядра проявляется под высокой нагрузкой, а не на одиночном запросе. В реальной системе пользователи не договариваются запускать запросы по очереди: одновременно идут интерактивные обращения, фоновые регламентные расчёты и ad-hoc-выборки аналитиков. В таком режиме важны две вещи — латентность одного запроса и устойчивость движка под одновременной нагрузкой.

В опубликованном бенчмарке CedrusData по TPC‑DS Q1 компания сравнила изолированный запрос и четыре конкурентных. CedrusData Engine показал 21,7 секунды изолированно и 69,9 секунды в среднем при четырёх параллельных запросах. Trino в тех же условиях — 46,7 секунды и 161,9 секунды соответственно. В обоих случаях все четыре запроса завершились успешно. Это вендорский инженерный тест, поэтому цифры стоит читать как ориентир: под конкуренцией разрыв с базовым Trino заметнее, чем на одиночном запуске.

На той же инфраструктуре параллельно работает больше команд и пользователей. Меньше очередей в пиковые часы, меньше ситуаций, когда тяжёлый ad‑hoc приводит к нехватке памяти и невозможности получить отчет для руководства.

Быстрая интерактивная аналитика

Второй выигрыш касается скорости на CPU‑bound‑операциях, из которых складывается интерактивная аналитика. По внутренним измерениям CedrusData перенос таких вычислений в Rust увеличивает производительность примерно в два раза, а в отдельных запросах ClickBench (Q30 и Q38) компания заявляет ускорение до трёх раз.

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

При этом важно понимать, с чем именно сравниваются заявленные цифры. CedrusData прямо указывает, что на синтетическом тесте ClickBench её движок пока примерно вдвое медленнее DuckDB — но DuckDB работает на одном узле и не решает задачи распределённой аналитики по данным в объектном хранилище (lakehouse). Заявленное ускорение в 1,5–3 раза относится к другому сопоставлению — с распределёнными lakehouse-движками (Trino, Doris, Dremio, StarRocks), которые работают в похожем классе задач: параллельная обработка больших объёмов данных на кластере, а не на одной машине. Иначе говоря, CedrusData Engine создан для распределённых enterprise-нагрузок, и его корректно сравнивать с движками этого же класса, а не с однопроцессными инструментами вроде DuckDB.

Меньше нагрузки на object storage

Lakehouse часто упирается в чтение: данные лежат в object storage, запрос читает Parquet‑файлы, движок выбирает фрагменты, применяет фильтры, передаёт данные между стадиями. Одного CPU‑ускорения здесь мало, и Rust‑ядро даёт ещё три рычага.

• Асинхронное чтение S3. Неблокирующая работа с S3 в Rust отделяет сетевую нагрузку от CPU‑bound‑обработки. CedrusData оценивает дополнительный прирост от этой архитектуры в 1,5–2 раза в отдельных случаях.
• Локальный дисковый кэш для S3. По заявлению компании, новый локальный кэш рутинно ускоряет работу с S3 в 5–10 раз на повторяемых запросах.
• Data skipping в Parquet. Движок пропускает нерелевантные фрагменты, поэтому меньше читает и меньше считает на каждом повторяемом сценарии.

Эффект этих механизмов зависит от того, какой S3‑слой стоит под движком. В составе VK Data Platform роль object storage выполняет VK Object Storage, где метаданные держатся в RAM на in‑memory‑технологии Tarantool.

Запас по пропускной способности

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

Ускорение влияет на очередь задач и на сроки расширения инфраструктуры. В пиковые окна — утренние нагрузки, закрытие периода, маркетинговые кампании — запас по пропускной способности означает меньше задержек в моменты, когда данные особенно нужны.

Где CedrusData Engine в структуре VK Data Platform

CedrusData Engine разумно рассматривать как часть дата‑стека VK Tech: объектное хранилище, in‑memory‑ и колоночная обработка, SQL‑движок и каталог метаданных на открытых форматах. Такая связка снижает зависимость от одного поставщика: данные не заперты в проприетарном формате, а движки взаимозаменяемы. Для команд, которые планируют импортозамещение аналитического стека, это практичный путь — переход без переписывания всего конвейера данных. CedrusData российская разработка и включена в реестр российского ПО.

Как измерить выигрыш на своей нагрузке

Заявленные цифры — хороший ориентир, но эффект на конкретной платформе зависит от профиля данных, IO и конкуренции. Чтобы увидеть его предметно, достаточно небольшого пилота.

• Возьмите 10–20 типовых запросов: BI‑дашборды, ad‑hoc‑аналитику, тяжёлые агрегации, фильтрацию по партициям и несколько неудобных запросов из хвоста p95. Только «красивые» сценарии плохо переносятся на эксплуатацию.
• Зафиксируйте профиль конкуренции: измеряйте одиночный запуск и параллельную нагрузку — например, четыре, восемь или шестнадцать одновременных пользователей. Среднее время под конкуренцией растёт в разы относительно изолированного запуска, поэтому профиль нужно задать заранее.
• Разделите CPU, IO и кэш: если запрос ускорился, поймите почему — помог Rust‑компонент, сработал локальный S3‑кэш или движок прочитал меньше Parquet‑данных за счёт data skipping. Без этого сложно прогнозировать эффект на других витринах.
• Переведите результат в бизнес‑язык: пиковое окно отчётности сократилось, больше пользователей работают с дашбордами параллельно, тяжёлые ad‑hoc реже уходят в тайм‑аут, расширение кластера можно отложить.

Такой пилот отвечает на главный управленческий вопрос: сможет ли платформа данных обрабатывать больше полезной аналитической работы на доступной инфраструктуре.