Модуль 12. Практический кейс: Построение аналитической витрины в StarRocks

Методологический подход

Витрина в StarRocks — это не просто «таблица с данными». Это целевой слой данных, который:

Обновляется в нужные SLA (от real-time до раз в сутки).
Содержит только необходимые поля для BI и аналитики.
Предоставляет данные в оптимальной для запросов форме (агрегированной, предрассчитанной).
Не грузит кластер ненужными джойнами и сканами.

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

Начинаем от потребности BI, а не от сырых данных.
Всегда разделяем Raw Layer → Core Layer → Presentation Layer.
Любая витрина — отдельная зона ответственности, с документацией и SLA.

Постановка задачи

Бизнес-требование: построить дашборд в Power BI по продажам e-commerce:

KPI: общая сумма продаж, средний чек, количество заказов.
Разрезы: по дате, региону, каналу продаж.
Обновление: каждые 5 минут.
Источник: события заказов из Kafka.

Шаг 1. Сырые данные (Raw Layer)

Тип таблицы: Duplicate Key (сохраняем 100% событий).

Партиционирование: по дате (order_date), час — для real-time TTL.

Дистрибуция: order_id (равномерно по BE).

DDL:

CREATE TABLE raw_orders (
    order_id BIGINT,
    order_date DATETIME,
    region_id INT,
    channel STRING,
    amount DECIMAL(10,2),
    status STRING
)
DUPLICATE KEY(order_id)
PARTITION BY DATE(order_date)
DISTRIBUTED BY HASH(order_id) BUCKETS 32
PROPERTIES (
    "replication_num" = "3",
    "storage_medium" = "SSD"
);

Загрузка: Routine Load из Kafka.

CREATE ROUTINE LOAD ecommerce.raw_orders_load
ON raw_orders
COLUMNS(order_id, order_date, region_id, channel, amount, status)
PROPERTIES (
    "desired_concurrent_number"="4",
    "max_batch_interval"="5",
    "max_batch_rows"="50000"
)
FROM KAFKA (
    "kafka_broker_list"="broker1:9092,broker2:9092",
    "kafka_topic"="orders_topic"
);

Шаг 2. Core Layer (нормализация и бизнес-логика)

Тип таблицы: Primary Key (upsert по order_id).

Задачи:

Исключить дубликаты заказов.
Отразить изменения (например, возвраты).

DDL:

CREATE TABLE orders (
    order_id BIGINT,
    order_date DATE,
    region_id INT,
    channel STRING,
    amount DECIMAL(10,2),
    status STRING
)
PRIMARY KEY(order_id)
PARTITION BY order_date
DISTRIBUTED BY HASH(order_id) BUCKETS 32
PROPERTIES (
    "replication_num" = "3",
    "enable_persistent_index" = "true"
);

Загрузка: MERGE из raw_orders каждые 5 минут через job:

INSERT INTO orders
SELECT order_id, DATE(order_date), region_id, channel, amount, status
FROM raw_orders
WHERE order_date >= NOW() - INTERVAL 1 DAY;

Шаг 3. Presentation Layer (витрина)

Тип таблицы: Aggregate Key (агрегация по региону, дате, каналу).

DDL:

CREATE MATERIALIZED VIEW mv_sales
AS
SELECT
    order_date,
    region_id,
    channel,
    COUNT(DISTINCT order_id) AS orders_count,
    SUM(amount) AS total_sales,
    AVG(amount) AS avg_check
FROM orders
WHERE status = 'completed'
GROUP BY order_date, region_id, channel;

Особенности:

MV обновляется инкрементально при новых данных.
BI подключается только к этой MV, а не к orders.

Оптимизация

Paritition pruning — фильтры по order_date в BI → сканируются только нужные партиции.
Hash distribution по region_id для равномерной нагрузки.
MV rewrite — проверка, что запросы BI переписываются в MV:

EXPLAIN SELECT * FROM mv_sales WHERE order_date='2025-08-10';

Routine Load tuning — max_batch_interval=5 сек, desired_concurrent_number=4 для баланса задержки и нагрузки.

Интеграция с BI

Подключение Power BI:

ODBC (MySQL), DirectQuery.
DSN:

Server=fe_host;Port=9030;Database=ecommerce;User=bi_user;Password=****

BI фильтры по дате, региону, каналу.

Best practice:

В BI — только MV, никакого доступа к raw/core.
Параметры запросов в Power BI → совпадают с partition keys.

Практические результаты

Задержка данных в BI: ~5–7 сек.
P95 latency отчётов: 1,4 сек.
Нагрузка на кластер: ingestion ~30% CPU, BI ~40% CPU.

Риски и защита

Риск	Симптом	Как избежать
BI подключается к orders	Долгие запросы	Ограничить права
Lag в ingestion	BI видит неполные данные	Настройка Routine Load, мониторинг lag
MV не переписывается	Запросы в сырые данные	Проверять EXPLAIN, корректировать SQL
Рост raw_orders	Переполнение диска	TTL на сырые партиции

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

Витрина всегда под конкретный отчёт — никакой «универсальной» огромной таблицы.
Инкрементальные MV для снижения нагрузки.
Разделение зон raw/core/presentation по схемам или базам.
Мониторинг lag и обновления MV в Grafana.
Документация по витрине — поля, формулы, источники, SLA.

← Предыдущая статья

Модуль 11. Advanced-возможности StarRocks

Следующая статья →

Глоссарий терминов по внедрению StarRocks