Устранение неполадок асинхронных материализованных представлений¶

В этом разделе описано, как проверять состояние ваших асинхронных материализованных представлений и решать возникающие при их использовании проблемы.

Некоторые показанные ниже возможности поддерживаются только начиная с StarRocks v3.1.

Изучение асинхронного материализованного представления¶

Чтобы получить полную картину по используемым асинхронным MV, сначала проверьте их рабочее состояние, историю обновлений и потребление ресурсов.

Проверка рабочего состояния асинхронного MV¶

Проверить рабочее состояние асинхронного MV можно с помощью SHOW MATERIALIZED VIEWS. Среди возвращаемой информации обратите внимание на поля:

is_active: активно ли представление. Только активное MV может использоваться для ускорения и переписывания запросов.
last_refresh_state: состояние последнего обновления: PENDING, RUNNING, FAILED или SUCCESS.
last_refresh_error_message: причина сбоя последнего обновления (если MV не активно).
rows: количество строк в MV. Учтите, что это значение может отличаться от фактического числа строк, поскольку применение обновлений может откладываться.

Подробное описание других полей см. в SHOW MATERIALIZED VIEWS - Returns.

Пример:

MySQL > SHOW MATERIALIZED VIEWS LIKE 'mv_pred_2'\G
***************************[ 1. row ]***************************
id                                   | 112517
database_name                        | ssb_1g
name                                 | mv_pred_2
refresh_type                         | ASYNC
is_active                            | true
inactive_reason                      | <null>
partition_type                       | UNPARTITIONED
task_id                              | 457930
task_name                            | mv-112517
last_refresh_start_time              | 2023-08-04 16:46:50
last_refresh_finished_time           | 2023-08-04 16:46:54
last_refresh_duration                | 3.996
last_refresh_state                   | SUCCESS
last_refresh_force_refresh           | false
last_refresh_start_partition         |
last_refresh_end_partition           |
last_refresh_base_refresh_partitions | {}
last_refresh_mv_refresh_partitions   |
last_refresh_error_code              | 0
last_refresh_error_message           |
rows                                 | 0
text                                 | CREATE MATERIALIZED VIEW `mv_pred_2` (`lo_quantity`, `lo_revenue`, `sum`)
DISTRIBUTED BY HASH(`lo_quantity`, `lo_revenue`) BUCKETS 2
REFRESH ASYNC
PROPERTIES (
"replication_num" = "3",
"storage_medium" = "HDD"
)
AS SELECT `lineorder`.`lo_quantity`, `lineorder`.`lo_revenue`, sum(`lineorder`.`lo_tax`) AS `sum`
FROM `ssb_1g`.`lineorder`
WHERE `lineorder`.`lo_linenumber` = 1
GROUP BY 1, 2;

1 row in set
Time: 0.003s

Просмотр истории обновлений асинхронного MV¶

Историю обновлений асинхронного MV можно просмотреть, запросив таблицу task_runs в базе information_schema. Среди возвращаемой информации обратите внимание на поля:

CREATE_TIME и FINISH_TIME: время начала и окончания задачи обновления.
STATE: состояние задачи обновления: PENDING, RUNNING, FAILED или SUCCESS.
ERROR_MESSAGE: причина сбоя задачи обновления.

Пример:

MySQL > SELECT * FROM information_schema.task_runs WHERE task_name ='mv-112517' \G
***************************[ 1. row ]***************************
QUERY_ID      | 7434cee5-32a3-11ee-b73a-8e20563011de
TASK_NAME     | mv-112517
CREATE_TIME   | 2023-08-04 16:46:50
FINISH_TIME   | 2023-08-04 16:46:54
STATE         | SUCCESS
DATABASE      | ssb_1g
EXPIRE_TIME   | 2023-08-05 16:46:50
ERROR_CODE    | 0
ERROR_MESSAGE | <null>
PROGRESS      | 100%
EXTRA_MESSAGE | {"forceRefresh":false,"mvPartitionsToRefresh":[],"refBasePartitionsToRefreshMap":{},"basePartitionsToRefreshMap":{}}
PROPERTIES    | {"FORCE":"false"}
***************************[ 2. row ]***************************
QUERY_ID      | 72dd2f16-32a3-11ee-b73a-8e20563011de
TASK_NAME     | mv-112517
CREATE_TIME   | 2023-08-04 16:46:48
FINISH_TIME   | 2023-08-04 16:46:53
STATE         | SUCCESS
DATABASE      | ssb_1g
EXPIRE_TIME   | 2023-08-05 16:46:48
ERROR_CODE    | 0
ERROR_MESSAGE | <null>
PROGRESS      | 100%
EXTRA_MESSAGE | {"forceRefresh":true,"mvPartitionsToRefresh":["mv_pred_2"],"refBasePartitionsToRefreshMap":{},"basePartitionsToRefreshMap":{"lineorder":["lineorder"]}}
PROPERTIES    | {"FORCE":"true"}

Мониторинг потребления ресурсов асинхронным MV¶

Вы можете контролировать и анализировать ресурсы, потребляемые асинхронным MV во время и после обновления.

Мониторинг ресурсов во время обновления¶

Во время выполнения задачи обновления вы можете отслеживать текущее потребление ресурсов с помощью SHOW PROC „/current_queries“.

Среди возвращаемой информации обратите внимание на поля:

ScanBytes: объем просканированных данных.
ScanRows: количество просканированных строк.
MemoryUsage: объем используемой памяти.
CPUTime: затраты CPU.
ExecTime: время выполнения запроса.

Пример:

MySQL > SHOW PROC '/current_queries'\G
***************************[ 1. row ]***************************
StartTime     | 2023-08-04 17:01:30
QueryId       | 806eed7d-32a5-11ee-b73a-8e20563011de
ConnectionId  | 0
Database      | ssb_1g
User          | root
ScanBytes     | 70.981 MB
ScanRows      | 6001215 rows
MemoryUsage   | 73.748 MB
DiskSpillSize | 0.000
CPUTime       | 2.515 s
ExecTime      | 2.583 s

Анализ ресурсов после обновления¶

После завершения задачи обновления вы можете проанализировать потребление ресурсов по профилю запроса. Профиль задачи обновления MV доступен через Web UI узла Leader FE кластера.

Во время обновления асинхронного MV выполняется оператор INSERT OVERWRITE. Изучите соответствующий профиль запроса, чтобы проанализировать время и ресурсы, потраченные задачей обновления.

Среди метрик обратите внимание на:

Total: суммарное время выполнения запроса.
QueryCpuCost: суммарные затраты CPU по запросу. Время CPU агрегируется по параллельным процессам, поэтому значение может превышать фактическое время выполнения запроса.
QueryMemCost: суммарные затраты памяти по запросу.
Прочие метрики по отдельным операторам, например по операторам соединений и агрегаций.

Подробности о проверке профиля и других метриках см. в Analyze query profile.

Проверка, переписываются ли запросы асинхронным MV¶

Понять, может ли запрос быть переписан с использованием асинхронного MV, можно по его плану запроса с помощью EXPLAIN.

Если метрика SCAN в плане запроса показывает имя соответствующего MV, значит запрос переписан с использованием этого MV.

Пример 1:

MySQL > SHOW CREATE TABLE mv_agg\G
***************************[ 1. row ]***************************
Materialized View        | mv_agg
Create Materialized View | CREATE MATERIALIZED VIEW `mv_agg` (`c_custkey`)
DISTRIBUTED BY RANDOM
REFRESH ASYNC
PROPERTIES (
"replication_num" = "3",
"replicated_storage" = "true",
"storage_medium" = "HDD"
)
AS SELECT `customer`.`c_custkey`
FROM `ssb_1g`.`customer`
GROUP BY `customer`.`c_custkey`;

MySQL > EXPLAIN LOGICAL SELECT `customer`.`c_custkey`
                      -> FROM `ssb_1g`.`customer`
                      -> GROUP BY `customer`.`c_custkey`;
+-----------------------------------------------------------------------------------+
| Explain String                                                                    |
+-----------------------------------------------------------------------------------+
| - Output => [1:c_custkey]                                                         |
|     - SCAN [mv_agg] => [1:c_custkey]                                              |
|             Estimates: {row: 30000, cpu: ?, memory: ?, network: ?, cost: 15000.0} |
|             partitionRatio: 1/1, tabletRatio: 12/12                               |
|             1:c_custkey := 10:c_custkey                                           |
+-----------------------------------------------------------------------------------+

Если отключить переписывание запросов, StarRocks применит обычный план.

Пример 2:

MySQL > SET enable_materialized_view_rewrite = false;
MySQL > EXPLAIN LOGICAL SELECT `customer`.`c_custkey`
                      -> FROM `ssb_1g`.`customer`
                      -> GROUP BY `customer`.`c_custkey`;
+---------------------------------------------------------------------------------------+
| Explain String                                                                        |
+---------------------------------------------------------------------------------------+
| - Output => [1:c_custkey]                                                             |
|     - AGGREGATE(GLOBAL) [1:c_custkey]                                                 |
|             Estimates: {row: 15000, cpu: ?, memory: ?, network: ?, cost: 120000.0}    |
|         - SCAN [mv_bitmap] => [1:c_custkey]                                           |
|                 Estimates: {row: 60000, cpu: ?, memory: ?, network: ?, cost: 30000.0} |
|                 partitionRatio: 1/1, tabletRatio: 12/12                               |
+---------------------------------------------------------------------------------------+

Диагностика и решение проблем¶

Ниже перечислены типичные проблемы, с которыми вы можете столкнуться при работе с асинхронными MV, и способы их решения.

Сбой построения MV¶

Если не удается создать асинхронное MV, то есть оператор CREATE MATERIALIZED VIEW не выполняется, проверьте следующее:

Проверьте, не используете ли вы по ошибке SQL-оператор для синхронных MV.

StarRocks предлагает два типа MV: синхронные и асинхронные.

Базовый SQL для создания синхронного MV выглядит так:
```
CREATE MATERIALIZED VIEW <mv_name> 
AS <query>
```
А для асинхронного MV оператор содержит дополнительные параметры:
```
CREATE MATERIALIZED VIEW <mv_name> 
REFRESH ASYNC -- стратегия обновления асинхронного MV.
DISTRIBUTED BY HASH(<column>) -- стратегия распределения данных асинхронного MV.
AS <query>
```
Кроме различий в синтаксисе, ключевое отличие: асинхронные MV поддерживают весь синтаксис запросов StarRocks, тогда как синхронные MV поддерживают ограниченный набор агрегатных функций.
Проверьте, правильно ли указан столбец партиционирования.

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

В настоящее время StarRocks поддерживает только RANGE‑партиционирование и только ссылку на один столбец из выражения SELECT в запросе, по которому строится MV. Можно применять функцию date_trunc() для усечения столбца и изменения гранулярности партиционирования. Другие выражения не поддерживаются.
Проверьте, есть ли у вас необходимые привилегии для создания MV.

Для создания асинхронного MV требуются права SELECT на все объекты (таблицы, представления, MV), задействованные в запросе. Если в запросе используются UDF, также нужны права USAGE на функции.

Сбой обновления MV¶

Если MV не удается обновить, то есть состояние задачи обновления не SUCCESS, проверьте следующее:

Проверьте корректность выбранной стратегии обновления.

По умолчанию MV обновляется сразу после создания. Однако в v2.5 и более ранних версиях MV со стратегией MANUAL не обновляется после создания — необходимо выполнить ручное обновление с помощью REFRESH MATERIALIZED VIEW.
Проверьте, не превышен ли лимит памяти задачей обновления.

Как правило, это происходит, если асинхронное MV включает масштабные агрегации или JOIN, которые исчерпывают память. Возможные решения:
- Задайте партиционирование MV, чтобы обновлять по одной партиции за раз.
- Включите функцию Spill to Disk для задачи обновления. Начиная с v3.1, StarRocks поддерживает сброс промежуточных результатов на диск при обновлении MV. Включить Spill to Disk можно так:
```
-- Задать свойства при создании MV.
CREATE MATERIALIZED VIEW mv1 
REFRESH ASYNC
PROPERTIES ( 'session.enable_spill'='true' )
AS <query>;

-- Добавить свойства к существующему MV.
ALTER MATERIALIZED VIEW mv2 SET ('session.enable_spill' = 'true');
```

Тайм‑аут обновления MV¶

Крупные MV могут не обновиться из‑за превышения тайм‑аута. Рассмотрите следующие решения:

Задайте партиционирование MV для тонкозернистого обновления

Как описано в Create partitioned materialized views, за счет партиционирования можно выполнять инкрементальное построение и обновление, избегая чрезмерного расхода ресурсов при первоначальном обновлении.
Установите более продолжительный тайм‑аут

Значение тайм‑аута по умолчанию для задач обновления MV — 5 минут в версиях до v3.2 и 1 час в v3.2 и новее. При ошибках тайм‑аута увеличьте период с помощью:
```
ALTER MATERIALIZED VIEW mv2 SET ('session.insert_timeout' = '4000');
```
Проанализируйте узкие места производительности обновления MV

Обновление MV со сложными вычислениями занимает много времени. Проанализируйте его узкие места по профилю задачи обновления:
- Получите query_id, соответствующий задаче обновления, запросив information_schema.task_runs.
- Проанализируйте профиль задачи обновления, используя:
  - GET_QUERY_PROFILE: извлечь исходный профиль по query_id.
  - ANALYZE PROFILE: проанализировать профиль по фрагментам и отобразить в древовидной структуре.

Состояние MV не активно¶

Если MV не может переписывать запросы или обновляться, и is_active равно false, вероятно, это вызвано изменением схемы базовых таблиц. Установите активное состояние вручную:

ALTER MATERIALIZED VIEW mv1 ACTIVE;

Если это не помогло, удалите MV и создайте его заново.

Задача обновления MV потребляет слишком много ресурсов¶

Если задачи обновления избыточно потребляют ресурсы системы, проверьте следующее:

Не слишком ли велико само MV.

Если в MV объединено слишком много таблиц, что ведет к значительным вычислениям, задача обновления займет много ресурсов. Оцените размер MV и перепланируйте его.
Не слишком ли часто настроен интервал обновления.

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

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

Чтобы остановить «тяжелую» задачу обновления, можно:

Перевести MV в неактивное состояние, чтобы остановить все его задачи обновления:
```
ALTER MATERIALIZED VIEW mv1 INACTIVE;
```
Прервать выполняющуюся задачу обновления с помощью CANCEL REFRESH MATERIALIZED VIEW:
```
CANCEL REFRESH MATERIALIZED VIEW mv1;
```

Сбой переписывания запросов с использованием MV¶

Если MV не переписывает соответствующие запросы, проверьте следующее:

Диагностика сбоя переписывания с помощью TRACE

StarRocks предоставляет оператор TRACE для диагностики проблем переписывания:

TRACE LOGS MV <query>: доступно в v3.2 и новее; анализирует детальный процесс переписывания и причины сбоя.
TRACE REASON MV <query>: доступно в v3.2.8 и новее; выдает краткие причины сбоя переписывания.

MySQL > TRACE REASON MV SELECT sum(c1) FROM `glue_ice`.`iceberg_test`.`ice_test3`;
+----------------------------------------------------------------------------------------------------------------------+
| Explain String                                                                                                       |
+----------------------------------------------------------------------------------------------------------------------+
|     MV rewrite fail for mv1: Rewrite aggregate rollup sum(1: c1) failed: only column-ref is supported after rewrite  |
|     MV rewrite fail for mv1: Rewrite aggregate function failed, cannot get rollup function: sum(1: c1)               |
|     MV rewrite fail for mv1: Rewrite rollup aggregate failed: cannot rewrite aggregate functions                     |
+----------------------------------------------------------------------------------------------------------------------+

Проверьте соответствие структуры MV и запроса.
- StarRocks сопоставляет MV и запрос на основе структурного соответствия, а не текстового. Поэтому схожесть текста запроса с определением MV не гарантирует возможность переписывания.
- MV могут переписывать только запросы класса SPJG (Select/Projection/Join/Aggregation). Запросы с оконными функциями, вложенными агрегациями или «join плюс aggregation» не поддерживаются.
- MV не могут переписывать запросы с комплексными предикатами соединений в Outer Join. Например, в случае A LEFT JOIN B ON A.dt > '2023-01-01' AND A.id = B.id рекомендуется вынести предикат из JOIN ON в WHERE.
Подробнее об ограничениях см. Query rewrite with materialized views - Limitations.
Проверьте, что состояние MV активно.

Перед переписыванием запросов StarRocks проверяет статус MV. Переписывание возможно только для активного MV. Установите активное состояние вручную:
```
ALTER MATERIALIZED VIEW mv1 ACTIVE;
```
Проверьте соответствие требованиям согласованности данных.

StarRocks проверяет согласованность данных в MV и базовых таблицах. По умолчанию переписывание выполняется только при актуальности данных MV. Возможные варианты:
- Добавьте PROPERTIES('query_rewrite_consistency'='LOOSE') к MV, чтобы отключить проверку согласованности.
- Добавьте PROPERTIES('mv_rewrite_staleness_second'='5'), чтобы допустить некоторую устарелость данных. Тогда запросы могут переписываться, если последнее обновление было ранее указанного интервала, независимо от изменений в базовых таблицах.
Проверьте, не отсутствуют ли в запросе MV выходные столбцы.

Для переписывания range/point‑запросов необходимо указывать в выражении SELECT запроса MV те столбцы, которые используются как фильтры. Убедитесь, что SELECT MV включает столбцы, на которые ссылаются в WHERE и ORDER BY запроса.

Пример 1: MV mv1 использует вложенную агрегацию и не может применяться для переписывания.

CREATE MATERIALIZED VIEW mv1 REFRESH ASYNC AS
select count(distinct cnt) 
from (
    select c_city, count(*) cnt 
    from customer 
    group by c_city
) t;

Пример 2: MV mv2 использует «join плюс aggregation» и не может применяться для переписывания. Решение: создайте MV с агрегацией, а затем вложенное MV c join на его основе.

CREATE MATERIALIZED VIEW mv2 REFRESH ASYNC AS
select *
from (
    select lo_orderkey, lo_custkey, p_partkey, p_name
    from lineorder
    join part on lo_partkey = p_partkey
) lo
join (
    select c_custkey
    from customer
    group by c_custkey
) cust
on lo.lo_custkey = cust.c_custkey;

Пример 3: MV mv3 не может переписать запросы вида SELECT c_city, sum(tax) FROM tbl WHERE dt='2023-01-01' AND c_city = 'xxx', потому что столбец из предиката отсутствует в выражении SELECT.

CREATE MATERIALIZED VIEW mv3 REFRESH ASYNC AS
SELECT c_city, sum(tax) FROM tbl GROUP BY c_city;

Решение:

CREATE MATERIALIZED VIEW mv3 REFRESH ASYNC AS
SELECT dt, c_city, sum(tax) FROM tbl GROUP BY dt, c_city;

FAQ¶

Какой ресурсной группой управляются ресурсы для асинхронных MV? Как изменить ее конфигурацию?¶

Если свойство resource_group не указано при создании асинхронного MV, система назначает его в группу по умолчанию default_mv_wg. Ее конфигурация по умолчанию:

cpu_core_limit: 1
mem_limit: 80%
concurrency_limit: 0
spill_mem_limit_threshold: 80%

Изменить лимиты CPU, памяти, конкуренции и порог spill можно через следующие параметры BE:

default_mv_resource_group_cpu_limit
default_mv_resource_group_memory_limit
default_mv_resource_group_concurrency_limit
default_mv_resource_group_spill_mem_limit_threshold

Также вы можете назначить выделенную ресурсную группу, указав свойство resource_group.

Пример:

CREATE MATERIALIZED VIEW IF NOT EXISTS mv_test.test_1
PARTITION BY `metric_date`
REFRESH MANUAL
PROPERTIES (
  "replicated_storage" = "true",
  "partition_refresh_number" = "1",
  "force_external_table_query_rewrite" = "CHECKED",
  "query_rewrite_consistency" = "LOOSE",
  "replication_num" = "1",
  "storage_medium" = "HDD",
  # highlight-start
  "resource_group" = "rg_mv"
  # highlight-end
) AS ...

Если обновление асинхронного MV запланировано каждые 1 минуту, что произойдет, если обновление длится дольше минуты?¶

Система обрабатывает это автоматически:

Если в очереди есть ожидающие задачи, новый триггер объединяется с ними (статус MERGED).
Если ожидающих задач нет (только выполняющиеся или завершенные), новый триггер ждет окончания текущей задачи и затем выполняется.

Ограничение: одновременно может выполняться только одна задача обновления на одно MV.

После установки auto_refresh_partitions_limit система всегда обновляет ровно столько партиций?¶

Нет. Это верхний предел. Если система определит, что изменилось меньше партиций базовых таблиц, будут обновлены только они.

MV настроено на обновление каждые 5 минут, но в `information_schema.task_runs` видно обновления каждые 5 секунд. Почему?¶

Начиная с v3.3, значение по умолчанию partition_refresh_number изменено с -1 на 1, то есть каждая операция обновления обрабатывает только одну партицию. Если необходимо обновить много партиций, система разбивает работу на несколько подзадач, что приводит к более частым записям в task_runs, чем заданный пользователем интервал обновления.

Можно ли вкладывать несколько асинхронных MV? Рекомендации?¶

Вложенность поддерживается, но рекомендуется минимизировать глубину. Чрезмерная вложенность значительно усложняет диагностику.

Устранение неполадок асинхронных материализованных представлений¶

Изучение асинхронного материализованного представления¶

Проверка рабочего состояния асинхронного MV¶

Просмотр истории обновлений асинхронного MV¶

Мониторинг потребления ресурсов асинхронным MV¶

Мониторинг ресурсов во время обновления¶

Анализ ресурсов после обновления¶

Проверка, переписываются ли запросы асинхронным MV¶

Диагностика и решение проблем¶

Сбой построения MV¶

Сбой обновления MV¶

Тайм‑аут обновления MV¶

Состояние MV не активно¶

Задача обновления MV потребляет слишком много ресурсов¶

Сбой переписывания запросов с использованием MV¶

FAQ¶

Какой ресурсной группой управляются ресурсы для асинхронных MV? Как изменить ее конфигурацию?¶

Если обновление асинхронного MV запланировано каждые 1 минуту, что произойдет, если обновление длится дольше минуты?¶

После установки auto_refresh_partitions_limit система всегда обновляет ровно столько партиций?¶

MV настроено на обновление каждые 5 минут, но в information_schema.task_runs видно обновления каждые 5 секунд. Почему?¶

Можно ли вкладывать несколько асинхронных MV? Рекомендации?¶

MV настроено на обновление каждые 5 минут, но в `information_schema.task_runs` видно обновления каждые 5 секунд. Почему?¶