Модуль 11. Advanced-возможности StarRocks
Методологическое понимание Advanced-функций
Когда мы ставим StarRocks в продакшн, на первых этапах обычно достаточно «базового» функционала: ingestion, партиционирование, MV, оптимизация SQL.
Но при росте нагрузки, числа пользователей и объёмов данных мы можем столкнуться с задачами, которые требуют:
- Высокой адаптивности к нагрузкам (автомасштабирование, Kubernetes).
- Максимальной скорости (vectorized execution, CBO).
- Интеграции с real-time обработкой (Flink/Spark).
- Работы с Lakehouse напрямую (Iceberg/Hive/S3).
- Реализации real-time dashboard с SLA в секунды.
Advanced-возможности — это не «навороты», а инструменты для удержания SLA при росте.
Kubernetes-развёртывание
Зачем:
- Гибкое масштабирование BE под ingest-пики.
- Автоматический перезапуск упавших нод.
- Лёгкое управление обновлениями (rolling update).
Методология:
- FE — StatefulSet с anti-affinity (разнести по разным нодам).
- BE — StatefulSet или DaemonSet с локальными NVMe (в облаке — локальные диски).
- Разделить node-pools под FE и BE.
Пример Helm Chart-параметров:
fe:
replicas: 3
resources:
limits:
cpu: "8"
memory: "32Gi"
be:
replicas: 10
resources:
limits:
cpu: "32"
memory: "256Gi"
Риск: если хранить данные на ephemeral-дисках и потерять ноду — данные исчезнут.
Защита: либо использовать PersistentVolume, либо RF=3 и быстрый rebalance.
Vectorized Execution Engine
Что это: обработка данных батчами (vectorized), а не построчно.
Выгода: в 3–5 раз быстрее на CPU-bound запросах.
Методология:
- Vectorized engine включён по умолчанию с версии 2.x.
- При миграции со старых версий проверить корректность SQL (некоторые функции ведут себя чуть иначе).
- Оптимизировать batch size (vector_chunk_size) для нагрузки.
Кейс:
- Отчёт с 2 млрд строк, тяжёлая агрегация.
- После включения vectorized engine время снизилось с 40 сек до 8 сек.
Cost-Based Optimizer (CBO)
Что это: оптимизатор, который строит план запроса на основе статистики.
Выгода: правильный выбор join-стратегий (hash, broadcast), порядок соединений.
Методология:
- Регулярно собирать статистику:
sql
КопироватьРедактировать
ANALYZE TABLE sales;
- Следить за обновлением статистики после массовой загрузки или удаления данных.
Риск: устаревшая статистика → CBO выбирает неэффективный план.
Защита: автоматизировать ANALYZE TABLE по расписанию.
Интеграция с Flink и Spark
Flink Connector:
- Чтение и запись в StarRocks в real-time.
- Используется для потоковой трансформации данных перед ingestion.
Spark Connector:
- Массовая загрузка batch-данных.
- Используется для тяжёлых ETL с агрегацией перед загрузкой.
Методология:
- Для Flink — настраивать batch flush size и interval, чтобы не перегружать StarRocks.
- Для Spark — избегать слишком большого числа параллельных коннектов.
Lakehouse-интеграция (Iceberg/Hive/S3)
Что даёт:
- Чтение данных без копирования.
- Возможность смешивать данные из внешних таблиц и StarRocks.
Пример подключения Iceberg:
CREATE EXTERNAL CATALOG iceberg_catalog PROPERTIES ( "type"="iceberg", "iceberg.catalog.type"="hive", "hive.metastore.uris"="thrift://metastore:9083" );
Риск: полное сканирование Iceberg-таблиц при отсутствии партиционного фильтра.
Защита: создавать MVs в StarRocks на часто используемые подмножества данных.
Real-time Dashboards с SLA в секунды
Методология:
- Используем PK-таблицы для upsert/delete в real-time.
- Routine Load из Kafka/Flink.
- MVs для агрегации и фильтрации.
- BI подключаем только к MV.
- Query Cache включаем для стабильных отчётов.
Кейс:
- Мониторинг заказов в e-commerce (обновление <3 сек).
- Kafka → Routine Load → MV → Power BI DirectQuery.
- SLA по P95 = 1,2 сек.
Риски Advanced-функций и защита
|
Риск |
Симптом |
Как избежать |
|---|---|---|
|
Потеря данных на ephemeral-дисках в K8s |
Пустые партиции |
RF=3, PersistentVolume |
|
Устаревшая статистика для CBO |
Долгие запросы |
Регулярный ANALYZE |
|
Перегрузка BE от Flink ingestion |
Высокий CPU, lag |
Настроить batch size |
|
Медленные внешние таблицы |
Латентность BI |
MV на подмножество |
|
Кэш с устаревшими данными |
BI видит старое |
TTL кэша, invalidate при обновлении |
Методологические рекомендации
- Использовать Kubernetes только при зрелой эксплуатации — для начала проще bare-metal/VM.
- Включить vectorized execution и следить за batch size.
- Автоматизировать сбор статистики для CBO.
- Разделять ingestion и BI-нагрузку по разным пулам BE.
- Для Lakehouse-интеграции — кэшировать и материализовать ключевые витрины.
