.create materialized-view

Статья
10/15/2024

Область применения: ✅Microsoft Fabric ✅Azure Data Explorer

Материализованное представление — это агрегирование запроса по исходной таблице. Он представляет одну summarize инструкцию.

Существует два возможных способа создания материализованного представления, как отмечается параметром обратной заполнения в команде:

Теперь создайте материализованное представление:

Материализованное представление создается пустым. Он включает только записи, которые будут приема после создания представления. Создание такого вида возвращается немедленно, и представление сразу же доступно для запроса.

Создайте материализованное представление на основе существующих записей в исходной таблице:

См . раздел "Обратная заполнение материализованного представления".
Создание может занять много времени в зависимости от количества записей в исходной таблице. Представление не будет доступно для запросов, пока не завершится заполнение.
При использовании этого параметра команда создания должна быть async. Вы можете отслеживать выполнение с помощью .show operations команды.
Вы можете отменить процесс обратной заполнения с помощью .cancel operation команды.

Внимание

В больших исходных таблицах для завершения резервной заполнения может потребоваться много времени. Если этот процесс временно завершается сбоем во время выполнения, он не будет автоматически извлечен. Затем необходимо повторно выполнить команду создания. Дополнительные сведения см. в разделе "Обратная заполнение материализованного представления".

Разрешения

Для этой команды требуются разрешения администратора базы данных. Создатель материализованного представления становится администратором.

Синтаксис

.create[] [asyncifnotexists] materialized-view [ with(PropertyName = PropertyValue,...] )Запрос SourceTableName MaterializedViewName on table { }

Дополнительные сведения о соглашениях синтаксиса.

Параметры

Имя (название)	Type	Обязательно	Описание
PropertyName, PropertyValue	`string`		Список свойств в виде пар имен и значений из списка поддерживаемых свойств.
MaterializedViewName	`string`	✔️	Имя материализованного представления. Имя представления не может конфликтовать с именами таблиц или функций в той же базе данных и должно соответствовать правилам именования идентификаторов.
SourceTableName	`string`	✔️	Имя исходной таблицы, для которой определено представление.
Запрос	`string`	✔️	Определение запроса материализованного представления. Дополнительные сведения и ограничения см. в разделе параметров запроса.

Примечание.

Если материализованное представление уже существует:

ifnotexists Если указан флаг, команда игнорируется. Никаких изменений не применяется, даже если новое определение не соответствует существующему определению.
ifnotexists Если флаг не указан, возвращается ошибка.
Чтобы изменить существующее материализованное представление, используйте команду alter materialized-view .

Поддерживаемые свойства

Следующие свойства поддерживаются в предложении with(PropertyName = PropertyValue). Все свойства являются необязательными.

Имя.	Тип	Описание
Обратной засыпки	`bool`	Следует ли создавать представление на основе всех записей, которые в данный момент находятся в `SourceTable` (`true`) или создавать его с этого момента (`false`). По умолчанию — `false`. Дополнительные сведения см. в разделе "Обратная заполнение материализованного представления".
effectiveDateTime	`datetime`	Релевантные только при использовании `backfill`. Если задано, создание резервных заполнений только записей, которые будут приемлены после даты и времени. `backfill` также должно быть задано значение `true`. Это свойство ожидает литерал datetime; например, `effectiveDateTime=datetime(2019-05-01)`.
updateExtentsCreationTime	`bool`	Релевантные только при использовании `backfill`. Если задано значение `true`, время создания экстентов назначается на основе ключа datetime group-by во время процесса обратной заполнения. Дополнительные сведения см. в разделе "Обратная заполнение материализованного представления".
обратная обратная связь	`timespan`	Допустимо только для `arg_max`//`arg_mintake_any` материализованных представлений. Он ограничивает период времени, в течение которого ожидаются дубликаты. Например, если в представлении указан `arg_max` обратный просмотр 6 часов, дедупликация между недавно приемными записями и существующими будут принимать во внимание только записи, которые были приема до 6 часов назад. Lookback относится к ingestion_time(). Если материализованный запрос представления не сохраняет `ingestion_time()` значение, обратный просмотр не может быть определен в представлении. См . материализованные ограничения представлений и известные проблемы. Неправильное определение периода обратного просмотра может привести к дубликатам в материализованном представлении. Например, если запись для определенного ключа будет приемлена через 10 часов после приема записи для того же ключа, а обратный просмотр имеет значение 6 часов, этот ключ будет дублироваться в представлении. Период обратного просмотра применяется как во время материализации, так и во время запроса.
autoUpdateSchema	`bool`	Следует ли автоматически обновлять представление в исходной таблице. По умолчанию — `false`. Этот параметр действителен только для представлений типа `arg_max(Timestamp, )`//`arg_min(Timestamp, )take_any()` (только если аргумент столбца равен).`` Если этот параметр задан `true`, изменения исходной таблицы будут автоматически отражены в материализованном представлении.
dimensionTables	array	Динамический аргумент, содержащий массив таблиц измерений в представлении. См . параметр запроса.
папку	`string`	Папка материализованного представления.
docString	`string`	Строка, которая документирует материализованное представление.
allowMaterializedViewsWithoutRowLevelSecurity	`bool`	Позволяет создавать материализованное представление по таблице с включенной политикой безопасности на уровне строк.

Предупреждение

Система автоматически отключит материализованное представление, если изменения исходной таблицы материализованного представления или изменения данных приводят к несовместимости между материализованным запросом представления и ожидаемой схемой материализованного представления.
Чтобы избежать этой ошибки, материализованный запрос представления должен быть детерминированным. Например, подключаемый модуль bag_unpack или сводной таблицы приводит к недетерминированной схеме.
При использовании агрегата и при autoUpdateSchema значении false изменения исходной arg_max(Timestamp, *) таблицы также могут привести к несоответствиям схемы. Избегайте этого сбоя, определяя запрос представления как arg_max(Timestamp, Column1, Column2, ...)или используя autoUpdateSchema этот параметр.
Использование autoUpdateSchema может привести к необратимой потере данных при удалении столбцов в исходной таблице.
Отслеживайте автоматическое отключение материализованных представлений с помощью метрики MaterializedViewResult.
После устранения проблем несовместимости необходимо явно включить представление с помощью команды включения материализованного представления .

Создание материализованного представления по материализованному представлению

Можно создать материализованное представление для другого материализованного представления только в том случае, если исходное материализованное представление является take_any(*) агрегированием (дедупликация). Дополнительные сведения см. в разделе Материализованное представление по материализованному представлению и примерам.

Синтаксис

.create[] [asyncifnotexists] materialized-view [ with(PropertyName = PropertyValue,...] )Запрос MaterializedViewName on materialized-view Source MaterializedViewName { }

Параметры:

Имя.	Type	Обязательно	Описание
PropertyName, PropertyValue	`string`		Список свойств в виде пар имен и значений из списка поддерживаемых свойств.
MaterializedViewName	`string`	✔️	Имя материализованного представления. Имя представления не может конфликтовать с именами таблиц или функций в той же базе данных и должно соответствовать правилам именования идентификаторов.
SourceMaterializedViewName	`string`	✔️	Имя исходного материализованного представления, для которого определено представление.
Запрос	`string`	✔️	Определение запроса материализованного представления.

Примеры

Создайте пустое arg_max представление, которое будет материализовать только записи, полученные с этого момента:
```
.create materialized-view ArgMax on table T
{
    T | summarize arg_max(Timestamp, *) by User
}
```

Создайте материализованное представление для ежедневных агрегатов с параметром обратной заполнения с помощью async:

.create async materialized-view with (backfill=true, docString="Customer telemetry") CustomerUsage on table T
{
    T 
    | extend Day = bin(Timestamp, 1d)
    | summarize count(), dcount(User), max(Duration) by Customer, Day 
}

Создание материализованного представления с помощью backfill и effectiveDateTime. Представление создается на основе записей только из даты и времени.
```
.create async materialized-view with (backfill=true, effectiveDateTime=datetime(2019-01-01)) CustomerUsage on table T 
{
    T 
    | extend Day = bin(Timestamp, 1d)
    | summarize count(), dcount(User), max(Duration) by Customer, Day
} 
```
Создайте материализованное представление, которое дедупликирует исходную таблицу на основе EventId столбца с помощью обратного просмотра 6 часов. Записи будут дедупликированы только в течение 6 часов до текущих записей.
```
.create materialized-view with(lookback=6h) DeduplicatedTable on table T
{
    T
    | summarize take_any(*) by EventId
}
```
Создайте материализованное представление вниз, основанное на предыдущем DeduplicatedTable материализованном представлении:
```
.create materialized-view DailyUsage on materialized-view DeduplicatedTable
{
    DeduplicatedTable
    | summarize count(), dcount(User) by Day=bin(Timestamp, 1d)
}
```

Определение может включать дополнительные операторы перед summarize оператором до тех пор, пока summarize это последний:

.create materialized-view CustomerUsage on table T 
{
    T 
    | where Customer in ("Customer1", "Customer2", "CustomerN")
    | parse Url with "https://contoso.com/" Api "/" *
    | extend Month = startofmonth(Timestamp)
    | summarize count(), dcount(User), max(Duration) by Customer, Api, Month
}

Ниже приведены материализованные представления, которые объединяются с таблицей измерений:

.create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T
{
    T
    | lookup DimUsers on User  
    | summarize arg_max(Timestamp, *) by User 
}

.create materialized-view with (dimensionTables = dynamic(["DimUsers"])) EnrichedArgMax on table T 
{
    DimUsers | project User, Age, Address
    | join kind=rightouter hint.strategy=broadcast T on User
    | summarize arg_max(Timestamp, *) by User 
}

Замечания

Параметр запроса

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

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

Материализованное представление, включающее только один arg_max//arg_mintake_any агрегат, может выполняться лучше, чем материализованное представление, которое включает эти агрегаты вместе с другими агрегатами (напримерavgcount/dcount/, ). Это связано с тем, что некоторые оптимизации относятся только к этим типам материализованных представлений. Они не применяются, если представление включает смешанные функции агрегирования (где смешанные средства оба иtake_any arg_max/arg_min/другие агрегаты в одном представлении).
Запрос не должен включать операторы, зависящие от now(). Например, запрос не должен иметь where Timestamp > ago(5d). Используйте политику хранения в материализованном представлении, чтобы ограничить период времени, охватываемого представлением.
Следующие операторы не поддерживаются в материализованном запросе представления: sort, top-nested, , toppartition. serialize
Составные агрегаты не поддерживаются в определении материализованного представления. Например, вместо использования SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Idопределите материализованное представление следующим образом: SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id Во время выполнения запроса выполните команду MaterializedViewName | project Id, Result=a/b. Требуемые выходные данные представления, включая вычисляемый столбец (a/b), можно инкапсулировать в хранимой функции. Доступ к хранимой функции вместо прямого доступа к материализованному представлению.

Запросы между кластерами и между базами данных не поддерживаются.

Межбазовые и межбазовые запросы не поддерживаются.

Ссылки на external_table() и externaldata не поддерживаются.
Материализованный запрос представления не может содержать выноски, требующие олицетворения. В частности, все подключаемые модули подключения к запросу, использующие олицетворение, не допускаются.
В дополнение к исходной таблице представления запрос может ссылаться на одну или несколько таблиц измерений. Таблицы измерений должны быть явно вызваны в свойствах представления. Важно понимать следующее поведение при присоединении к таблицам измерений:
- Записи в исходной таблице представления (таблица фактов) материализуются только один раз. Обновления таблиц измерений не влияют на записи, которые уже обработаны из таблицы фактов.
- Другая задержка приема данных между таблицей фактов и таблицей измерений может повлиять на результаты представления.
  
  Пример. Определение представления включает внутреннее соединение с таблицей измерений. В момент материализации запись измерения не была полностью приемна, но она уже была приемлена в таблицу фактов. Эта запись будет удалена из представления и никогда не обрабатывается снова.
  
  Аналогичным образом, если соединение является внешним соединением, запись из таблицы фактов будет обработана и добавлена для просмотра со значением NULL для столбцов таблицы измерений. Записи, которые уже были добавлены (с пустыми значениями) в представление не будут обрабатываться снова. Их значения в столбцах из таблицы измерений останутся null.

Поддерживаемые функции агрегирования

Поддерживаются следующие функции агрегирования:

Советы по производительности

Используйте ключ группы даты и времени: материализованные представления, имеющие столбец datetime в качестве одного из ключей группы, эффективнее, чем те, которые этого не делают. Причина заключается в том, что некоторые оптимизации могут применяться только при наличии ключа datetime group-by. Если добавление ключа для группы даты и времени не изменяет семантику агрегирования, рекомендуется добавить ее. Это можно сделать, только если столбец datetime неизменяем для каждой уникальной сущности.

Например, в следующей агрегации:
```
    SourceTable | summarize take_any(*) by EventId
```
Если EventId всегда имеет одно и то же Timestamp значение, поэтому добавление Timestamp не изменяет семантику агрегирования, лучше определить представление следующим образом:
```
    SourceTable | summarize take_any(*) by EventId, Timestamp
```
Совет

Последние поступающие данные в ключе datetime могут негативно повлиять на производительность материализованного представления. Например, предположим, что материализованное представление используется bin(Timestamp, 1d) в качестве одного из ключей группы по группам, а недавно принятые записи в исходную таблицу имеют старые Timestamp значения. Эти записи могут негативно повлиять на материализованное представление.

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

Если такие поздние записи не ожидаются, рекомендуется отфильтровать эти записи или нормализовать значения меток времени до текущего времени.
Определите период обратного просмотра: если применимо к вашему сценарию, добавление lookback свойства может значительно повысить производительность запросов. Дополнительные сведения см. в разделе "Поддерживаемые свойства".
Добавление столбцов, часто используемых для фильтрации в виде ключей групп по группам: запросы материализованного представления оптимизированы при фильтрации по одному из материализованных ключей представления. Если вы знаете, что шаблон запроса часто фильтруется по столбцу, неизменяемому в соответствии с уникальной сущностью в материализованном представлении, включите его в материализованные ключи представления по группам.

Например, материализованное представление предоставляется arg_max по ResourceId значению, которое часто фильтруется по SubscriptionId. Предположим, что ResourceId значение всегда принадлежит тому же SubscriptionId значению, определите материализованный запрос представления следующим образом:
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
}
```
Предыдущее определение предпочтительнее следующего:
```
.create materialized-view ArgMaxResourceId on table FactResources
{
    FactResources | summarize arg_max(Timestamp, *) by ResourceId 
}
```
Используйте политики обновления, где это необходимо: материализованное представление может включать преобразования, нормализации и подстановки в таблицах измерений. Однако рекомендуется переместить эти операции в политику обновления. Оставьте только агрегирование для материализованного представления.

Например, лучше определить следующую политику обновления:
```
.alter-merge table Target policy update 
@'[{"IsEnabled": true, 
    "Source": "SourceTable", 
    "Query": 
        "SourceTable 
        | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)", 
        | lookup DimResources on ResourceId
        | mv-expand Events
    "IsTransactional": false}]'  
```
И определите следующее материализованное представление:
```
.create materialized-view Usage on table Events
{
    Target 
    | summarize count() by ResourceId 
}
```
Альтернатива, включая политику обновления в рамках материализованного запроса представления, может оказаться хуже и поэтому не рекомендуется:
```
.create materialized-view Usage on table SourceTable
{
    SourceTable
    | extend ResourceId = strcat('subscriptions/', toupper(SubscriptionId), '/', resourceId)
    | lookup DimResources on ResourceId
    | mv-expand Events
    | summarize count() by ResourceId
}
```

Совет

Если требуется оптимальная производительность времени запроса, но вы можете терпеть некоторую задержку данных, используйте функцию materialized_view().

Заполнение материализованного представления

При создании материализованного представления с помощью backfill свойства материализованное представление будет создано на основе записей, доступных в исходной таблице. Или он будет создан на основе подмножества этих записей, если вы используете effectiveDateTime.

За кулисами процесс обратной заполнения разбивает данные для обратной заполнения на несколько пакетов и выполняет несколько операций приема для резервного заполнения представления. Процесс может занять некоторое время, когда количество записей в исходной таблице большое. Длительность процесса зависит от размера базы данных. Отслеживайте ход выполнения резервной заполнения с помощью .show operations команды.

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

Мы не рекомендуем использовать обратную заполнение при превышении number-of-nodes X 200 million количества записей в исходной таблице (иногда даже меньше в зависимости от сложности запроса). Альтернативным вариантом является обратная заполнение путем перемещения экстентов .

Использование параметра обратной заполнения не поддерживается для данных в холодном кэше. При необходимости увеличьте период горячего кэша в течение периода создания представления. Для этого может потребоваться горизонтальное масштабирование.

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

MaxSourceRecordsForSingleIngest: по умолчанию количество исходных записей в каждой операции приема во время резервной заполнения составляет 2 миллиона на узел. Вы можете изменить это значение по умолчанию, задав это свойство требуемому количеству записей. (Значение — общее количество записей в каждой операции приема.)

Уменьшение этого значения может оказаться полезным при сбое при создании ограничений памяти или времени ожидания запросов. Увеличение этого значения может ускорить создание представления, если база данных может выполнить функцию агрегирования для большей записи, чем по умолчанию.
Concurrency: операции приема, выполняемые в процессе обратной заполнения, выполняются одновременно. По умолчанию параллелизм имеет значение min(number_of_nodes * 2, 5). Это свойство можно задать для увеличения или уменьшения параллелизма. Мы рекомендуем увеличить это значение только в том случае, если ЦП ЦП databse низкая, так как увеличение может значительно повлиять на потребление ЦП базы данных.

Например, следующая команда заполтит материализованное представление.2020-01-01 Максимальное количество записей в каждой операции приема составляет 3 миллиона. Команда выполнит операции приема с параллелизмом 2.

.create async materialized-view with (
        backfill=true,
        effectiveDateTime=datetime(2020-01-01),
        MaxSourceRecordsForSingleIngest=3000000,
        Concurrency=2
    )
    CustomerUsage on table T
{
    T
    | summarize count(), dcount(User), max(Duration) by Customer, bin(Timestamp, 1d)
}

Если материализованное представление содержит ключ группы даты и времени, то обратная заполнение поддерживает переопределение времени создания экстентов на основе столбца datetime. Это может быть полезно, например, если вы хотите удалить старые записи до последних, так как политика хранения основана на времени создания экстентов. Свойство updateExtentsCreationTime поддерживается только в том случае, если представление содержит ключ datetime group-by, который использует функцию bin() . Например, следующая обратная заполнение назначает время создания на Timestamp основе ключа по группе:

.create async materialized-view with (
        backfill=true,
        updateExtentsCreationTime=true
    )
    CustomerUsage on table T
{
    T
    | summarize count() by Customer, bin(Timestamp, 1d)
}

Обратная заполнение экстентами перемещения

Параметр обратной заполнения путем перемещения экстентов заполняет материализованное представление на основе существующей таблицы, которая не обязательно является исходной таблицей материализованного представления. Для этого необходимо переместить экстенты из указанной таблицы в базовую материализованную таблицу представлений. Этот процесс подразумевает следующее:

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

Например, если материализованное представление имеет следующее агрегирование:

T | summarize arg_max(Timestamp, *) by EventId

Затем записи в исходной таблице для операции экстентов перемещения уже должны быть дедупированы EventID.

Так как операция использует экстенты перемещения, записи будут удалены из указанной таблицы во время резервной заполнения (перемещаются, не копируются).

Резервное заполнение экстентами перемещения не поддерживается для всех функций агрегирования, поддерживаемых в материализованных представлениях. Это приведет к сбою для агрегатов, таких как avg()dcount(), в которых базовые данные, хранящиеся в представлении, отличаются от агрегирования.

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

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

Случаи использования

Вариант обратной заполнения экстентами перемещения может быть полезен в двух основных сценариях:

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

Вы также можете использовать один из рекомендуемых средств оркестрации.

Примеры:

В следующем примере таблица DeduplicatedTable содержит одну запись для EventId каждого экземпляра и будет использоваться в качестве базового плана для материализованного представления. Только записи в этом приеме после времени создания представления будут включены в T материализованное представление.
```
.create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```
effectiveDateTime Если свойство указано вместе со move_extents_from свойством, то только экстенты, DeduplicatedTable значение которых MaxCreatedOn больше, чем effectiveDateTime в обратном заполнении (перемещается в материализованное представление):
```
.create async materialized-view with 
    (move_extents_from=DeduplicatedTable, effectiveDateTime=datetime(2019-01-01)) 
    MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```
В следующем примере показано использование свойства в параметре обратной source_ingestion_time_from заполнения экстентами перемещения. Использование обоих source_ingestion_time_from и move_extents_from указывает, что материализованное представление заполняется из двух источников:
- Таблицаmove_extents_from: DeduplicatedTable в следующем примере. Эта таблица должна содержать все исторические данные для резервного заполнения. При необходимости можно использовать effectiveDateTime свойство для включения только экстентов, DeduplicatedTable MaxCreatedOn значение которых больше effectiveDateTime.
- Исходная таблица материализованного представления: T в следующем примере. Обратная заполнение из этой таблицы содержит только записи, значения ingestion_time() которых source_ingestion_time_fromбольше.
  
  Свойство source_ingestion_time_from должно использоваться только для обработки возможной потери данных в течение короткого времени между подготовкой таблицы к обратной заполнению (DeduplicatedTable) и временем создания представления. Не устанавливайте это свойство слишком далеко в прошлом. Это привело бы к материализованному представлению со значительным задержкой, что может быть трудно догнать.
В следующем примере предположим, что текущее время равно 2020-01-01 03:00. Таблица DeduplicatedTable представляет собой дедупированную таблицу T. Он включает все исторические данные, дедупликированные до тех пор 2020-01-01 00:00. Команда create используется DeduplicatedTable для резервного заполнения материализованного представления с помощью экстентов перемещения. Команда create также включает все записи, T которые были приема с тех пор 2020-01-01.
```
.create async materialized-view with (move_extents_from=DeduplicatedTable, source_ingestion_time_from=datetime(2020-01-01)) MV on table T
{
    T
    | summarize arg_max(Timestamp, *) by EventId
} 
```

Отмена создания материализованного представления

Вы можете отменить процесс создания материализованного представления при использовании параметра обратной заполнения. Это действие полезно, если создание занимает слишком много времени, и вы хотите остановить его во время его выполнения.

Предупреждение

Материализованное представление невозможно восстановить после выполнения этой команды.

Процесс создания не может быть немедленно отменен. Команда отмены сигнализирует материализации для остановки, а создание периодически проверяет, запрашивается ли отмена. Команда отмены ожидает не более 10 минут до отмены процесса создания материализованного представления и сообщает обратно, если отмена выполнена успешно.

Даже если отмена не завершается в течение 10 минут, а команда отмены сообщает об ошибке, материализованное представление, вероятно, отменяется позже в процессе создания. Команда .show operations указывает, была ли отменена операция.

Если операция больше не выполняется при .cancel operation выполнении команды, команда сообщит об ошибке.

Синтаксис

.cancel operationoperationId

Дополнительные сведения о соглашениях синтаксиса.

Параметры

Имя (название)	Type	Обязательно	Описание
`operationId`	`guid`	✔️	Идентификатор операции, возвращенный командой `.create async materialized-view` .

Выходные данные

Имя.	Тип	Описание
OperationId	`guid`	Идентификатор `.create materialized-view` операции команды.
Операция	`string`	Тип операции.
StartedOn	`datetime`	Время начала операции создания.
ОтменаState	`string`	Одно из следующих: `Canceled successfully` (создание было отменено), `Cancellation failed` (ожидание истечения времени ожидания отмены), (создание представления больше не выполняется, `Unknown` но не было отменено этой операцией).
ReasonPhrase	`string`	Причина того, почему отмена не была успешной.

Примеры

.cancel operation c4b29441-4873-4e36-8310-c631c35c916e

OperationId	Операция	StartedOn	ОтменаState	ReasonPhrase
`c4b29441-4873-4e36-8310-c631c35c916e`	`MaterializedViewCreateOrAlter`	`2020-05-08 19:45:03.9184142`	`Canceled successfully`

Если отмена не завершена в течение 10 минут, CancellationState укажите сбой. Затем можно отменить создание.

Поделиться через

.create materialized-view

Разрешения

Синтаксис

Параметры

Поддерживаемые свойства

Создание материализованного представления по материализованному представлению

Примеры

Замечания

Параметр запроса

Поддерживаемые функции агрегирования

Советы по производительности

Заполнение материализованного представления

Обратная заполнение экстентами перемещения

Случаи использования

Отмена создания материализованного представления

Синтаксис

Параметры

Выходные данные

Примеры

Обратная связь

Дополнительные ресурсы