Модуль 7. Оптимизация производительности в StarRocks

Методологическое понимание оптимизации

В StarRocks оптимизация — это системная работа на трёх уровнях:

Моделирование данных — правильный выбор типа таблиц, партиций, дистрибуции, MV (разбирали в Модуле 4).
SQL и план выполнения — фильтрация по партициям, hash join по ключам, предагрегация (Модуль 6).
Системные настройки — конфигурация FE/BE, управление ресурсами, параллелизм, compaction, ingest tuning.

Методология:

Сначала оптимизируем модель и SQL, только потом идём в системный тюнинг.
Тюнинг под одну задачу может ухудшить другую — тестируем на репрезентативных нагрузках.
Все параметры документируем, чтобы не потерять изменения при обновлениях.

1. Параллелизм выполнения запросов

StarRocks — MPP-система, и правильный параллелизм решает половину проблем с латентностью.

Ключевые параметры (на уровне сессии или кластера):

parallel_fragment_exec_instance_num — число фрагментов на BE при выполнении.
pipeline_dop — степень параллелизма внутри одного фрагмента (в новом pipeline engine).
exec_mem_limit — лимит памяти на запрос.

Методология:

2. Компакшн (Compaction)

Компакшн — объединение мелких сегментов в крупные, чтобы ускорить сканирование.

Проблема: при большом ingest (особенно PK-таблицы с upsert) compaction может забить диски и CPU.

Советы:

Разделить compaction-окна: в пиковые часы — только ingestion, ночью — full compaction.
Параметры:
- disable_auto_compaction=true — полностью вручную.
- cumulative_compaction_check_interval_seconds — частота проверки.
- base_compaction_check_interval_seconds — для крупных сегментов.
Мониторить очередь compaction (SHOW PROC '/compactions').

3. Кэширование (Query Cache, Page Cache)

Методология:

4. Распределение данных

Равномерный hash distribution по бизнес-ключу — обязательный минимум.
Избегать ключей с «горячими» значениями (например, region_id если один регион = 50% данных).
Для маленьких таблиц, часто джойнящихся с большими — использовать broadcast join.

5. Индексы и статистика

StarRocks не имеет классических B-Tree индексов, но:
- Sort Key улучшает сканирование.
- Zone Map автоматически создаётся.
Статистика (ANALYZE TABLE) помогает оптимизатору CBO выбирать правильный план.
Обновлять статистику при массовой перезагрузке данных.

Кейс 1. BI на 200 аналитиков

Проблема: отчёты открываются по 8–12 сек.
Диагностика: PROFILE показал, что 80% времени уходит на shuffle при join.
Решение:
- Переразбили таблицы по ключу join.
- Включили parallel_fragment_exec_instance_num=4.
- Уменьшили pipeline_dop для лёгких запросов, чтобы избежать контеншна.
Результат: P95 латентности снизилось до 1,9 сек.

Кейс 2. Real-time ingestion из Kafka

Проблема: lag в ingestion, compaction не успевает.
Решение:
- disable_auto_compaction=true в пике.
- Ночной скрипт запускает ручной compaction.
- Увеличили max_batch_rows в Routine Load.
Результат: lag снизился с 15 до 2 мин.

Кейс 3. Ограничение «тяжёлых» пользователей

Проблема: один отдел BI запускал join трёх сырых таблиц по 500 млн строк.
Решение:
- Ввели exec_mem_limit=8 GB для их пользователей.
- Создали MV с готовыми агрегациями.
Результат: нагрузка на BE стабилизировалась, SLA других отчётов не упал.

Риск	Симптом	Как избежать
Слишком высокий параллелизм	BE уходят в swap, рост latency	Ограничивать pipeline_dop, тестировать
Компакшн душит ingest	Lag, задержка данных	Развести по времени, ручное управление
Неравномерная дистрибуция	Одни BE перегружены	Выбор равномерного hash key
Нет статистики	Плохие планы CBO	ANALYZE TABLE после крупных загрузок
Перекос в join	Shuffle на TB данных	Broadcast join для маленьких таблиц