.create materialized-view

Une vue matérialisée est une requête d’agrégation sur une table source. Il représente une seule déclaration summarize.

Il existe deux façons possibles de créer une vue matérialisée, comme indiqué par l’option de remplissage dans la commande :

Créez la vue matérialisée à partir de maintenant :

• La vue matérialisée est créée vide. Il inclut uniquement les enregistrements ingérés après la création de la vue. La création de ce type retourne immédiatement et la vue est immédiatement disponible pour la requête.

Créez la vue matérialisée en fonction des enregistrements existants dans la table source :

• Consultez Remplissage d’une vue matérialisée.
• La création peut prendre un certain temps, en fonction du nombre d’enregistrements dans la table source. La vue n’est pas disponible pour les requêtes tant que le remplissage n’est pas terminé.
• Lorsque vous utilisez cette option, la commande create doit être async. Vous pouvez surveiller l’exécution à l’aide de la .show operations commande .
• Vous pouvez annuler le processus de remplissage à l’aide de la .cancel operation commande .

Important

Sur les tables sources volumineuses, l’option de remplissage peut prendre beaucoup de temps. Si ce processus échoue temporairement pendant l’exécution, il ne sera pas retenté automatiquement. Vous devez ensuite réexécuter la commande create. Pour plus d’informations, consultez Remplissage d’une vue matérialisée.

Autorisations

Cette commande nécessite des autorisations de Administration de base de données. Le créateur de la vue matérialisée en devient l’administrateur.

Syntax

.create [async] [ifnotexists] materialized-view [ with(PropertyName=PropertyValue,...)] MaterializedViewNameon tableSourceTableName{Requête}

Découvrez les conventions de syntaxe.

Paramètres

Nom	Type	Obligatoire	Description
PropertyName, PropertyValue	string		Liste des propriétés sous forme de paires nom et valeur, à partir de la liste des propriétés prises en charge.
MaterializedViewName	string	✔️	Nom de la vue matérialisée. Le nom de la vue ne peut pas entrer en conflit avec les noms de table ou de fonction dans la même base de données et doit respecter les règles de nommage de l’identificateur.
SourceTableName	string	✔️	Nom de la table source sur laquelle la vue est définie.
Requête	string	✔️	Définition de la requête de la vue matérialisée. Pour plus d’informations et pour connaître les limitations, consultez la section Paramètre de requête .

Notes

Si la vue matérialisée existe déjà :

• Si l’indicateur ifnotexists est spécifié, la commande est ignorée. Aucune modification n’est appliquée, même si la nouvelle définition ne correspond pas à la définition existante.
• Si l’indicateur ifnotexists n’est pas spécifié, une erreur est retournée.
• Pour modifier une vue matérialisée existante, utilisez la commande .alter materialized-view .

Propriétés prises en charge

Les propriétés suivantes sont prises en charge dans la with( clause PropertyName=PropertyValue). Toutes les propriétés sont facultatives.

Nom	Type	Description
Remblai	bool	Si vous souhaitez créer l’affichage en fonction de tous les enregistrements actuellement dans SourceTable (true), ou pour le créer à partir de maintenant (false). La valeur par défaut est false. Pour plus d’informations, consultez Remplissage d’une vue matérialisée.
effectiveDateTime	datetime	Pertinent uniquement lorsque vous utilisez backfill. S’il est défini, la création remblaye uniquement avec les enregistrements ingérés après la datetime. backfill doit également avoir la valeur true. Cette propriété attend un littéral datetime ; par exemple, effectiveDateTime=datetime(2019-05-01).
updateExtentsCreationTime	bool	Pertinent uniquement lorsque vous utilisez backfill. S’il est défini sur true, l’heure de création de l’étendue est attribuée en fonction de la clé groupe par datetime pendant le processus de remplissage. Pour plus d’informations, consultez Remplissage d’une vue matérialisée.
retour en arrière	timespan	Valide uniquement pour les arg_max//arg_mintake_any vues matérialisées. Il limite la période pendant laquelle les doublons sont attendus. Par exemple, si un retour en arrière de 6 heures est spécifié sur une arg_max vue, la déduplication entre les enregistrements nouvellement ingérés et les enregistrements existants prend uniquement en compte les enregistrements qui ont été ingérés il y a 6 heures. La recherche en arrière est relative à ingestion_time. La définition incorrecte de la période de recherche en arrière peut entraîner des doublons dans la vue matérialisée. Par exemple, si un enregistrement d’une clé spécifique est ingéré 10 heures après l’ingestion d’un enregistrement pour la même clé et que le lookback est défini sur 6 heures, cette clé sera un doublon dans la vue. La période de recherche en arrière est appliquée pendant le temps de matérialisation et le temps de requête.
autoUpdateSchema	bool	Indique s’il faut mettre à jour automatiquement la vue sur les modifications de la table source. La valeur par défaut est false. Cette option est valide uniquement pour les vues de type arg_max(Timestamp, *)//arg_min(Timestamp, *)take_any(*) (uniquement lorsque l’argument de la colonne est ).* Si cette option a la valeur true, les modifications apportées à la table source seront automatiquement reflétées dans la vue matérialisée.
dimensionTables	tableau	Argument dynamique qui inclut un tableau de tables de dimension dans la vue. Consultez Paramètre de requête.
dossier	string	Dossier de la vue matérialisée.
docString	string	Chaîne qui documente la vue matérialisée.
allowMaterializedViewsWithoutRowLevelSecurity	bool	Permet de créer une vue matérialisée sur une table avec la stratégie de sécurité au niveau des lignes activée.

Avertissement

• Le système désactive automatiquement une vue matérialisée si les modifications apportées à la table source de la vue matérialisée ou les modifications apportées aux données entraînent une incompatibilité entre la requête d’affichage matérialisé et le schéma de vue matérialisé attendu.
• Pour éviter cette erreur, la requête d’affichage matérialisé doit être déterministe. Par exemple, le plug-in bag_unpack ou pivot génère un schéma non déterministe.
• Lorsque vous utilisez une arg_max(Timestamp, *) agrégation et que la autoUpdateSchema valeur est false, les modifications apportées à la table source peuvent également entraîner des incompatibilités de schéma. Évitez cet échec en définissant la requête d’affichage en tant que arg_max(Timestamp, Column1, Column2, ...)ou en utilisant l’option autoUpdateSchema .
• L’utilisation autoUpdateSchema peut entraîner une perte de données irréversible lorsque les colonnes de la table source sont supprimées.
• Surveillez la désactivation automatique des vues matérialisées à l’aide de la métrique MaterializedViewResult.
• Une fois que vous avez résolu les problèmes d’incompatibilité, vous devez explicitement réactiver la vue à l’aide de la commande activer la vue matérialisée .

Créer une vue matérialisée sur une vue matérialisée

Vous pouvez créer une vue matérialisée sur une autre vue matérialisée uniquement lorsque la vue matérialisée source est une take_any(*) agrégation (déduplication). Pour plus d’informations, consultez Affichage matérialisé sur la vue matérialisée et Exemples.

Syntaxe :

.create [async] [ifnotexists] materialized-view [ with(PropertyName=PropertyValue,...)] MaterializedViewNameon materialized-viewSourceMaterializedViewName{Requête}

Paramètres :

Nom	Type	Obligatoire	Description
PropertyName, PropertyValue	string		Liste des propriétés sous forme de paires nom et valeur, à partir de la liste des propriétés prises en charge.
MaterializedViewName	string	✔️	Nom de la vue matérialisée. Le nom de la vue ne peut pas entrer en conflit avec les noms de table ou de fonction dans la même base de données et doit respecter les règles de nommage de l’identificateur.
SourceMaterializedViewName	string	✔️	Nom de la vue matérialisée source sur laquelle la vue est définie.
Requête	string	✔️	Définition de la requête de la vue matérialisée.

Exemples

• Créez une vue vide arg_max qui matérialisera uniquement les enregistrements ingérés à partir de maintenant :

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

• Créez une vue matérialisée pour les agrégats quotidiens avec l’option de remplissage, à l’aide de 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 
  } 
  

• Créez une vue matérialisée avec backfill et effectiveDateTime. La vue est créée en fonction des enregistrements de datetime uniquement.

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

• Créez une vue matérialisée qui déduplique la table source, en fonction de la colonne, à l’aide EventId d’un lookback de 6 heures. Les enregistrements sont dédupliqués par rapport uniquement aux enregistrements ingérés 6 heures avant les enregistrements actuels.

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

• Créez une vue matérialisée de sous-échantillonnage basée sur la vue matérialisée précédente DeduplicatedTable :

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

• La définition peut inclure des opérateurs supplémentaires avant l’instruction summarize , à condition que summarize soit la dernière :

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

• Voici des vues matérialisées qui se joignent à une table de dimension :

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

Remarques

Paramètre de requête.

Les règles suivantes limitent la requête utilisée dans le paramètre requête d’affichage matérialisé :

• La requête doit référencer une table de faits unique qui est la source de la vue matérialisée. Il doit inclure un opérateur unique summarize et une ou plusieurs fonctions d’agrégation agrégées par un ou plusieurs groupes par expressions. L’opérateur summarize doit toujours être le dernier opérateur de la requête.

  Une vue matérialisée qui n’inclut qu’une seule arg_maxarg_mintake_any//agrégation peut fonctionner mieux qu’une vue matérialisée qui inclut ces agrégations avec d’autres agrégations (telles que ).count/dcount/avg En effet, certaines optimisations ne concernent que ces types de vues matérialisées. Elles ne s’appliquent pas lorsque la vue inclut des fonctions d’agrégation mixtes (où mixte signifie à la fois et arg_max//arg_mintake_any d’autres agrégations dans la même vue).

• La requête ne doit pas inclure d’opérateurs qui dépendent now()de . Par exemple, la requête ne doit pas avoir where Timestamp > ago(5d). Utilisez la stratégie de rétention sur la vue matérialisée pour limiter la période pendant laquelle la vue couvre.

• Les opérateurs suivants ne sont pas pris en charge dans la requête d’affichage matérialisé : sort, top-nested, top, partition, . serialize

• Les agrégations composites ne sont pas prises en charge dans la définition de la vue matérialisée. Par instance, au lieu d’utiliser SourceTableName | summarize Result=sum(Column1)/sum(Column2) by Id, définissez la vue matérialisée comme : SourceTableName | summarize a=sum(Column1), b=sum(Column2) by Id. Pendant l’heure de la requête d’affichage, exécutez MaterializedViewName | project Id, Result=a/b. La sortie requise de la vue, y compris la colonne calculée (a/b), peut être encapsulée dans une fonction stockée. Accédez à la fonction stockée au lieu d’accéder directement à la vue matérialisée.

• Les requêtes inter-clusters et inter-bases de données ne sont pas prises en charge.

• Les références à external_table() et externaldata ne sont pas prises en charge.

• La requête d’affichage matérialisé ne peut pas inclure de légendes qui nécessitent l’emprunt d’identité. Plus précisément, tous les plug-ins de connectivité de requête qui utilisent l’emprunt d’identité ne sont pas autorisés.

• En plus de la table source de la vue, la requête est autorisée à référencer une ou plusieurs tables de dimension. Les tables de dimension doivent être explicitement appelées dans les propriétés de la vue. Il est important de comprendre le comportement suivant lorsque vous joignez des tables de dimension :

  • Les enregistrements de la table source de la vue (la table des faits) ne sont matérialisés qu’une seule fois. Mises à jour aux tables de dimension n’ont aucun impact sur les enregistrements qui ont déjà été traités à partir de la table de faits.

  • Une latence d’ingestion différente entre la table de faits et la table de dimension peut affecter les résultats de la vue.

    Exemple : Une définition de vue inclut une jointure interne avec une table de dimension. Au moment de la matérialisation, l’enregistrement de dimension n’était pas entièrement ingéré, mais il était déjà ingéré dans la table de faits. Cet enregistrement sera supprimé de la vue et ne sera plus jamais traité.

    De même, si la jointure est une jointure externe, l’enregistrement de la table de faits est traité et ajouté pour l’afficher avec une valeur null pour les colonnes de la table de dimension. Les enregistrements qui ont déjà été ajoutés (avec des valeurs null) à la vue ne seront plus traités. Leurs valeurs, dans les colonnes de la table de dimension, restent null.

Fonctions d’agrégation prises en charge

Les fonctions d’agrégation suivantes sont prises en charge :

• 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

Conseils sur les performances

• Utiliser une clé de groupe datetime : les vues matérialisées qui ont une colonne datetime comme l’une de leurs clés de groupe par sont plus efficaces que celles qui n’en ont pas. La raison en est que certaines optimisations ne peuvent être appliquées que lorsqu’il existe un groupe datetime par clé. Si l’ajout d’une clé groupe par datetime ne modifie pas la sémantique de votre agrégation, nous vous recommandons de l’ajouter. Vous pouvez effectuer cette opération uniquement si la colonne datetime est immuable pour chaque entité unique.

  Par exemple, dans l’agrégation suivante :

      SourceTable | summarize take_any(*) by EventId
  

  Si EventId a toujours la même Timestamp valeur et que l’ajout Timestamp ne modifie pas la sémantique de l’agrégation, il est préférable de définir la vue comme suit :

      SourceTable | summarize take_any(*) by EventId, Timestamp
  

  Conseil

  L’arrivée tardive de données dans un groupe datetime par clé peut avoir un impact négatif sur les performances de la vue matérialisée. Par exemple, supposons qu’une vue matérialisée utilise bin(Timestamp, 1d) comme l’une de ses clés group-by, et que plusieurs valeurs aberrantes dans les données ont des valeurs très anciennes Timestamp . Ces valeurs hors norme peuvent affecter négativement la vue matérialisée.

  Dans la requête d’affichage matérialisé, nous vous recommandons de filtrer les enregistrements hors norme ou de normaliser ces enregistrements à l’heure actuelle.

• Définir une période de recherche en arrière : si applicable à votre scénario, l’ajout d’une lookback propriété peut considérablement améliorer les performances des requêtes. Pour plus d’informations, consultez Propriétés prises en charge.

• Ajouter des colonnes fréquemment utilisées pour filtrer en tant que clés de groupe par : les requêtes d’affichage matérialisée sont optimisées lorsqu’elles sont filtrées par l’une des clés de groupe par de la vue matérialisée. Si vous savez que votre modèle de requête filtre souvent par une colonne immuable en fonction d’une entité unique dans la vue matérialisée, incluez-le dans les clés de groupe par de la vue matérialisée.

  Par exemple, une vue matérialisée expose arg_max par une ResourceId valeur qui sera souvent filtrée par SubscriptionId. En supposant qu’une ResourceId valeur appartient toujours à la même SubscriptionId valeur, définissez la requête d’affichage matérialisée comme suit :

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

  La définition précédente est préférable à la définition suivante :

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

• Utilisez des stratégies de mise à jour le cas échéant : la vue matérialisée peut inclure des transformations, des normalisations et des recherches dans des tables de dimension. Toutefois, nous vous recommandons de déplacer ces opérations vers une stratégie de mise à jour. Laissez uniquement l’agrégation pour la vue matérialisée.

  Par exemple, il est préférable de définir la stratégie de mise à jour suivante :

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

  Et définissez la vue matérialisée suivante :

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

  L’alternative, qui consiste à inclure la stratégie de mise à jour dans le cadre de la requête d’affichage matérialisée, peut s’exécuter moins bien et donc pas recommandée :

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

Conseil

Si vous avez besoin des meilleures performances de temps de requête, mais que vous pouvez tolérer une certaine latence des données, utilisez la fonction materialized_view().

Remplissage d’une vue matérialisée

Lorsque vous créez une vue matérialisée à l’aide de la backfill propriété , la vue matérialisée est créée en fonction des enregistrements disponibles dans la table source. Il sera également créé en fonction d’un sous-ensemble de ces enregistrements, si vous utilisez effectiveDateTime.

En arrière-plan, le processus de remblayage fractionne les données à remplir en plusieurs lots et exécute plusieurs opérations d’ingestion pour remplir la vue. Le processus peut prendre beaucoup de temps lorsque le nombre d’enregistrements dans la table source est élevé. La durée du processus dépend de la taille du cluster. Suivez la progression du remplissage à l’aide de la .show operations commande .

Les échecs temporaires qui se produisent dans le cadre du processus de remplissage sont retentés. Si toutes les nouvelles tentatives sont épuisées, la commande échoue et nécessite une ré-exécution manuelle de la commande create.

Nous vous déconseillons number-of-nodes X 200 million d’utiliser le remplissage lorsque le nombre d’enregistrements dans la table source dépasse (parfois même moins, selon la complexité de la requête). Une alternative est l’option de remplissage par déplacement d’étendues .

L’utilisation de l’option de remplissage n’est pas prise en charge pour les données dans un cache froid. Augmentez la période de cache chaud, si nécessaire, pendant la durée de la création de la vue. Cela peut nécessiter un scale-out.

Si vous rencontrez des échecs lors de la création de la vue, essayez de modifier ces propriétés :

• MaxSourceRecordsForSingleIngest: Par défaut, le nombre d’enregistrements sources dans chaque opération d’ingestion pendant le remplissage est de 2 millions par nœud. Vous pouvez modifier cette valeur par défaut en définissant cette propriété sur le nombre d’enregistrements souhaité. (La valeur est le nombre total d’enregistrements dans chaque opération d’ingestion.)

  La diminution de cette valeur peut être utile lorsque la création échoue sur des limites de mémoire ou des délais d’expiration des requêtes. L’augmentation de cette valeur peut accélérer la création d’affichage, en supposant que le cluster peut exécuter la fonction d’agrégation sur plus d’enregistrements que la valeur par défaut.

• Concurrency: les opérations d’ingestion, exécutées dans le cadre du processus de remplissage, s’exécutent simultanément. Par défaut, la concurrence est min(number_of_nodes * 2, 5). Vous pouvez définir cette propriété pour augmenter ou diminuer la concurrence. Nous vous recommandons d’augmenter cette valeur uniquement si le processeur du cluster est faible, car l’augmentation peut affecter considérablement la consommation du processeur du cluster.

Par exemple, la commande suivante remblaye la vue matérialisée à partir de 2020-01-01. Le nombre maximal d’enregistrements dans chaque opération d’ingestion est de 3 millions. La commande exécute les opérations d’ingestion avec la concurrence 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)
} 

Si la vue matérialisée inclut une clé de groupe datetime, le processus de remplissage prend en charge le remplacement de l’heure de création de l’étendue en fonction de la colonne datetime. Cela peut être utile, par exemple, si vous souhaitez que les enregistrements plus anciens soient supprimés avant les enregistrements récents, car la stratégie de rétention est basée sur l’heure de création de l’étendue. La updateExtentsCreationTime propriété n’est prise en charge que si la vue inclut une clé de groupe par datetime qui utilise la bin() fonction . Par exemple, le remplissage suivant affecte le temps de création en fonction de la Timestamp clé de groupe par :

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

Remplissage par extension de déplacement

L’option de remblayage en déplaçant des étendues remblaye la vue matérialisée en fonction d’une table existante, qui n’est pas nécessairement la table source de la vue matérialisée. Vous obtenez le remplissage en déplaçant les étendues de la table spécifiée vers la table d’affichage matérialisée sous-jacente. Ce processus implique que :

• Les données de la table spécifiée doivent avoir le même schéma que le schéma d’affichage matérialisé.
• Les enregistrements de la table spécifiée sont déplacés vers la vue en l’état. Ils sont supposés être dédupés en fonction de la définition de la vue matérialisée.

Par exemple, si la vue matérialisée a l’agrégation suivante :

T | summarize arg_max(Timestamp, *) by EventId

Ensuite, les enregistrements de la table source pour l’opération de déplacement des étendues doivent déjà être dédupés par EventID.

Étant donné que l’opération utilise des étendues .move, les enregistrements sont supprimés de la table spécifiée pendant le remplissage (déplacés, non copiés).

Le remplissage par les étendues de déplacement n’est pas pris en charge pour toutes les fonctions d’agrégation prises en charge dans les vues matérialisées. Il échoue pour les agrégations telles que avg(), dcount()dans lesquelles les données sous-jacentes stockées dans la vue sont différentes de l’agrégation elle-même.

La vue matérialisée est remblayée uniquement en fonction de la table spécifiée. La matérialisation des enregistrements dans la table source de la vue commence à partir de l’heure de création de l’affichage, par défaut.

Si la table source de la vue matérialisée ingère continuellement des données, la création de la vue à l’aide d’étendues de déplacement peut entraîner une perte de données. En effet, les enregistrements ingérés dans la table source, dans le court laps de temps entre le moment de la préparation de la table à remplir et le moment où la vue est créée, ne sont pas inclus dans la vue matérialisée. Pour gérer ce scénario, vous pouvez définir la source_ingestion_time_from propriété sur l’heure de début de la vue matérialisée sur la table source.

Cas d'utilisation

L’option de remplissage par déplacement d’étendues peut être utile dans deux scénarios main :

• Lorsque vous avez déjà une table qui inclut les données sources dédupliquées pour la vue matérialisée, et que vous n’avez pas besoin de ces enregistrements dans cette table après la création de la vue, car vous utilisez uniquement la vue matérialisée.

• Lorsque la table source de la vue matérialisée est très grande et que le remplissage de l’affichage basé sur la table source ne fonctionne pas correctement en raison des limitations mentionnées précédemment. Dans ce cas, vous pouvez orchestrer le processus de remplissage vous-même dans une table temporaire à l’aide de l’ingestion à partir de commandes de requête et de l’un des outils d’orchestration recommandés. Lorsque la table temporaire inclut tous les enregistrements pour le remplissage, créez la vue matérialisée basée sur cette table.

Exemples :

• Dans l’exemple suivant, la table DeduplicatedTable inclut un enregistrement unique par EventId instance et sera utilisée comme base de référence pour la vue matérialisée. Seuls les enregistrements dans T qui sont ingérés après l’heure de création de la vue seront inclus dans la vue matérialisée.

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

• Si la effectiveDateTime propriété est spécifiée avec la propriété, seules les étendues dont DeduplicatedTableMaxCreatedOn la move_extents_from valeur est supérieure à sont effectiveDateTime incluses dans le remplissage (déplacées vers la vue matérialisée) :

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

• L’exemple suivant illustre l’utilisation de la source_ingestion_time_from propriété dans l’option de remplissage en déplaçant des étendues. source_ingestion_time_from L’utilisation de et move_extents_from indique que la vue matérialisée est remblayée à partir de deux sources :

  • La move_extents_from table : DeduplicatedTable dans l’exemple suivant. Cette table doit inclure toutes les données historiques à remplir. Vous pouvez éventuellement utiliser la effectiveDateTime propriété pour inclure uniquement des étendues dans DeduplicatedTable dont MaxCreatedOn la valeur est supérieure effectiveDateTimeà .

  • Table source de la vue matérialisée : T dans l’exemple suivant. Le remplissage de cette table inclut uniquement les enregistrements dont la valeur ingestion_time() est supérieure à source_ingestion_time_from.

    La source_ingestion_time_from propriété doit uniquement être utilisée pour gérer la perte de données possible dans le court laps de temps entre la préparation de la table à remplir à partir de (DeduplicatedTable) et le moment où la vue est créée. Ne définissez pas cette propriété trop loin dans le passé. Cela commencerait la vue matérialisée avec un décalage important, qui pourrait être difficile à rattraper.

  Dans l’exemple suivant, supposons que l’heure actuelle est 2020-01-01 03:00. Table DeduplicatedTable est une table dédupée de T. Il inclut toutes les données historiques, dédupliquées jusqu’à 2020-01-01 00:00. La create commande utilise DeduplicatedTable pour le remplissage de la vue matérialisée à l’aide des étendues de déplacement. La create commande inclut également tous les enregistrements dans T qui ont été ingérés depuis 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
  } 
  

Annuler la création d’une vue matérialisée

Vous pouvez annuler le processus de création d’une vue matérialisée lorsque vous utilisez l’option de remplissage. Cette action est utile lorsque la création prend trop de temps et que vous souhaitez l’arrêter pendant son exécution.

Avertissement

La vue matérialisée ne peut pas être restaurée après l’exécution de cette commande.

Le processus de création ne peut pas être annulé immédiatement. La commande cancel signale l’arrêt de la matérialisation et la création vérifie régulièrement si une annulation a été demandée. La commande cancel attend pendant une période maximale de 10 minutes jusqu’à ce que le processus de création de la vue matérialisée soit annulé, et elle signale si l’annulation a réussi.

Même si l’annulation n’aboutit pas dans les 10 minutes et que la commande d’annulation signale un échec, la vue matérialisée s’annulera probablement elle-même plus tard dans le processus de création. La .show operations commande indique si l’opération a été annulée.

Si l’opération n’est plus en cours lorsque la .cancel operation commande est émise, la commande signale une erreur.

Syntax

.cancel operationoperationId

Découvrez les conventions de syntaxe.

Paramètres

Nom	Type	Obligatoire	Description
operationId	guid	✔️	ID d’opération retourné par la .create async materialized-view commande.

Output

Nom	Type	Description
OperationId	guid	ID d’opération de la .create materialized-view commande.
Opération	string	Type d’opération.
StartedOn	datetime	Heure de début de l’opération de création.
CancellationState	string	L’un des éléments suivants : Canceled successfully (la création a été annulée), Cancellation failed (délai d’attente d’annulation expiré), Unknown (la création de l’affichage n’est plus en cours d’exécution, mais n’a pas été annulée par cette opération).
ReasonPhrase	string	Raison pour laquelle l’annulation n’a pas réussi.

Exemples

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

OperationId	Opération	StartedOn	CancellationState	ReasonPhrase
c4b29441-4873-4e36-8310-c631c35c916e	MaterializedViewCreateOrAlter	2020-05-08 19:45:03.9184142	Canceled successfully

Si l’annulation n’est pas terminée dans les 10 minutes, CancellationState indique l’échec. La création peut ensuite être annulée.