.создать материализованное представление

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

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

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

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

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

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

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

Разрешения

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

Синтаксис

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

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

Параметры

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

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

период ретроспективного обзора.

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

Например, рассмотрим материализованное представление, используемое для хранения последнего события для каждого сеанса веб-службы. Представление определяется следующим образом:

Events | summarize arg_max(ReceivedTime, *) by SessionId

Если ясно, что сеанс не будет длиться более одного дня, то lookback_column можно задать и lookback период, чтобы повысить производительность:

.create materialized-view with(lookback=1d, lookback_column = "ReceivedTime") SessionEvents on table Events
{
    Events
    | summarize arg_max(ReceivedTime, *) by SessionId
}

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

Столбец Lookback

Период обратного просмотра всегда относительно столбца datetime в материализованном представлении. Существует два способа определения этого столбца:

• По умолчанию: Относительно ingestion_time() записи в исходной таблице. Записи дедупликируются только для записей, которые отправляются в исходную таблицу после периода обратного просмотра относительно текущих записей. Этот вид обратного просмотра действителен только для представлений , arg_maxили arg_min материализованных представлений, и только для take_anyпредставлений, сохраняющих время приема. Дополнительные сведения см. в разделе "Материализованные представления" и известные проблемы. Параметр по умолчанию можно настроить, задав lookback свойство без lookback_column свойства.

• lookback_column (предварительная версия): Относительно столбца datetime в материализованном представлении. Обратный просмотр явно указан в определении материализованного представления с помощью lookback_column свойства. Дополнительные сведения см. в описании известных ограничений. Параметр столбца lookback можно настроить, задав как свойства, так lookback и lookback_column свойства.

Известные ограничения

• lookback_column После определения нельзя изменить его значение.
• lookback_column Использование может привести к дубликатам, если столбец имеет datetime(null) значения. В таких случаях для заданного сочетания ключей по группам представление может в конечном итоге иметь одно значение datetime(null) и другое с ненулевое значение.

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

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

Синтаксис

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

Параметры:

Примеры

• Создайте пустое 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 с помощью обратного просмотра в шесть часов. Записи дедупликируются только в отношении записей, которые получают шесть часов до текущих записей.

  .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)
  }
  

• Создайте материализованное представление, которое дедупликирует исходную таблицу на основе столбца EventId с помощью обратного просмотра в шесть часов. Записи дедупликируются для записей, для которых Timestamp не более шести часов отличается от текущих записей.

  .create materialized-view with(lookback=6h, lookback_column = "Timestamp") LatestEventID on table T
  {
      T
      | summarize arg_max(Timestamp, *) by EventId
  }
  

• Определение может включать дополнительные операторы перед 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_min/take_any агрегат, может выполняться лучше, чем материализованное представление, которое включает эти агрегаты вместе с другими агрегатами (напримерcount/dcount/avg, ). Это связано с тем, что некоторые оптимизации относятся только к этим типам материализованных представлений. Они не применяются, если представление включает смешанные функции агрегирования (где смешанные средства оба иarg_max/arg_min/take_anyдругие агрегаты в одном представлении).

• Запрос не должен включать операторы, зависящие от now(). Например, запрос не должен иметь where Timestamp > ago(5d). Используйте политику хранения в материализованном представлении, чтобы ограничить период времени, охватываемого представлением.

• В материализованном запросе представления не поддерживаются следующие операторы: sort, , top-nestedtop, partition. 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) в представление не обрабатываются снова. Их значения в столбцах из таблицы измерений остаются пустыми.

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

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

• count
• countif
• dcount
• dcountif
• min
• max
• avg
• avgif
• sum
• sumif
• arg_max
• arg_min
• take_any
• take_anyif
• hll
• make_set
• make_list
• make_bag
• percentile, percentiles
• tdigest

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

• Используйте ключ даты и времени: материализованные представления, имеющие 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
  }
  

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

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

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

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

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

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

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

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

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

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

Например, следующая команда создает резервную копию материализованного представления.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 свойство для включения только экстентов, DeduplicatedTableMaxCreatedOn значение которых больше 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 operation operationId

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

Параметры

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

Примеры

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

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

Связанный контент

• материализованные представления
• варианты использования материализованных представлений
• Alter materialized-view
• .drop материализованное представление
• .show materialized-view(s)