Cas d’usage des vues matérialisées
S’applique à : ✅Microsoft Fabric✅Azure Data Explorer
vues matérialisées exposer une requête d’agrégation sur une table source ou une autre vue matérialisée. Cet article traite des cas d’usage courants et avancés pour les vues matérialisées.
Cas d’usage courants
Voici des scénarios courants qui peuvent être traités à l’aide d’une vue matérialisée :
Mettre à jour les données : Mettre à jour les données en retournant le dernier enregistrement par entité à l’aide de
arg_max()
(fonction d’agrégation). Par exemple, créez une vue qui matérialise uniquement les enregistrements ingérés à partir de maintenant :.create materialized-view ArgMax on table T { T | summarize arg_max(Timestamp, *) by User }
Réduire la résolution des données Réduire la résolution des données en calculant des statistiques périodiques sur les données brutes. Utilisez différentes fonctions d’agrégation par période. Par exemple, conservez un instantané up-to-date des utilisateurs distincts par jour :
.create materialized-view UsersByDay on table T { T | summarize dcount(User) by bin(Timestamp, 1d) }
Dédupliquer les enregistrements : dédupliquer des enregistrements dans une table à l’aide de
take_any()
(fonction d’agrégation). Par exemple, créez une vue matérialisée qui déduplique la table source en fonction de la colonneEventId
, à l’aide d’une recherche 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 }
Note
Vous pouvez masquer la table source en créant une fonction portant le même nom que la table qui fait référence à la vue matérialisée à la place. Ce modèle garantit que les appelants interrogeant la table accèdent à la vue matérialisée dédupliquée, car fonctions remplacent les tables du même nom. Pour éviter les références cycliques dans la définition de vue, utilisez la fonction table() pour référencer la table source :
.create materialized-view DeduplicatedTable on table T { table('T') | summarize take_any(*) by EventId }
Pour plus d’exemples, consultez la commande .create materialized-view.
Scénario avancé
Vous pouvez utiliser une vue matérialisée pour le traitement des événements de création/mise à jour/suppression. Pour les enregistrements avec des informations incomplètes ou obsolètes dans chaque colonne, une vue matérialisée peut fournir les dernières mises à jour de chaque colonne, à l’exclusion des entités qui ont été supprimées.
Considérez la table d’entrée suivante nommée Events
:
d’entrée
Horodatage | Cud | ID | col1 | col2 | col3 |
---|---|---|---|---|---|
2023-10-24 00:00:00.0000000 | C | 1 | 1 | 2 | |
2023-10-24 01:00:00.0000000 | U | 1 | 22 | 33 | |
2023-10-24 02:00:00.0000000 | U | 1 | 23 | ||
2023-10-24 00:00:00.0000000 | C | 2 | 1 | 2 | |
2023-10-24 00:10:00.0000000 | U | 2 | 4 | ||
2023-10-24 02:00:00.0000000 | D | 2 |
Créez une vue matérialisée pour obtenir la dernière mise à jour par colonne, à l’aide de la fonction d’agrégation arg_max():
Exécuter le de requête
.create materialized-view ItemHistory on table Events
{
Events
| extend Timestamp_col1 = iff(isnull(col1), datetime(1970-01-01), Timestamp),
Timestamp_col2 = iff(isnull(col2), datetime(1970-01-01), Timestamp),
Timestamp_col3 = iff(isnull(col3), datetime(1970-01-01), Timestamp)
| summarize arg_max(Timestamp_col1, col1), arg_max(Timestamp_col2, col2), arg_max(Timestamp_col3, col3), arg_max(Timestamp, cud) by id
}
de sortie
ID | Timestamp_col1 | col1 | Timestamp_col2 | col2 | Timestamp_col3 | col3 | Horodatage | Cud |
---|---|---|---|---|---|---|---|---|
2 | 2023-10-24 00:00:00.0000000 | 1 | 2023-10-24 00:10:00.0000000 | 4 | 1970-01-01 00:00:00.0000000 | 2023-10-24 02:00:00.0000000 | D | |
1 | 2023-10-24 00:00:00.0000000 | 1 | 2023-10-24 02:00:00.0000000 | 23 | 2023-10-24 01:00:00.0000000 | 33 | 2023-10-24 02:00:00.0000000 | U |
Vous pouvez créer une fonction stockée pour nettoyer davantage les résultats :
ItemHistory
| project Timestamp, cud, id, col1, col2, col3
| where cud != "D"
| project-away cud
de sortie finale
La dernière mise à jour de chaque colonne pour l’ID 1
, car l’ID 2
a été supprimé.
Horodatage | ID | col1 | col2 | col3 |
---|---|---|---|---|
2023-10-24 02:00:00.0000000 | 1 | 1 | 23 | 33 |
Vues matérialisées et stratégies de mise à jour
Les vues matérialisées et les stratégies de mise à jour fonctionnent différemment et servent différents cas d’usage. Utilisez les instructions suivantes pour identifier celle que vous devez utiliser :
Les vues matérialisées conviennent aux agrégations , tandis que les stratégies de mise à jour ne le sont pas. Les stratégies de mise à jour s’exécutent séparément pour chaque lot d’ingestion et peuvent donc effectuer uniquement des agrégations dans le même lot d’ingestion. Si vous avez besoin d’une requête d’agrégation, utilisez toujours des vues matérialisées.
Les stratégies de mise à jour sont utiles pour les transformations de données, les enrichissements avec des tables de dimension (généralement à l’aide d''opérateur de recherche) et d’autres manipulations de données qui peuvent s’exécuter dans l’étendue d’une seule ingestion.
Les stratégies de mise à jour s’exécutent pendant le temps d’ingestion. Les données ne sont pas disponibles pour les requêtes dans la table source ou la table cible tant que toutes les stratégies de mise à jour ne sont pas exécutées. Les vues matérialisées, en revanche, ne font pas partie du pipeline d’ingestion. Le processus de matérialisation s’exécute régulièrement en arrière-plan, après l’ingestion. Les enregistrements de la table source sont disponibles pour les requêtes avant qu’elles ne soient matérialisées.
Les stratégies de mise à jour et les vues matérialisées peuvent incorporer des jointures , mais leur efficacité est limitée à des scénarios spécifiques. Plus précisément, les jointures ne conviennent que lorsque les données requises pour la jointure des deux côtés sont accessibles au moment de la stratégie de mise à jour ou du processus de matérialisation. Si des entités correspondantes sont ingérées lorsque la stratégie de mise à jour ou la matérialisation s’exécute, il y a un risque d’ignorer les données. En savoir plus sur
dimension tables
dans paramètre de requête de vue matérialisée et dans tables de faits et de dimension.
Note
Si vous devez matérialiser des jointures qui ne conviennent pas aux stratégies de mise à jour et aux vues matérialisées, vous pouvez gérer vous-même ce processus. Pour créer et stocker les résultats des opérations de jointure, utilisez outils d’orchestration et ingérer à partir des commandes de requête.