.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. A exibição não estará disponível para consultas até que o preenchimento 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.

Permissões

Esse comando requer permissões de administrador de banco de dados. O criador da visão materializada torna-se o administrador dela.

Sintaxe

.create[async] [ifnotexists] materialized-view [(with PropertyName = PropertyValue,...] )Consulta MaterializedViewName on table SourceTableName { }

Saiba mais sobre as convenções de sintaxe.

Parâmetros

Propriedades com suporte

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

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 [(with PropertyName = PropertyValue,...] )Consulta MaterializedViewName on materialized-view SourceMaterializedViewName { }

Parâmetros:

Exemplos

• Crie uma visualização vazia arg_max que materializará apenas os registros ingeridos a partir de agora:

  .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 deduza a duplicação da tabela de origem, com base na EventId coluna, usando uma retrospectiva de 6 horas. A duplicação dos registros será removida apenas em relação aos registros assimilados 6 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 com base na exibição materializada anterior DeduplicatedTable :

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

• 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_maxarg_mintake_any//agregaçã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 ambastake_any//arg_maxarg_min e outras agregações na mesma exibição).

• 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 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 será removido da exibição e nunca mais será processado.

    Da mesma forma, se a junção for uma junção externa, o registro da tabela de fatos será processado e adicionado à exibição com um valor nulo para as colunas da tabela de dimensões. Os registros que já foram adicionados (com valores nulos) à exibição não serão processados novamente. Seus valores, em colunas da tabela de dimensões, permanecerão 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 uma chave de grupo de data e hora: as exibições materializadas que têm uma coluna de data e hora como uma de suas chaves de grupo por são mais eficientes 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 for esperado que os registros com carimbo de data/hora de seis meses atrás sejam 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 sofrerá erros de cache que terão 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, você filtre esses registros ou normalize seus valores de carimbo de data/hora para a 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 é arg_max exposta por um ResourceId valor que geralmente será 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
  }
  

Preencher uma exibição materializada

Quando você estiver criando uma exibição materializada usando a backfill propriedade, a exibição materializada será criada com base nos registros disponíveis na tabela de origem. Ou ele 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 tentativas forem esgotadas, o comando falhará e exigirá uma reexecuçã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.

O uso da opção de aterramento não é suportado para dados em um cache frio. Aumente o período de cache ativo, 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 estiver baixa, pois o aumento pode afetar significativamente o consumo de CPU do banco de dados.

Por exemplo, o comando a seguir preencherá a exibição materializada do 2020-01-01. O número máximo de registros em cada operação de ingestão é de 3 milhões. O comando executará 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 preenchimento retroativo a seguir atribuirá o tempo de criação com base na Timestamp chave agrupar por:

.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 serão removidos da tabela especificada durante o aterramento (movidos, não copiados).

O preenchimento por extensões de movimentação não é suportado para todas as funções de agregação suportadas em vistas materializadas. Ele falhará para agregações como avg(), dcount(), nas quais os dados subjacentes armazenados na exibição são diferentes da própria agregação.

A exibição materializada é preenchida somente com base na tabela especificada. A materialização de registros na tabela de origem da exibição começará a partir do momento de criação da 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 de tempo entre o momento de preparação da tabela para preenchimento retroativo e o momento em que a exibição é criada, não serã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 EventId instância e será usada como linha de base para a exibição materializada. Somente os registros ingeridos T após o tempo de criação da exibição serã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 DeduplicatedTable MaxCreatedOn 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.

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 cancel aguarda um período máximo de 10 minutos até que o processo de criação da exibição materializada seja cancelado e relata 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 .cancel operation comando for emitido, o comando relatará um erro informando isso.

Sintaxe

.cancel operationID da operação

Saiba mais sobre as convenções de sintaxe.

Parâmetros

Saída

Exemplos

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

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