.criar exibição materializada

Aplica-se a: ✅Microsoft Fabric✅Azure Data Explorer

Uma exibição materializada é uma consulta de agregação em uma tabela de origem. Isso representa uma única declaração summarize.

Há duas maneiras possíveis de criar uma vista materializada, conforme observado pela opção de aterramento no comando:

Crie a exibição materializada a partir de agora:

• A exibição materializada é criada vazia. Ele inclui apenas registros assimilados após a criação da exibição. A criação desse tipo retorna imediatamente e a exibição fica imediatamente disponível para consulta.

Crie a exibição materializada com base nos registros existentes na tabela de origem:

• Consulte Aterrar uma vista materializada.
• A criação pode demorar muito para ser concluída, dependendo do número de registros na tabela de origem. O modo de exibição não está disponível para consultas até que o backfill seja concluído.
• Quando você estiver usando essa opção, o comando create deve ser async. Você pode monitorar a execução usando o .show operations comando.
• Você pode cancelar o processo de aterramento usando o .cancel operation comando.

Importante

Em tabelas de origem grandes, a opção de aterramento pode levar muito tempo para ser concluída. Se esse processo falhar transitóriamente durante a execução, ele não será repetido automaticamente. Em seguida, você deve executar novamente o comando create. Para obter mais informações, consulte Preencher uma vista materializada.

Permissões

Você deve ter pelo menos permissões de administrador de banco de dados para executar esse comando. O criador de modo de exibição materializado torna-se seu administrador.

Sintaxe

.create[async] [ifnotexists] materialized-view [,...] )Consulta MaterializedViewNameon tableSourceTableName{}

Saiba mais sobre as convenções de sintaxe.

Parâmetros

Nome	Digitar	Obrigatória	Descrição
PropertyName, PropertyValue	string		Lista de propriedades na forma de pares de nome e valor, da lista de propriedades suportadas.
MaterializedViewName	string	✔️	Nome da exibição materializada. O nome da exibição não pode entrar em conflito com nomes de tabela ou função no mesmo banco de dados e deve aderir às regras de nomenclatura do identificador.
Nome_da_Tabela_de_Origem	string	✔️	Nome da tabela de origem na qual a exibição é definida.
Consulta	string	✔️	Definição de consulta da visualização materializada. Para obter mais informações e limitações, consulte a seção Parâmetro de consulta.

Observação

Se a exibição materializada já existir:

• Se o sinalizador ifnotexists for especificado, o comando será ignorado. Nenhuma alteração é aplicada, mesmo que a nova definição não corresponda à definição existente.
• Se o ifnotexists sinalizador não for especificado, um erro será retornado.
• Para alterar uma exibição materializada existente, use o comando .alter materialized-view .

Propriedades aceitas

As propriedades a seguir têm suporte na with(cláusula PropertyName=PropertyValue.) Todas as propriedades são opcionais.

Nome	Digitar	Descrição
Aterramento	bool	Se a exibição deve ser criada com base em todos os registros atualmente em SourceTable (true) ou criá-la a partir de agora (false). O padrão é false. Para obter mais informações, consulte Preencher uma vista materializada.
data/hora efetiva	datetime	Relevante apenas quando você estiver usando backfill. Se definido, a criação só será arquivada com registros ingeridos após o datetime. backfill também deve ser definido como true. Essa propriedade espera um literal datetime; por exemplo, effectiveDateTime=datetime(2019-05-01).
updateExtentsCreationTime	bool	Relevante apenas quando você estiver usando backfill. Se definido como true, tempo de criação de extensão será atribuído com base na chave grupo por data durante o processo de backfill. Para obter mais informações, consulte Preencher uma vista materializada.
olhar para trás	timespan	O período de tempo que limita o período durante o qual são esperadas duplicatas ou atualizações. Para obter mais informações, consulte de período de pesquisa.
lookback_column	string	Uma coluna string no modo de exibição que serve como referência para o período de pesquisa. Se essa coluna estiver vazia, mas a lookback tiver um valor, a exibição materializada usará um lookback padrão. Para obter mais informações, consulte de período de pesquisa.
autoUpdateSchema	bool	Se a exibição deve ser atualizada automaticamente nas alterações da tabela de origem. O padrão é false. Essa opção é válida apenas para exibições do tipo arg_max(Timestamp, *)/arg_min(Timestamp, *)/take_any(*) (somente quando o argumento da coluna é ).* Se essa opção estiver definida como true, as alterações na tabela de origem serão refletidas automaticamente na exibição materializada.
dimensionTables	matriz	Um argumento dinâmico que inclui uma matriz de tabelas de dimensões na exibição. Consulte Parâmetro de consulta.
folder	string	A pasta da exibição materializada.
Sequência de documentos	string	Uma cadeia de caracteres que documenta a exibição materializada.
allowMaterializedViewsWithoutRowLevelSecurity	bool	Permite criar uma exibição materializada em uma tabela com a política de segurança em nível de linha habilitada.

Aviso

• O sistema desabilita automaticamente uma exibição materializada se as alterações na tabela de origem da exibição materializada ou alterações nos dados levarem à incompatibilidade entre a consulta de exibição materializada e o esquema de exibição materializado esperado.
• Para evitar esse erro, a consulta de exibição materializada deve ser determinística. Por exemplo, o bag_unpack ou plug-in de dinâmica resulta em um esquema não determinístico.
• Quando você está usando uma arg_max(Timestamp, *) agregação e quando autoUpdateSchema é false, as alterações na tabela de origem também podem levar a incompatibilidades de esquema. Evite essa falha definindo a consulta de exibição como arg_max(Timestamp, Column1, Column2, ...)ou usando a autoUpdateSchema opção.
• O uso autoUpdateSchema pode levar à perda irreversível de dados quando as colunas na tabela de origem são descartadas.
• Monitore a desabilitação automática de exibições materializadas usando a métrica MaterializedViewResult.
• Depois de corrigir problemas de incompatibilidade, você deverá reabilitar explicitamente a exibição usando o comando .enable materialized-view.

Período de pesquisa

Uma especifica o período de tempo máximo esperado entre dois registros da mesma combinação de chave de grupo por na tabela de origem de exibição materializada. A configuração de uma pesquisa pode melhorar significativamente o desempenho da exibição materializada.

Por exemplo, considere uma exibição materializada usada para armazenar o último evento para cada sessão de um serviço Web. A exibição é definida da seguinte maneira:

Events | summarize arg_max(ReceivedTime, *) by SessionId

Quando estiver claro que uma sessão não durará mais de um dia, o período de lookback_column e lookback pode ser definido para melhorar o desempenho:

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

A configuração de um lookback em uma exibição materializada reduz a parte da exibição verificada durante a materialização. Em vez de verificar toda a exibição materializada, somente a parte que se enquadra no período de pesquisa é combinada com o delta durante a materialização. Para obter mais informações, consulte Como as exibições materializadas funcionam. Embora essa etapa possa melhorar significativamente o desempenho da exibição materializada, definir um período de pesquisa incorreto pode resultar em registros duplicados. No exemplo anterior, se um registro for ingerido dois dias após um registro para o mesmo SessionId, o modo de exibição materializado terá registros duplicados para esse SessionId.

Coluna lookback

O período de pesquisa é sempre relativo a uma coluna datetime na exibição materializada. Há duas maneiras de definir esta coluna:

• Padrão: relativo à ingestion_time() do registro na tabela de origem. Os registros são eliminação de duplicação somente em relação aos registros que são ingeridos na tabela de origem após um período de pesquisa relativo aos registros atuais. Esse tipo de pesquisa é válido apenas para arg_max, arg_minou take_any exibições materializadas e apenas para exibições que preservam o tempo de ingestão. Para obter mais informações, consulte Limitações de exibições materializadas e problemas conhecidos. Você pode configurar a opção padrão definindo a propriedade lookback sem a propriedade lookback_column.

• lookback_column (versão prévia): em relação a uma coluna datetime no modo de exibição materializado. O lookback é especificado explicitamente na definição de exibição materializada, usando a propriedade lookback_column. Para obter mais informações, consulte Limitações conhecidas. Você pode configurar a opção de coluna de lookback definindo as propriedades lookback e lookback_column.

Limitações conhecidas

• Depois que um lookback_column é definido, você não pode alterar seu valor.
• O uso de um lookback_column poderá levar a duplicatas se a coluna tiver valores datetime(null). Nesses casos, para uma determinada combinação de chaves agrupadas, o modo de exibição pode acabar com um registro com um valor datetime(null) e outro com um valor não nulo.

Criar exibição materializada sobre exibição materializada

Você pode criar uma exibição materializada sobre outra exibição materializada somente quando a exibição materializada de origem for uma take_any(*) agregação (eliminação de duplicação). Para obter mais informações, consulte Exibição materializada sobre exibição materializada e Exemplos.

Sintaxe:

.create[async] [ifnotexists] materialized-view [,...] )Consulta MaterializedViewNameon materialized-viewSourceMaterializedViewName{}

Parâmetros:

Nome	Digitar	Obrigatória	Descrição
PropertyName, PropertyValue	string		Lista de propriedades na forma de pares de nome e valor, da lista de propriedades suportadas.
MaterializedViewName	string	✔️	Nome da exibição materializada. O nome da exibição não pode entrar em conflito com nomes de tabela ou função no mesmo banco de dados e deve aderir às regras de nomenclatura do identificador.
SourceMaterializedViewName	string	✔️	Nome da exibição materializada de origem na qual a exibição é definida.
Consulta	string	✔️	Definição de consulta da visualização materializada.

Exemplos

• Crie uma exibição de arg_max vazia que materialize apenas os registros ingeridos de agora em diante:

  .create materialized-view ArgMax on table T
  {
      T | summarize arg_max(Timestamp, *) by User
  }
  

• Crie uma exibição materializada para agregações diárias com a opção de aterramento, usando 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 
  } 
  

• Crie uma exibição materializada com backfill e effectiveDateTime. A exibição é criada com base apenas em registros de data e hora.

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

• Crie uma exibição materializada que elimina a eliminação de duplicação da tabela de origem, com base na coluna EventId, usando um lookback de seis horas. Os registros são eliminação de duplicação somente em relação aos registros ingeridos seis horas antes dos registros atuais.

  .create materialized-view with(lookback=6h) DeduplicatedTable on table T
  {
      T
      | summarize take_any(*) by EventId
  }
  

• Crie uma exibição materializada de downsampling com base na exibição materializada DeduplicatedTable:

  .create materialized-view DailyUsage on materialized-view DeduplicatedTable
  {
      DeduplicatedTable
      | summarize count(), dcount(User) by Day=bin(Timestamp, 1d)
  }
  

• Crie uma exibição materializada que elimina a eliminação de duplicação da tabela de origem, com base na coluna EventId, usando um lookback de seis horas. Os registros são duplicados em relação aos registros cujo Timestamp tem uma diferença máxima de seis horas em relação aos registros atuais.

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

• A definição pode incluir operadores adicionais antes da summarize instrução, desde que summarize seja a última:

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

• Aqui estão as exibições materializadas que se unem a uma tabela de dimensões:

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

Comentários

Parâmetro de consulta

As regras a seguir limitam a consulta usada no parâmetro Query da exibição materializada:

• A consulta deve fazer referência a uma única tabela de fatos que é a origem da exibição materializada. Ele deve incluir um único summarize operador e uma ou mais funções de agregação agregadas por um ou mais grupos por expressões. O summarize operador deve ser sempre o último operador na consulta.

  Uma exibição materializada que inclui apenas uma única arg_max/arg_min/take_anyagregação pode ter um desempenho melhor do que uma exibição materializada que inclui essas agregações junto com outras agregações (como ).count/dcount/avg Isso ocorre porque algumas otimizações são relevantes apenas para esses tipos de exibições materializadas. Eles não se aplicam quando a exibição inclui funções de agregação mistas (em que mixed significa ambasarg_max/arg_min/ e outras agregações na mesma exibição).take_any

• A consulta não deve incluir nenhum operador que dependa do now(). Por exemplo, a consulta não deve ter where Timestamp > ago(5d). Use a política de retenção na exibição materializada para limitar o período de tempo que a exibição abrange.

• Não há suporte para os seguintes operadores na consulta de exibição materializada: sort, top-nested, top, partition, serialize.

• Não há suporte para agregações compostas na definição da exibição materializada. Por exemplo, em vez de usar SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Id, defina a visualização materializada como: SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id. Durante o tempo de consulta de exibição, execute MaterializedViewName | project Id, Result=a/b. A saída necessária da exibição, incluindo a coluna calculada (a/b), pode ser encapsulada em uma função armazenada. Acesse a função armazenada em vez de acessar a exibição materializada diretamente.

• Não há suporte para consultas entre eventos e entre bancos de dados.

• Não há suporte para referências a external_table() e externaldata .

• A consulta de exibição materializada não pode incluir textos explicativos que exijam representação. Especificamente, todos os plug-ins de conectividade de consulta que usam representação não são permitidos.

• Além da tabela de origem da exibição, a consulta tem permissão para fazer referência a uma ou mais tabelas de dimensões. As tabelas de dimensões devem ser explicitamente chamadas nas propriedades de exibição. É importante entender o seguinte comportamento ao ingressar em tabelas de dimensões:

  • Os registros na tabela de origem da exibição (a tabela de fatos) são materializados apenas uma vez. As atualizações nas tabelas de dimensões não têm nenhum impacto nos registros que já foram processados da tabela de fatos.

  • Uma latência de ingestão diferente entre a tabela de fatos e a tabela de dimensões pode afetar os resultados da exibição.

    Exemplo: uma definição de exibição inclui uma junção interna com uma tabela de dimensões. No momento da materialização, o registro de dimensão não foi totalmente ingerido, mas já foi ingerido na tabela de fatos. Esse registro é removido do modo de exibição e nunca mais processado.

    Da mesma forma, se a junção for uma junção externa, os registros da tabela de fatos serão processados e adicionados para exibição com um valor nulo para as colunas da tabela de dimensão. Os registros que já foram adicionados (com valores nulos) à exibição não são processados novamente. Seus valores, em colunas da tabela de dimensões, permanecem nulos.

Funções de agregação com suporte

As seguintes funções de agregação são suportadas:

• 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

Dicas de desempenho

• Usar umde chave de datetime agrupado por: exibições materializadas que têm uma coluna datetime, pois uma de suas chaves agrupadas é mais eficiente do que aquelas que não têm. O motivo é que algumas otimizações podem ser aplicadas somente quando há uma chave datetime group-by. Se a adição de uma chave datetime group-by não alterar a semântica da agregação, recomendamos que você a adicione. Você só poderá fazer isso se a coluna datetime for imutável para cada entidade exclusiva.

  Por exemplo, na seguinte agregação:

      SourceTable | summarize take_any(*) by EventId
  

  Se EventId sempre tiver o mesmo Timestamp valor e, portanto, adicionar Timestamp não alterar a semântica da agregação, é melhor definir a exibição como:

      SourceTable | summarize take_any(*) by EventId, Timestamp
  

  Dica

  Os dados que chegam atrasados em uma chave de grupo de data e hora podem ter um impacto negativo no desempenho da exibição materializada. Por exemplo, suponha que uma exibição materializada use bin(Timestamp, 1d) como uma de suas chaves agrupar por e os registros recém-ingeridos na tabela de origem tenham valores antigos Timestamp . Esses registros podem afetar negativamente a exibição materializada.

  Se você espera que os registros de chegada tardia sejam ingeridos na tabela de origem, ajuste a política de cache da exibição materializada de acordo. Por exemplo, se os registros com Carimbo de Data/Hora de seis meses atrás forem ingeridos na tabela de origem, o processo de materialização precisará verificar a exibição materializada dos seis meses anteriores. Se esse período estiver em cache frio, a materialização apresentará erros de cache que têm um impacto negativo no desempenho da exibição.

  Se esses registros de chegada tardia não forem esperados, recomendamos que na consulta de exibição materializada. Filtre esses registros ou normalize seus valores de carimbo de data/hora na hora atual.

• Defina um período de lookback: se aplicável ao seu cenário, adicionar uma lookback propriedade pode melhorar significativamente o desempenho da consulta. Para obter detalhes, consulte Propriedades com suporte.

• Adicionar colunas usadas com frequência para filtragem como chaves agrupar por: as consultas de exibição materializadas são otimizadas quando são filtradas por uma das chaves agrupar por da exibição materializada. Se você souber que seu padrão de consulta geralmente será filtrado por uma coluna imutável de acordo com uma entidade exclusiva na exibição materializada, inclua-o nas chaves agrupar por da exibição materializada.

  Por exemplo, uma exibição materializada expõe arg_max por um valor ResourceId que geralmente é filtrado por SubscriptionId. Supondo que um ResourceId valor sempre pertença ao mesmo SubscriptionId valor, defina a consulta de exibição materializada como:

  .create materialized-view ArgMaxResourceId on table FactResources
  {
      FactResources | summarize arg_max(Timestamp, *) by SubscriptionId, ResourceId 
  }
  

  A definição anterior é preferível ao seguinte:

  .create materialized-view ArgMaxResourceId on table FactResources
  {
      FactResources | summarize arg_max(Timestamp, *) by ResourceId 
  }
  

• Use políticas de atualização quando apropriado: a exibição materializada pode incluir transformações, normalizações e pesquisas em tabelas de dimensões. No entanto, recomendamos que você mova essas operações para uma política de atualização. Deixe apenas a agregação para a exibição materializada.

  Por exemplo, é melhor definir a seguinte política de atualização:

  .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}]'  
  

  E defina a seguinte exibição materializada:

  .create materialized-view Usage on table Events
  {
      Target 
      | summarize count() by ResourceId 
  }
  

  A alternativa, de incluir a política de atualização como parte da consulta de exibição materializada, pode ter um desempenho pior e, portanto, não é recomendada:

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

Dica

Se você precisar do melhor desempenho de tempo de consulta, mas puder tolerar alguma latência de dados, use a função materialized_view().

Preencher uma exibição materializada

Quando você está criando uma exibição materializada usando a propriedade backfill, a exibição materializada é criada com base nos registros disponíveis na tabela de origem. Ou será criado com base em um subconjunto desses registros, se você usar effectiveDateTime.

Nos bastidores, o processo de aterramento divide os dados a serem preenchidos em vários lotes e executa várias operações de ingestão para preencher a exibição. O processo pode demorar muito para ser concluído quando o número de registros na tabela de origem é grande. A duração do processo depende do tamanho do banco de dados. Acompanhe o progresso do aterro usando o .show operations comando.

Falhas transitórias que ocorrem como parte do processo de aterramento são repetidas. Se todas as novas tentativas estiverem esgotadas, o comando falhará e exigirá uma re-execução manual do comando create.

Não recomendamos que você use o preenchimento retroativo quando o número de registros na tabela de origem exceder number-of-nodes X 200 million (às vezes até menos, dependendo da complexidade da consulta). Uma alternativa é a opção de preenchimento por extensões de movimento.

Não há suporte para o uso da opção de backfill para dados em um cache frio. Aumente o período de cache frequente, se necessário, durante a criação da exibição. Isso pode exigir expansão.

Se você tiver falhas na criação de exibições, tente alterar estas propriedades:

• MaxSourceRecordsForSingleIngest: Por padrão, o número de registros de origem em cada operação de ingestão durante o aterramento é de 2 milhões por nó. Você pode alterar esse padrão definindo essa propriedade como o número desejado de registros. (O valor é o número total de registros em cada operação de ingestão.)

  Diminuir esse valor pode ser útil quando a criação falha em limites de memória ou tempos limite de consulta. Aumentar esse valor pode acelerar a criação de exibições, supondo que o banco de dados possa executar a função de agregação em mais registros do que o padrão.

• Concurrency: As operações de ingestão, executadas como parte do processo de aterramento, são executadas simultaneamente. Por padrão, a simultaneidade é min(number_of_nodes * 2, 5). Você pode definir essa propriedade para aumentar ou diminuir a simultaneidade. Recomendamos aumentar esse valor somente se a CPU do banco de dados for baixa, pois o aumento pode afetar significativamente o consumo de CPU do banco de dados.

Por exemplo, o comando a seguir remove o modo de exibição materializado de 2020-01-01. O número máximo de registros em cada operação de ingestão é de 3 milhões. O comando executa as operações de ingestão com simultaneidade de 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)
} 

Se a exibição materializada incluir uma chave de grupo de data e hora, o processo de aterramento dará suporte à substituição da hora de criação da extensão com base na coluna de data e hora. Isso pode ser útil, por exemplo, se você quiser que os registros mais antigos sejam descartados antes dos recentes, pois a política de retenção é baseada no tempo de criação da extensão. A updateExtentsCreationTime propriedade só terá suporte se o modo de exibição incluir uma chave de grupo de data e hora que usa a bin() função. Por exemplo, o seguinte arquivo de fundo atribui o tempo de criação com base no Timestamp chave agrupada:

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

Preenchimento por extensões de movimento

A opção de preenchimento retroativo por extensões de movimentação preenche a exibição materializada com base em uma tabela existente, que não é necessariamente a tabela de origem da exibição materializada. Você obtém o preenchimento retroativo movendo extensões da tabela especificada para a tabela de visualização materializada subjacente. Este processo implica que:

• Os dados na tabela especificada devem ter o mesmo esquema que o esquema de exibição materializado.
• Os registros na tabela especificada são movidos para a exibição no estado em que se encontram. Supõe-se que eles sejam desduplicados com base na definição da exibição materializada.

Por exemplo, se a exibição materializada tiver a seguinte agregação:

T | summarize arg_max(Timestamp, *) by EventId

Em seguida, os registros na tabela de origem para a operação de extensão de movimentação já devem ter sido eliminados com duplicação por EventID.

Como a operação usa extensões .move, os registros são removidos da tabela especificada durante o backfill (movido, não copiado).

Não há suporte para o backfill por extensões de movimentação para todas as funções de agregação com suporte em exibições materializadas. Falha em agregações como avg(), dcount(), em que os dados subjacentes armazenados na exibição são diferentes da agregação em si.

A exibição materializada é preenchida somente com base na tabela especificada. A materialização de registros na tabela de origem do modo de exibição começa a partir do tempo de criação do modo de exibição, por padrão.

Se a tabela de origem da exibição materializada estiver ingerindo dados continuamente, criar a exibição usando extensões de movimentação poderá resultar em alguma perda de dados. Isso ocorre porque os registros ingeridos na tabela de origem, no curto período entre o tempo de preparação da tabela para o preenchimento invertido e o momento em que o modo de exibição é criado, não são incluídos na exibição materializada. Para lidar com esse cenário, você pode definir a source_ingestion_time_from propriedade como a hora de início da exibição materializada na tabela de origem.

Casos de uso

A opção de preenchimento retroativo por extensões de movimentação pode ser útil em dois cenários principais:

• Quando você já tem uma tabela que inclui os dados de origem com eliminação de duplicação para a exibição materializada e não precisa desses registros nessa tabela após a criação da exibição porque está usando apenas a exibição materializada.

• Quando a tabela de origem da exibição materializada é muito grande e o preenchimento retroativo da exibição com base na tabela de origem não funciona bem devido às limitações mencionadas anteriormente. Nesse caso, você pode orquestrar o processo de aterramento em uma tabela temporária usando a ingestão de comandos de consulta. Quando a tabela temporária incluir todos os registros do aterro, crie a exibição materializada com base nessa tabela.

Exemplos:

• No exemplo a seguir, a tabela DeduplicatedTable inclui um único registro por instância de EventId e é usada como a linha de base para a exibição materializada. Somente os registros em T que são ingeridos após a hora de criação do modo de exibição são incluídos na exibição materializada.

  .create async materialized-view with (move_extents_from=DeduplicatedTable) MV on table T
  {
      T
      | summarize arg_max(Timestamp, *) by EventId
  } 
  

• Se a effectiveDateTime propriedade for especificada junto com a move_extents_from propriedade, somente as extensões cujo DeduplicatedTableMaxCreatedOn valor é maior que effectiveDateTime serão incluídas no aterramento (movidas para a vista materializada):

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

• O exemplo a seguir demonstra o uso da source_ingestion_time_from propriedade na opção de preenchimento retroativo por extensões de movimentação. Usar ambos source_ingestion_time_from e move_extents_from indica que a exibição materializada é preenchida de duas fontes:

  • A move_extents_from tabela: DeduplicatedTable no exemplo a seguir. Esta tabela deve incluir todos os dados históricos a serem preenchidos. Opcionalmente, você pode usar a effectiveDateTime propriedade para incluir apenas extensões em DeduplicatedTable cujo MaxCreatedOn valor é maior que effectiveDateTime.

  • A tabela de origem da exibição materializada: T no exemplo a seguir. O preenchimento retroativo desta tabela inclui apenas registros cujo valor ingestion_time() é maior que source_ingestion_time_from.

    A source_ingestion_time_from propriedade deve ser usada apenas para lidar com a possível perda de dados no curto período de tempo entre a preparação da tabela para preenchimento retroativo de (DeduplicatedTable) e o momento em que a exibição é criada. Não defina essa propriedade muito longe no passado. Isso iniciaria a visão materializada com um atraso significativo, o que pode ser difícil de acompanhar.

  No exemplo a seguir, suponha que a hora atual seja 2020-01-01 03:00. Table DeduplicatedTable é uma tabela com desduplicação de T. Inclui todos os dados históricos, desduplicados até 2020-01-01 00:00. O create comando usa DeduplicatedTable para preencher a vista materializada usando extensões de movimento. O create comando também inclui todos os registros que T foram assimilados desde 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
  } 
  

Cancelar a criação de exibição materializada

Você pode cancelar o processo de criação da vista materializada quando estiver usando a opção de aterramento. Essa ação é útil quando a criação está demorando muito e você deseja interrompê-la enquanto ela está em execução.

Aviso

A exibição materializada não pode ser restaurada depois que você executa esse comando.

O processo de criação não pode ser cancelado imediatamente. O comando cancel sinaliza a materialização para parar e a criação verifica periodicamente se um cancelamento foi solicitado. O comando cancelar aguarda um período máximo de 10 minutos até que o processo de criação da exibição materializada seja cancelado. Ele retornará se o cancelamento foi bem-sucedido.

Mesmo que o cancelamento não seja bem-sucedido em 10 minutos e o comando cancel relate falha, a exibição materializada provavelmente se cancelará posteriormente no processo de criação. O .show operations comando indica se a operação foi cancelada.

Se a operação não estiver mais em andamento quando o comando .cancel operation for emitido, o comando relatará um erro.

Sintaxe

.cancel operation ID da operação

Saiba mais sobre as convenções de sintaxe.

Parâmetros

Nome	Digitar	Obrigatória	Descrição
operationId	guid	✔️	A ID da operação retornada do .create async materialized-view comando.

Saída

Nome	Digitar	Descrição
OperationId	guid	A ID da operação do .create materialized-view comando.
Operação	string	O tipo de operação.
StartedOn	datetime	A hora de início da operação de criação.
CancellationState	string	Um dos seguintes: Canceled successfully (a criação foi cancelada), Cancellation failed (aguarde o cancelamento expirou), (a criação da exibição não está mais em execução, Unknown mas não foi cancelada por esta operação).
ReasonPhrase	string	A razão pela qual o cancelamento não foi bem-sucedido.

Exemplos

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

OperationId	Operação	StartedOn	CancellationState	ReasonPhrase
c4b29441-4873-4e36-8310-c631c35c916e	MaterializedViewCreateOrAlter	2020-05-08 19:45:03.9184142	Canceled successfully

Se o cancelamento não for concluído em 10 minutos, CancellationState indicará falha. A criação pode então ser cancelada.

Conteúdo relacionado

• exibições materializadas
• casos de uso de exibições materializadas
• .alter materialized-view
• .drop materialized-view
• .show materialized-view(s)