StarRocks 3.5 приносит точечные улучшения по надёжности, производительности и безопасности: кластерные Snapshot для DR в архитектуре shared-data (разделение хранения и вычислений), оптимизацию пакетной загрузки (Load Spill) для сокращения мелких файлов и пропуска Compaction, более гибкое управление жизненным циклом партиций (слияние по времени и автоматический TTL), многооператорные транзакции для ETL, ускорение запросов по озеру данных через автоматические глобальные словари, а также поддержку OAuth 2.0 и JWT.
Кластерные Snapshot для резервного копирования и восстановления (shared-data)
В 3.5 добавлена встроенная поддержка кластерных Snapshot в режимах shared-data. Это закрывает ключевой пробел в backup/DR.
Snapshot автоматически фиксирует полное состояние кластера (catalog, таблицы, пользователи, права) и сохраняется в объектном хранилище рядом с данными.
По умолчанию сохраняется только последний Snapshot — минимум накладных расходов на хранение.
Восстановление:
Указать новому или существующему кластеру путь к Snapshot в объектном хранилище.
StarRocks перегружает метаданные и переиспользует существующие файлы данных — копирование данных не требуется.
Восстановление занимает минуты и минимально нарушает сервис.
Итог: низкая стоимость, автоматизация, упрощённый DR для критичных нагрузок в shared-data.
Пакетная загрузка: меньше мелких файлов и стабильные запросы (Load Spill)
Проблема: из‑за лимитов памяти пакетные загрузки нередко порождали множество мелких файлов, повышали накладные расходы запросов и запускали дорогостоящий Compaction; запросы сразу после загрузки могли быть нестабильны.
Решение в 3.5 — механизм Load Spill:
При достижении порога памяти промежуточные данные проливаются (spilled) на диск крупными блоками.
Во многих случаях Compaction можно пропустить entirely, так как данные уже хорошо организованы.
Выгоды:
Стабильная производительность запросов сразу после загрузки.
Существенно меньше времени и ресурсов на Compaction.
Выше надёжность задач под конкурентной и/или высокообъёмной нагрузкой.
Примерные результаты (из публичных бенчмарков):
Data Volume & Mode | Load Spill Enabled | Ingest Time | Compaction | Query immediately after load |
100GB – Single Thread | No | 16.5 min | 8 min | 1.29 s |
Yes (Local + S3) | 19 min | N/A | 0.15 s | |
Yes (S3 Only) | 23 min | N/A | 0.12 s | |
1TB – Single Thread | No | 2h 15min | 34 min | 56.25 s |
Yes (Local + S3) | 2h 42min | N/A | 0.72 s | |
100GB – 5 Parallel Loads | No | 33 min | 49min 30s | OOM |
Yes (Local + S3) | 45 min | N/A | 0.52 s |
Более умное управление партициями: упрощение жизненного цикла и снижение накладных расходов
StarRocks 3.5 добавляет две ключевые функции:
Time-based partition merge (слияние партиций по времени).
Partition TTL (автоматическая политика удержания партиций).
Time-based partition merge
Частый паттерн: по «горячим» данным запросы идут в мелкой гранулярности (например, по дням), тогда как исторические данные можно укрупнять (месяц).
Ранее все партиции должны были иметь единую гранулярность, что вело к избытку мелких партиций и замедляло планирование.
Теперь можно использовать
ALTER TABLE ... PARTITION BY <time_expr>, чтобы сливать мелкие партиции в более крупные в заданном диапазоне дат.
Эффекты:
Быстрее планирование и отсечение партиций — сканируется меньше.
Меньше метаданных и памяти, особенно по истории.
Чище и масштабируемее схема секционирования, согласованная с паттернами доступа.
Пример:
-- Слияние дневных партиций за январь–март в месячные
ALTER TABLE sales PARTITION BY date_trunc('month', dt)
WHERE dt BETWEEN '2024-01-01' AND '2024-03-31';Partition TTL: автоматические политики просрочки
Опишите политику через partition_retention_condition (например, хранить последние 3 месяца).
StarRocks регулярно оценивает правило и удаляет старые партиции автоматически.
Работает со всеми типами партиций: range, list и expression-based.
Политику можно менять в любой момент через ALTER TABLE.
По‑прежнему можно вручную удалять партиции с WHERE для частных случаев.
Примеры:
-- Задать политику удержания при создании
CREATE TABLE t1 (
dt date,
region string,
num int
)
DUPLICATE KEY(dt)
PARTITION BY (dt, region)
PROPERTIES (
"partition_retention_condition" = "dt >= CURRENT_DATE() - INTERVAL 3 MONTH",
"replication_num" = "1"
);
-- Изменить политику удержания
ALTER TABLE t1 SET ('partition_retention_condition' = 'dt >= CURRENT_DATE() - INTERVAL 1 MONTH');
-- Удалить партиции по условию
ALTER TABLE t1 DROP PARTITIONS WHERE dt < CURRENT_DATE() - INTERVAL 3 MONTH;Более гибкие Materialized Views (MV)
Задача: ускорять запросы без избыточного роста и «застаивания» MV, особенно при работе с партиционированными таблицами и внешними каталогами.
Что нового:
Multi-column partitioning: MV могут наследовать несколько партиционных колонок (например, date, region) от базовой таблицы — лучшее соответствие внутренним и Lakehouse (Iceberg/Hive) таблицам, более эффективные refresh и partition pruning.
Partition TTL для MV: используйте тот же механизм TTL, чтобы автоматически удалять старые партиции при обновлении.
Выгоды:
Фокус на «горячих» данных (например, последние 7 дней).
Дешевле и чаще сбор статистики — дополнительный рост производительности.
Меньше хранилища и быстрее обновление.
Термины: MV (materialized view), Lakehouse, Iceberg, Hive.
Многооператорные транзакции для INSERT (Beta)
До 3.5 перенос многошаговых ETL был сложен: при сбое шага не было отката промежуточных записей.
Что добавлено:
Поддержка multi-statement transaction (Beta) — группируйте несколько операций INSERT в один атомарный блок с использованием стандартного синтаксиса BEGIN; ... COMMIT; / ROLLBACK;.
Выгоды:
Все операторы успевают вместе или не применяется ни один — no partial writes.
Откаты чистые и быстрые — без ручной очистки.
Ограничение текущей версии: поддерживаются только INSERT (основа для более полной транзакционности в будущих релизах).
Ускорение аналитики по озеру данных с автоматическими глобальными словарями
Контекст: запросы к внешним таблицам Iceberg/Hive часто сканируют широкие Parquet/ORC‑файлы с низкокардинальными строковыми колонками (country, category, gender), где строковые сравнения дороже числовых.
Новое в 3.5:
Автоматические global dictionaries для внешних Parquet и ORC таблиц — ранее такие ускорения были только для внутренних таблиц.
Почему это важно:
Меньше CPU и памяти при сканировании повторяющихся строк.
Быстрее фильтры, join и group by за счёт замены строк на целые числа.
Работает «из коробки», без ручной настройки и тюнинга.
Query | Scenario | OFF (ms) | ON (ms) | Speedup |
q01 | Count distinct on 1 low-cardinality column (<50) | 623 | 177 | 3.52× |
q12 | Group by 1 low-cardinality column (<50) | 647 | 180 | 3.59× |
q36 | Group by 2 low-cardinality + 1 high-cardinality int (200–256) | 16179 | 6687 | 2.42× |
q40 | Group by 2 low-cardinality + 1 date column (<50) | 1196 | 533 | 2.24× |
q41 | Group by 2 low-cardinality + 1 tinyint column (<50) | 1038 | 407 | 2.55× |
q46 | Group by 7 low-cardinality columns + function (<50) | 5654 | 2813 | 2.01× |
q58 | Decode before order by | 470 | 178 | 2.64× |
Результаты:
На наборе Iceberg 100GB средний выигрыш производительности в сценариях с низкокардинальными колонками — около 2.6×.
Термины: Parquet, ORC, Iceberg, Hive, global dictionary.
Безопасность уровня предприятия и аутентификация
OAuth 2.0 и JWT support: аутентификация через стандартных провайдеров идентичности — удобно для интеграции с IAM и токен‑базовыми потоками.
Security Integration с LDAP и групповым доступом: StarRocks может подтягивать пользователей и группы из внешних источников (LDAP, ОС или файлы), обеспечивая согласованное ролевое управление доступом.
SSL для протокола MySQL: шифрование клиентских соединений для соответствия требованиям безопасности и комплаенса.
