Notez que vous consultez la documentation Looker. Pour accéder à la documentation sur Looker Studio, consultez la page https://support.google.com/looker-studio.

Cette page a été traduite par l'API Cloud Translation.

Tutoriel sur la détection d'agrégats

Pour en savoir plus, consultez la page de documentation Reconnaissance d'agrégats.

Introduction

Cette page est un guide permettant d'implémenter la notoriété agrégée dans un scénario pratique, y compris l'identification des opportunités d'implémentation, la valeur générée par la notoriété agrégée et un workflow simple pour l'implémenter dans un modèle réel. Cette page n'explique pas en détail toutes les fonctionnalités agrégées de notoriété ni les cas limites, ni un catalogue exhaustif de toutes leurs fonctionnalités.

Qu'est-ce que la notoriété globale ?

Dans Looker, vous interrogez principalement les tables ou les vues brutes de votre base de données. Il s'agit parfois de tables dérivées persistantes (PDT) Looker.

Vous pouvez souvent rencontrer des ensembles de données ou des tables très volumineux qui, pour être performants, nécessitent des tables d'agrégation ou des propriétés de consolidation.

En règle générale, vous pouvez créer des tableaux d'agrégation comme une table orders_daily contenant une dimensionnalité limitée. Celles-ci doivent être traitées séparément et modélisées séparément dans l'exploration, et elles ne sont pas correctement intégrées dans le modèle. Ces limites entraînent une mauvaise expérience utilisateur lorsque celui-ci doit choisir entre plusieurs explorations pour les mêmes données.

Désormais, grâce à la fonctionnalité de sensibilisation des agrégations de Looker, vous pouvez préconstruire des tables agrégées à différents niveaux de granularité, de dimensionnalité et d'agrégation, et indiquer à Looker comment les utiliser dans des explorations existantes. Les requêtes exploiteront ensuite ces tables de consolidation lorsque Looker le juge approprié, sans intervention de l'utilisateur. Cela permettra de réduire la taille des requêtes, de réduire les temps d'attente et d'améliorer l'expérience utilisateur.

REMARQUE:Les tables agrégées de Looker sont un type de table dérivée persistante (PDT). Cela signifie que les tables agrégées ont les mêmes exigences en matière de base de données et de connexion que les tables PDT.
Pour savoir si votre dialecte de base de données et votre connexion à Looker peuvent prendre en charge les tables PDT, consultez les exigences indiquées dans la page de documentation Tables dérivées dans Looker.
Pour savoir si votre dialecte de base de données est compatible avec la reconnaissance d'agrégats, consultez la page de documentation Reconnaissance d'agrégats.

La valeur de la notoriété agrégée

Il existe un certain nombre de propositions de valeur importantes qui regroupent les offres de sensibilisation pour générer de la valeur supplémentaire à partir de votre modèle Looker existant:

Amélioration des performances:si vous implémentez la notoriété globale, les requêtes des utilisateurs seront plus rapides. Looker utilisera une table plus petite si elle contient les données nécessaires à la requête de l'utilisateur.
Économies:certains dialectes sont facturés en fonction de la taille de la requête sur un modèle de consommation. En demandant à Looker d'interroger des tables plus petites, vous réduirez le coût par requête utilisateur.
Amélioration de l'expérience utilisateur:en plus d'une expérience améliorée permettant de récupérer les réponses plus rapidement, la consolidation élimine la création d'explorations redondantes.
Réduction de l'empreinte LookML:le remplacement des stratégies de sensibilisation agrégées existantes basées sur Liquid par des implémentations natives flexibles permet d'améliorer la résilience et de réduire les erreurs.
Possibilité d'exploiter le code LookML existant:les tables agrégées utilisent l'objet query, qui réutilise la logique modélisée existante plutôt que de dupliquer la logique avec un langage SQL personnalisé explicite.

Exemple de base

Voici une implémentation très simple dans un modèle Looker pour démontrer à quel point la reconnaissance des agrégations peut être légère. À partir d'une table flights hypothétique de la base de données avec une ligne pour chaque vol enregistré via la FAA, nous pouvons modéliser cette table dans Looker avec sa propre vue et sa propre exploration. Voici le code LookML d'une table agrégée que nous pouvons définir pour l'exploration:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Avec cette table agrégée, un utilisateur peut interroger l'exploration flights, et Looker exploitera automatiquement la table agrégée définie dans le code LookML et se servira de la table agrégée pour répondre aux requêtes. L'utilisateur n'a pas besoin d'informer Looker des conditions particulières: si la table peut convenir aux champs sélectionnés par l'utilisateur, Looker l'utilisera.

Les utilisateurs disposant des autorisations see_sql peuvent utiliser les commentaires de l'onglet SQL d'une exploration pour voir quelle table agrégée sera utilisée pour une requête. Voici un exemple d'onglet SQL Looker pour une requête qui utilise la table agrégée flights:flights_by_week_and_carrier in teach_scratch:

Onglet SQL d'une exploration affichant le code SQL sous-jacent et un commentaire spécifiant le schéma entièrement nouveau de la table agrégée en cours d'utilisation.

Consultez la page de documentation Reconnaissance d'agrégats pour savoir comment déterminer si des tables agrégées sont utilisées pour une requête.

Identification des opportunités

Pour maximiser les avantages de la détection d'agrégats, vous devez identifier l'impact potentiel de cette fonctionnalité sur l'optimisation ou sur la valeur de cette fonctionnalité.

Identifier les tableaux de bord avec un temps d'exécution élevé

Une excellente opportunité de reconnaissance des agrégations consiste à créer des tables agrégées pour les tableaux de bord fréquemment utilisés avec un temps d'exécution très élevé. Vos utilisateurs vous parleront peut-être des tableaux de bord lents, mais si vous disposez de see_system_activity, vous pouvez également utiliser l'exploration de l'historique de l'activité du système de Looker pour trouver les tableaux de bord dont l'exécution est plus lente que la moyenne. Vous pouvez ouvrir ce lien d'exploration de l'historique de l'activité du système dans un navigateur, puis remplacer "nom d'hôte" dans l'URL par le nom de votre instance Looker. Une visualisation de l'exploration s'affiche. Elle contient des données relatives aux tableaux de bord de votre instance, y compris le titre, l'historique, le nombre d'explorations, la proportion du cache par rapport à la base de données et est moins performante que la moyenne:

Dans cet exemple, un certain nombre de tableaux de bord avec une utilisation élevée présentent des performances inférieures à la moyenne, comme le tableau de bord Sample Visualizations. Le tableau de bord Sample Visualizations utilise deux explorations. Une bonne stratégie consiste donc à créer des tables agrégées pour chacune de ces explorations.

Identifier les explorations lentes et fortement interrogées par les utilisateurs

Une autre possibilité d'obtenir une visibilité globale réside dans les explorations, qui sont fortement interrogées par les utilisateurs et dont le taux de réponse aux requêtes est inférieur à la moyenne.

L'exploration de l'historique des activités du système peut vous servir de point de départ pour identifier des opportunités d'optimisation des explorations. En guise de raccourci, vous pouvez ouvrir le lien d'exploration de l'historique des activités du système dans un navigateur, puis remplacer "nom d'hôte" dans l'URL par le nom de votre instance Looker. Une visualisation de l'exploration s'affiche. Elle contient des données relatives aux explorations de votre instance, y compris l'exploration, le modèle, le nombre d'exécutions de requêtes, le nombre d'utilisateurs et le moyen d'exécution en secondes:

Visualisation sous forme de tableau montrant que les explorations "order_items" et "flights" sont les plus fréquemment interrogées sur l'instance.

Dans l'exploration de l'historique, vous pouvez identifier les types d'explorations suivants sur votre instance:

les explorations interrogées par les utilisateurs (par opposition aux requêtes de l'API ou des requêtes d'envois programmés) ;
Explorer des requêtes fréquentes
Explorations peu performantes (par rapport aux autres explorations)

Dans l'exemple d'exploration précédent de l'historique de l'activité du système, les explorations flights et order_items sont susceptibles d'être implémentées dans la détection d'agrégats.

Identifier les champs fréquemment utilisés dans les requêtes

Enfin, vous pouvez identifier d'autres opportunités au niveau des données en comprenant les champs que les utilisateurs incluent couramment dans les requêtes et les filtres.

Utilisez l'exploration d'utilisation du champ Activité système pour comprendre les champs couramment sélectionnés dans les explorations que vous avez identifiés comme lents et très utilisés. Pour aller plus vite, vous pouvez ouvrir ce lien d'exploration de l'utilisation du champ des activités système dans un navigateur, puis remplacer "nom d'hôte" dans l'URL par le nom de votre instance Looker. Remplacez les filtres en conséquence. Une exploration s'affiche avec une visualisation sous forme de graphique à barres qui indique le nombre de fois qu'un champ a été utilisé dans une requête:

Graphique à barres montrant que les champs "flights.count" et "flights.depart_week" de l'exploration "flights" dans le modèle faa sont les plus utilisés.

Dans l'exemple d'exploration de l'activité système illustré sur l'image, vous pouvez voir que flights.count et flights.depart_week sont les deux champs les plus couramment sélectionnés pour l'exploration. Par conséquent, ces champs se prêtent très bien aux champs à inclure dans les tableaux cumulés.

Des données concrètes de ce type sont utiles, mais il existe des éléments subjectifs qui guideront vos critères de sélection. Par exemple, en examinant les quatre champs précédents, vous pouvez supposer sans risque que les utilisateurs regardent souvent le nombre de vols programmés et le nombre de vols annulés, et qu'ils veulent répartir ces données par semaine et par transporteur. Il s'agit d'un exemple d'une combinaison claire, logique et concrète de champs et de paramètres.

Résumé

Les étapes décrites sur cette page de documentation doivent vous servir de guide pour trouver les tableaux de bord, les explorations et les champs à optimiser. Il convient également de comprendre que les trois peuvent s'exclure mutuellement: les tableaux de bord problématiques peuvent ne pas être alimentés par les explorations problématiques, et la création de tables agrégées avec les champs couramment utilisés peut ne pas aider ces tableaux de bord du tout. Il est possible qu'il s'agisse de trois implémentations distinctes de reconnaissance d'agrégats.

Concevoir des tableaux cumulés

Après avoir identifié les opportunités de sensibilisation agrégée, vous pouvez concevoir des tableaux cumulés qui répondront au mieux à ces opportunités. Consultez la page de documentation Reconnaissance d'agrégats pour obtenir des informations sur les champs, les mesures et les périodes acceptés dans les tableaux cumulés, ainsi que d'autres consignes pour la conception de tableaux cumulés.

REMARQUE:Les tables agrégées n'ont pas besoin d'être une correspondance exacte pour que votre requête puisse être utilisée. Si votre requête est de précision hebdomadaire et que vous disposez d'une table de consolidation quotidienne, Looker utilisera votre table agrégée au lieu de votre table brute au niveau de l'horodatage. De même, si vous disposez d'une table agrégée aux niveaux brand et date et qu'un utilisateur envoie des requêtes au niveau brand uniquement, Looker peut tout de même l'utiliser pour identifier les agrégats.

La détection d'agrégats est compatible avec les mesures suivantes:

Mesures standards : mesures de type SOMME, COUNT, MOYENNE, MIN et MAX
Mesures composites : mesures de type NUMBER, STRING, YESNO et DATE
Mesures distinctes approximatives : dialectes pouvant utiliser la fonctionnalité HyperLogLog.

La détection d'agrégats n'est pas disponible pour les mesures suivantes:

Mesures distinctes:étant donné que la distinction ne peut être calculée que sur des données atomiques et non agrégées, les mesures *_DISTINCT ne sont pas compatibles en dehors de ces méthodes approximatives qui utilisent HyperLogLog.
Mesures basées sur la cardinalité:comme pour les mesures distinctes, les médianes et les centiles ne peuvent pas être pré-agrégés et ne sont pas acceptés.

REMARQUE:Si vous connaissez une requête utilisateur potentielle dont les types de mesure ne sont pas compatibles avec Aggregate Awareness, vous pouvez créer une table agrégée correspondant exactement à une requête dans ce cas. Un tableau cumulé qui est une correspondance exacte de la requête peut être utilisé pour répondre à une requête avec des types de mesure qui ne seraient autrement pas pris en charge par la reconnaissance d'agrégats.

Précision des tables agrégées

Avant de créer des tableaux pour des combinaisons de dimensions et de mesures, vous devez déterminer des modèles d'utilisation et de sélection de champs communs pour créer des tableaux cumulés qui seront utilisés le plus souvent possible avec le plus d'impact possible. Notez que tous les champs utilisés dans la requête (qu'ils soient sélectionnés ou filtrés) doivent figurer dans le tableau cumulé pour que celui-ci puisse être utilisé dans la requête. Mais, comme indiqué précédemment, le tableau cumulé ne doit pas nécessairement être une correspondance exacte pour une requête à utiliser pour la requête. Vous pouvez traiter de nombreuses requêtes d'utilisateurs potentielles dans un seul tableau cumulé, tout en obtenant d'importants gains de performances.

Dans l'exemple d'identification des champs fréquemment utilisés dans les requêtes, deux dimensions (flights.depart_week et flights.carrier) sont sélectionnées très fréquemment, ainsi que deux mesures (flights.count et flights.cancelled_count). Par conséquent, il serait logique de créer une table agrégée qui utilise ces quatre champs. De plus, la création d'un seul tableau cumulé pour flights_by_week_and_carrier se traduira par une utilisation plus fréquente des tables agrégées que de deux tables agrégées différentes pour les tables flights_by_week et flights_by_carrier.

Voici un exemple de tableau cumulé que nous pouvons créer pour les requêtes portant sur les champs courants:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Vos utilisateurs métier, des preuves anecdotiques ainsi que les données de l'activité du système de Looker peuvent vous aider à prendre des décisions.

Trouver le juste équilibre entre applicabilité et performances

L'exemple suivant montre une requête d'exploration des champs "Flights Depart Week" (Semaine de départ des vols), "Flights Details Carrier" (Transporteur des détails des vols), "Flights Count" (Nombre de vols) et "Flights Cancelled Count" (Nombre d'annulations détaillés des vols) de la table globale flights_by_week_and_carrier:

Explorez la table de données avec quatre champs de la table agrégée "flights_by_week_and_carrier".

L'exécution de cette requête à partir de la table de base de données d'origine a pris 15,8 secondes et a analysé 38 millions de lignes sans jointure à l'aide d'Amazon Redshift. Le pivotement de la requête, qui serait une opération utilisateur normale, a pris 29,5 secondes.

Après avoir implémenté la table agrégée flights_by_week_and_carrier, la requête suivante a duré 7,2 secondes et a analysé 4 592 lignes. Cela représente une réduction de 99,98% de la taille de la table. Le pivotement de la requête a pris 9,8 secondes.

À partir de l'exploration de l'utilisation du champ Activité du système, nous pouvons voir à quelle fréquence nos utilisateurs ont inclus ces champs dans leurs requêtes. Dans cet exemple, flights.count a été utilisé 47 848 fois, flights.depart_week a été utilisé 18 169 fois, flights.cancelled_count a été utilisé 16 570 fois et flights.carrier a été utilisé 13 517 fois.

Même si nous avons estimé très simplement que 25% de ces requêtes ont utilisé les quatre champs de la manière la plus simple (sélection simple, pas de pivot), 3 379 x 8,6 secondes = 8 heures, 4 minutes dans le temps d'attente cumulé des utilisateurs éliminé.

REMARQUE:L'exemple de modèle utilisé ici est très basique. Ces résultats ne doivent pas servir de référence ni de cadre de référence pour votre modèle.

Après avoir appliqué exactement le même flux à notre modèle d'e-commerce order_items (l'exploration la plus utilisée sur l'instance), les résultats sont les suivants:

Source	Durée de la requête	Lignes analysées
Table basse	13,1 secondes	285 000
Table agrégée	5,1 secondes	138 000
Delta	8 secondes	147 000

Les champs utilisés dans la requête et le tableau cumulé suivant étaient brand, created_date, orders_count et total_revenue, avec deux jointures. Les champs avaient été utilisés 11 000 fois au total. Si l'on estime la même utilisation combinée d'environ 25%, l'économie globale pour les utilisateurs serait de 6 heures et 6 minutes (8 s x 2 750 = 22 000 s). La création de la table agrégée a pris 17,9 secondes.

Au vu de ces résultats, il est utile de prendre un moment pour prendre du recul et évaluer les retours que vous pourriez obtenir grâce aux éléments suivants:

Optimiser des modèles/explorations plus volumineux et plus complexes dont les performances sont "acceptables" et dont les performances peuvent être améliorées grâce à de meilleures pratiques de modélisation

Utiliser la reconnaissance d'agrégats pour optimiser des modèles plus simples utilisés plus fréquemment et peu performants

Vous constaterez que la rentabilité de vos efforts diminue lorsque vous essayez d'obtenir les dernières performances de Looker et de votre base de données. Vous devez toujours être conscient des attentes de base en termes de performances, en particulier de la part des utilisateurs professionnels, ainsi que des limites imposées par votre base de données (comme la simultanéité, les seuils de requêtes, le coût, etc.). Vous ne devez pas vous attendre à ce que la sensibilisation globale permette de surmonter ces limites.

De plus, lorsque vous concevez une table agrégée, n'oubliez pas que plus le nombre de champs est important, plus la table agrégée sera plus grande et plus lente. Des tableaux plus volumineux peuvent optimiser davantage de requêtes et donc être utilisés dans davantage de situations, mais les grands tableaux ne seront pas aussi rapides que des tableaux plus petits et plus simples.

Exemple :

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week,flights.distance, flights.arrival_week,flights.cancelled]
        measures: [cancelled_count, count, flights.average_distance, flights.total_distance]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Le tableau cumulé sera alors utilisé pour toute combinaison de dimensions affichée et pour toute mesure incluse. Ce tableau peut donc être utilisé pour répondre à de nombreuses requêtes utilisateur différentes. Mais pour utiliser cette table pour une simple requête SELECT de carrier et count,il faudrait analyser une table de 885 000 lignes. En revanche, la même requête ne nécessiterait une analyse de 4 592 lignes si le tableau était basé sur deux dimensions. La taille du tableau de 885 000 lignes correspond toujours à une réduction de 97 % (par rapport aux 38 millions de lignes précédentes), mais l'ajout d'une autre dimension augmente sa taille à 20 millions de lignes. Par conséquent, les rendements diminuent à mesure que vous incluez davantage de champs dans votre table agrégée afin de l'appliquer à un plus grand nombre de requêtes.

Créer des tableaux cumulés

Pour reprendre l'exemple de l'exploration Vols, que nous avons identifié comme pouvant être optimisée, la meilleure stratégie serait de créer trois tableaux cumulés différents pour celui-ci:

flights_by_week_and_carrier
flights_by_month_and_distance
flights_by_year

Le moyen le plus simple de créer ces tables agrégées consiste à obtenir le code LookML de la table agrégée à partir d'une requête d'exploration ou à partir d'un tableau de bord et à ajouter le code LookML aux fichiers de votre projet Looker.

Une fois que vous avez ajouté les tables agrégées à votre projet LookML et déployé les mises à jour en production, vos explorations exploitent les tables agrégées pour les requêtes de vos utilisateurs.

Persistance

Pour être accessibles à des fins de reconnaissance d'agrégats, les tableaux agrégés doivent être conservés dans votre base de données. Il est recommandé d'aligner la génération automatique de ces tables agrégées sur votre règle de mise en cache en utilisant les groupes de données. Pour une table agrégée, vous devez utiliser le même groupe de données que celui utilisé pour l'exploration associée. Si vous ne pouvez pas utiliser de groupes de données, une autre option consiste à utiliser le paramètre sql_trigger_value à la place. Une valeur générique basée sur la date pour sql_trigger_value est présentée ci-dessous:

sql_trigger_value: SELECT CURRENT_DATE() ;;

Vos tableaux cumulés seront créés automatiquement chaque jour à minuit.

Logique de période

Lorsque Looker crée une table agrégée, elle inclut des données jusqu'au moment où la table agrégée a été créée. Toute donnée qui a ensuite été ajoutée à la table de base dans la base de données serait normalement exclue des résultats d'une requête utilisant ce tableau cumulé.

Ce schéma montre la chronologie de réception et de consignation des commandes dans la base de données par rapport au moment où la table agrégée Orders a été créée. Deux commandes reçues aujourd'hui ne figurent pas dans le tableau cumulé Commandes, car elles ont été reçues après la création du tableau cumulé:

Chronologie des commandes reçues aujourd'hui et hier qui excluent deux points de données se produisant après la création du tableau cumulé.

Toutefois, Looker peut unifier des données actualisées vers la table agrégée lorsqu'un utilisateur interroge une période qui chevauche la table agrégée, comme illustré dans le même diagramme chronologique:

La requête de l'utilisateur inclut les points de données de la chronologie qui se sont produits après la création du tableau cumulé.

Looker peut UNION pour intégrer des données actualisées dans une table agrégée. Par conséquent, si un utilisateur filtre une période qui chevauche la fin de la table agrégée et de la table de base, les commandes reçues après la création de la table agrégée seront incluses dans les résultats de l'utilisateur. Consultez la page de documentation Reconnaissance d'agrégats pour obtenir plus de détails et connaître les conditions à remplir pour unir de nouvelles données et agréger les requêtes de table.

Résumé

Pour récapituler, l'implémentation de la notoriété globale repose sur trois étapes fondamentales:

Identifiez les opportunités pour lesquelles l'optimisation à l'aide de tableaux cumulés est appropriée et percutante.
Concevez des tableaux cumulés qui offriront une couverture maximale pour les requêtes courantes des utilisateurs, tout en restant suffisamment petits pour réduire suffisamment la taille de ces requêtes.
Créez les tables agrégées dans le modèle Looker, en associant la persistance de la table à celle du cache d'exploration.