Асинхронные материализованные представления¶

В этом разделе описано, как понимать, создавать, использовать и администрировать асинхронные материализованные представления. Асинхронные MV поддерживаются, начиная с StarRocks v2.4.

По сравнению с синхронными MV, асинхронные MV поддерживают многотабличные JOIN и больше агрегатных функций. Обновление асинхронных MV может запускаться вручную, регулярно по заданному расписанию или автоматически при изменении данных в базовых таблицах. Можно обновлять только часть партиций вместо всего MV, существенно снижая стоимость обновления. Кроме того, асинхронные MV поддерживают разнообразные сценарии переписывания запросов, обеспечивая автоматическое «прозрачное» ускорение.

Сценарии и использование синхронных MV (Rollup) см. в Synchronous materialized view (Rollup).

Обзор¶

Приложения в СУБД часто выполняют сложные запросы к большим таблицам. Такие запросы включают многотабличные JOIN и агрегации по таблицам с миллиардами строк. Обработка подобных запросов затратна по системным ресурсам и времени вычисления.

Асинхронные MV в StarRocks разработаны для решения этих задач. Асинхронное MV — это специальная физическая таблица, в которой хранятся предвычисленные результаты запросов на основе одной или нескольких базовых таблиц. При выполнении сложных запросов над базовыми таблицами StarRocks возвращает предвычисленные результаты из соответствующих MV. Это повышает производительность, поскольку избегаются повторные сложные вычисления. Эффект особенно заметен для часто повторяющихся или достаточно сложных запросов.

Кроме того, асинхронные MV особенно полезны для построения математических моделей поверх вашего хранилища данных. Так вы можете предоставить унифицированную спецификацию данных для приложений верхнего уровня, скрыть нижележащую реализацию или защитить исходные данные базовых таблиц.

Понимание MV в StarRocks¶

В версиях StarRocks v2.3 и ниже существовали синхронные MV, которые можно было строить только на одной таблице. Синхронные MV (Rollup) обеспечивают высокую «свежесть» данных и низкую стоимость обновления. Однако по сравнению с асинхронными MV (поддерживаются с v2.4) синхронные MV ограничены: при построении синхронного MV для ускорения или переписывания запросов доступен ограниченный набор агрегирующих операторов.

Сравнение возможностей ASYNC MV и SYNC MV в StarRocks:

	Single-table aggregation	Multi-table join	Query rewrite	Refresh strategy	Base table
ASYNC MV	Yes	Yes	Yes	Asynchronous refresh Manual refresh	Несколько таблиц из: Default catalog External catalogs (v2.5) Существующие MV (v2.5) Существующие View (v3.1)
SYNC MV (Rollup)	Ограниченный набор агрегатных функций	No	Yes	Синхронное обновление при загрузке данных	Одна таблица в default catalog

Базовые понятия¶

Base table

Базовые таблицы — это «исходники» для построения MV.

Для асинхронных MV в StarRocks базовыми могут быть «родные» таблицы StarRocks в default catalog, таблицы во внешних каталогах (поддержка с v2.5), а также существующие асинхронные MV (с v2.5) и представления (с v3.1). Поддерживается создание асинхронных MV на всех типах таблиц StarRocks.
Refresh

При создании асинхронного MV его данные отражают состояние базовых таблиц только на момент создания. При изменении данных в базовых таблицах MV необходимо обновлять.

Поддерживаются две общие стратегии:
- ASYNC: асинхронный режим. Обновление может запускаться автоматически при изменении данных в базовой таблице или по расписанию.
- MANUAL: ручной режим. MV не обновляется автоматически; обновления запускаются пользователем.
Query rewrite

Переписывание запроса означает, что при выполнении запроса над базовыми таблицами с построенными MV система автоматически определяет, можно ли переиспользовать предвычисленные результаты из MV. Если можно, данные читаются напрямую из соответствующего MV, избегая затратных вычислений и соединений.

Начиная с v2.5, StarRocks поддерживает автоматическое «прозрачное» переписывание запросов на основе асинхронных MV типа SPJG. Под SPJG понимаются планы, включающие только операторы Scan, Filter, Project, Aggregate.

Асинхронные MV, построенные на базовых таблицах в JDBC‑каталоге или Hudi‑каталоге, не поддерживают переписывание запросов.

Когда стоит создавать MV¶

Создавайте асинхронное MV, если в вашем DWH есть следующие потребности:

Ускорение запросов с повторяющимися агрегатами

Если большинство запросов содержат одинаковый подзапрос с агрегатной функцией и он потребляет существенную долю вычислительных ресурсов, создайте асинхронное MV на основе этого подзапроса. MV подсчитает и сохранит все результаты; затем StarRocks будет переписывать такие запросы и читать промежуточные результаты из MV, ускоряя выполнение.
Регулярные многотабличные JOIN

Если регулярно формируется «широкая» таблица через JOIN нескольких таблиц, создайте асинхронное MV для этих таблиц и задайте стратегию ASYNC с периодическим обновлением. После построения результаты запросов будут возвращаться напрямую из MV, избегая задержек из‑за JOIN.
Слоение DWH (Data Warehouse layering)

При большом объёме «сырых» данных и сложных ETL‑цепочках создайте несколько уровней асинхронных MV для стратификации: разобьёте сложный запрос на серию простых подзапросов, уменьшите повторные вычисления, упростите диагностику. Кроме того, это помогает развязать «сырые» и статистические данные, повышая безопасность.
Ускорение запросов по data lake

Из‑за сетевых задержек и пропускной способности объектного хранилища запросы к data lake могут быть медленными. Стройте асинхронные MV поверх data lake, а StarRocks сможет интеллектуально переписывать запросы под уже созданные MV — без изменения текста запросов.

См. конкретные сценарии:

Data Modeling
Query Rewrite
Data Lake Query Acceleration

Создание асинхронного MV¶

Асинхронные MV можно создавать над:

Родными таблицами StarRocks (поддерживаются все типы таблиц)
Таблицами во внешних каталогах:
- Hive Catalog
- Hudi Catalog
- Iceberg Catalog
- JDBC Catalog
- Paimon Catalog
- DeltaLake Catalog
Существующими асинхронными MV
Существующими View

Перед началом¶

Примеры ниже используют две базовые таблицы в default catalog:

goods(item_id1, item_name, price)
order_list(order_id, client_id, item_id2, order_date)

Колонка goods.item_id1 эквивалентна order_list.item_id2.

Создание и наполнение:

CREATE TABLE goods(
    item_id1          INT,
    item_name         STRING,
    price             FLOAT
) DISTRIBUTED BY HASH(item_id1);

INSERT INTO goods
VALUES
    (1001,"apple",6.5),
    (1002,"pear",8.0),
    (1003,"potato",2.2);

CREATE TABLE order_list(
    order_id          INT,
    client_id         INT,
    item_id2          INT,
    order_date        DATE
) DISTRIBUTED BY HASH(order_id);

INSERT INTO order_list
VALUES
    (10001,101,1001,"2022-03-13"),
    (10001,101,1002,"2022-03-13"),
    (10002,103,1002,"2022-03-13"),
    (10002,103,1003,"2022-03-14"),
    (10003,102,1003,"2022-03-14"),
    (10003,102,1001,"2022-03-14");

В примере требуется регулярно считать сумму по каждому заказу (частые JOIN двух таблиц и sum()), а также обновлять данные раз в сутки. Базовый запрос:

SELECT
    order_id,
    sum(goods.price) as total
FROM order_list INNER JOIN goods ON goods.item_id1 = order_list.item_id2
GROUP BY order_id;

Создание MV¶

Используйте CREATE MATERIALIZED VIEW. Пример для order_mv с ежедневным обновлением:

CREATE MATERIALIZED VIEW order_mv
DISTRIBUTED BY HASH(`order_id`)
REFRESH ASYNC START('2022-09-01 10:00:00') EVERY (interval 1 day)
AS SELECT
    order_list.order_id,
    sum(goods.price) as total
FROM order_list INNER JOIN goods ON goods.item_id1 = order_list.item_id2
GROUP BY order_id;

При создании асинхронного MV нужно указать стратегию распределения данных и/или стратегию обновления.
Разрешены собственные партиционирование/бакетирование MV, но ключи партиций/бакетов MV должны участвовать в SELECT для создания MV.
Поддерживается «более длинная» динамическая партиция: если базовая таблица — по дням, MV можно — по месяцам.
В запросе создания MV не допускаются случайные функции: rand(), random(), uuid(), sleep().
Поддерживаемые типы данных см. в CREATE MATERIALIZED VIEW - Supported data types.
По умолчанию выполнение CREATE MV сразу запускает задачу refresh; если хотите отложить обновление, используйте REFRESH DEFERRED.
MV можно создавать только в default_catalog.

О механизмах обновления

Поддерживаются два режима ON DEMAND: MANUAL и ASYNC. В v2.5 добавлены расширенные механизмы для повышения стабильности и управляемости:
- Разбиение refresh‑задач на батчи по числу партиций.
- TTL для партиций MV, чтобы снижать объём хранения.
- Ограничение области refresh — только последние N партиций.
- Исключение отдельных базовых таблиц из триггера «обновление по изменению».
- Привязка refresh‑задачи к resource group.
Подробно см. раздел PROPERTIES в CREATE MATERIALIZED VIEW - Parameters. Для изменения механики уже созданного MV используйте ALTER MATERIALIZED VIEW.

Во избежание полной перерасчётной загрузки рекомендуется строить партиционированные MV над партиционированными базовыми таблицами, чтобы при изменении данных в партиции базовой таблицы обновлялась только соответствующая партиция MV. См. Data Modeling with Materialized Views - Partitioned Modeling.
Вложенные MV

В v2.5 поддержано создание асинхронных MV на основе существующих асинхронных MV. Стратегия обновления каждого слоя независима. Жёсткого лимита глубины нет, но в проде рекомендуется не более трёх уровней.
MV на внешних каталогах

Поддерживается создание MV над Hive (с v2.5), Hudi (с v2.5), Iceberg (с v2.5), JDBC (с v3.0). Синтаксис похож на default catalog, но есть ограничения. См. Data lake query acceleration with materialized views.

Ручное обновление MV¶

Независимо от стратегии можно запускать refresh через REFRESH MATERIALIZED VIEW. В v2.5 поддержано обновление конкретных партиций; в v3.1 — синхронный вызов.

-- Асинхронно (по умолчанию)
REFRESH MATERIALIZED VIEW order_mv;
-- Синхронно
REFRESH MATERIALIZED VIEW order_mv WITH SYNC MODE;

Отменить асинхронную refresh‑задачу можно через CANCEL REFRESH MATERIALIZED VIEW.

Прямой запрос к MV¶

Созданное асинхронное MV — физическая таблица с полным набором предвычисленных результатов. Его можно запрашивать напрямую после первого успешного refresh.

SELECT * FROM order_mv;

Прямой запрос к MV может дать результат, расходящийся с актуальным результатом по базовым таблицам (зависит от «свежести» MV).

Переписывание запросов через MV¶

В v2.5 поддерживается автоматическое переписывание для SPJG‑MV: одиночные таблицы, JOIN, агрегации, UNION, вложенные MV. С v3.3.0 — также text‑based переписывание. См. Query Rewrite with Materialized Views.

Поддерживается переписывание как для MV в default catalog, так и для MV на Hive/Hudi/Iceberg. Для default catalog StarRocks обеспечивает сильную согласованность результатов: «просроченные» MV исключаются из кандидатов. Для внешних каталогов сильная согласованность не гарантируется (StarRocks не видит изменения данных извне). См. также Data lake query acceleration with materialized views.

Асинхронные MV на JDBC‑каталоге не поддерживают переписывание.

Управление MV¶

ALTER MATERIALIZED VIEW¶

Изменение свойств асинхронного MV: ALTER MATERIALIZED VIEW.

Активация неактивного MV:

ALTER MATERIALIZED VIEW order_mv ACTIVE;

Переименование MV:

ALTER MATERIALIZED VIEW order_mv RENAME order_total;

Изменение интервала обновления на 2 дня:

ALTER MATERIALIZED VIEW order_mv REFRESH ASYNC EVERY(INTERVAL 2 DAY);

Просмотр MV¶

Список MV см. через SHOW MATERIALIZED VIEWS или системные представления Information Schema.

Все MV:

SHOW MATERIALIZED VIEWS;

Конкретное MV:

SHOW MATERIALIZED VIEWS WHERE NAME = "order_mv";

По шаблону имени:

SHOW MATERIALIZED VIEWS WHERE NAME LIKE "order%";

Через представление information_schema.materialized_views:

SELECT * FROM information_schema.materialized_views;

Просмотр определения MV¶

Исходный запрос для создания MV:

SHOW CREATE MATERIALIZED VIEW order_mv;

Статус выполнения задач MV¶

Статус сборки/обновления через information_schema.tasks и information_schema.task_runs.

Найдите TASK_NAME в tasks, затем 2) посмотрите прогресс в task_runs.

Удаление MV¶

Удаление асинхронного MV: DROP MATERIALIZED VIEW:

DROP MATERIALIZED VIEW order_mv;

Важные переменные сессии¶

analyze_mv: анализировать ли MV после refresh: '' (нет), sample, full (по умолчанию sample).
enable_materialized_view_rewrite: включить автоматическое переписывание через MV (true — по умолчанию с v2.5).