Cas d’usage des vues matérialisées

  • Article

Les vues matérialisées exposent 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’utilisation courants

Voici des scénarios courants qui peuvent être traités à l’aide d’une vue matérialisée :

  • Mettre à jour les données : Mettez à jour les données en retournant le dernier enregistrement par entité à l’aide dearg_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éduisez 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 de temps. Par exemple, maintenez une instantané à jour d’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 les enregistrements dans une table à l’aide take_any() de (fonction d’agrégation). Par exemple, 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
}

    Notes

    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 les fonctions remplacent les tables portant le même nom. Pour éviter les références cycliques dans la définition de la 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. Lors de la gestion des enregistrements avec des informations incomplètes ou obsolètes pour chaque colonne, une vue matérialisée peut fournir les dernières mises à jour pour chaque colonne, à l’exclusion des entités qui ont été supprimées.

Considérez la table d’entrée suivante nommée Events:

Input

Timestamp 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 la 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
}

Sortie

id Timestamp_col1 col1 Timestamp_col2 col2 Timestamp_col3 col3 Timestamp 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 propre les résultats :

ItemHistory
| project Timestamp, cud, id, col1, col2, col3
| where cud != "D"
| project-away cud

Sortie finale

Dernière mise à jour pour chaque colonne pour ID 1, puisque l’ID 2 a été supprimé.

Timestamp ID col1 col2 col3
2023-10-24 02:00:00.0000000 1 1 23 33

Affichages matérialisés 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, contrairement aux stratégies de mise à jour. Les stratégies de mise à jour s’exécutent séparément pour chaque lot d’ingestion et peuvent donc uniquement effectuer des agrégations au sein du 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’un 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 l’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. En revanche, les vues matérialisées 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 ingestion. Les enregistrements dans la table source sont disponibles pour les requêtes avant leur matérialisation.

  • 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 lors de l’exécution de la stratégie de mise à jour ou de la matérialisation, il existe un risque de négliger les données. En savoir plus sur dimension tables le paramètre de requête de vue matérialisée et dans les tables de fait et de dimension.

Notes

Si vous avez besoin de matérialiser des jointures, qui ne conviennent pas aux stratégies de mise à jour et aux vues matérialisées, vous pouvez orchestrer votre propre processus à cette fin, à l’aide d’outils d’orchestration et d’ingestion à partir de commandes de requête.

Contenu connexe