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: шифрование клиентских соединений для соответствия требованиям безопасности и комплаенса.
Ссылки
ссылка на оригинал статьи https://habr.com/ru/articles/935216/
Добавить комментарий