Pour découvrir comment implémenter la notoriété globale, consultez notre page sur les bonnes pratiques concernant le tutoriel sur la notoriété globale.
Présentation
Looker utilise la logique de notoriété globale pour trouver la table la plus petite et la plus efficace disponible dans votre base de données afin d'exécuter une requête tout en préservant la précision.
Pour les tableaux très volumineux de votre base de données, les développeurs Looker peuvent créer des tableaux cumulés de données plus petits, regroupés par différentes combinaisons d'attributs. Les tableaux cumulés agissent comme des tables de consolidation ou récapitulatives que Looker peut utiliser pour les requêtes dans la mesure du possible, au lieu de la grande table d'origine. Lorsqu'elle est mise en œuvre de façon stratégique, la notoriété globale peut accélérer la requête moyenne par ordre de grandeur.
Par exemple, vous pouvez avoir une table de données à l'échelle du pétaoctet avec une ligne pour chaque commande passée sur votre site Web. À partir de cette base de données, vous pouvez créer un tableau cumulé avec vos totaux quotidiens des ventes. Si votre site Web reçoit 1 000 commandes par jour, votre tableau cumulé quotidien représentera chaque jour 999 lignes de moins que votre tableau d'origine. Vous pouvez créer un autre tableau cumulé avec des totaux de ventes mensuelles encore plus efficaces. Ainsi, si un utilisateur exécute une requête pour les ventes quotidiennes ou hebdomadaires, Looker utilisera la table des ventes quotidiennes totales. Si un utilisateur exécute une requête sur les ventes annuelles et que vous ne disposez pas d'une table agrégée annuelle, Looker utilisera la deuxième fonction la plus efficace : la table agrégée mensuelle des ventes dans cet exemple.
Looker répond aux questions de vos utilisateurs en utilisant les plus petits tableaux cumulés possible. Exemple :
- Pour une requête sur le total des ventes mensuelles, Looker utilise le tableau cumulé en fonction des ventes mensuelles (
sales_monthly_aggregate_table). - Pour une requête portant sur le total de chaque vente par jour, il n'existe pas de table agrégée avec cette précision. Looker obtient donc les résultats de la table de base de données d'origine (
orders_database). Toutefois, si vos utilisateurs exécutent souvent ce type de requête, vous pouvez facilement créer une table agrégée pour celle-ci. - Pour une requête concernant les ventes hebdomadaires, il n'existe pas de table agrégée hebdomadaire. Looker utilise donc la fonction suivante, à savoir la table agrégée basée sur les ventes quotidiennes (
sales_daily_aggregate_table).
Grâce à la logique de notoriété globale, Looker interroge la plus petite table agrégée possible pour répondre aux questions de vos utilisateurs. La table d'origine n'est utilisée que pour les requêtes nécessitant un niveau de précision plus précis que les tables agrégées.
Il n'est pas nécessaire de joindre les tables agrégées ni de les ajouter à une exploration distincte. Au lieu de cela, Looker ajuste la clause FROM de la requête Explorer pour accéder au meilleur tableau cumulé pour la requête. Cela signifie que vos forages sont conservés et que vos explorations peuvent être regroupées. Grâce à la notoriété globale, l'exploration 1 peut exploiter automatiquement les tableaux cumulés, tout en étudiant en profondeur des données précises si nécessaire.
Vous pouvez également exploiter des tables agrégées pour améliorer considérablement les performances des tableaux de bord, en particulier pour les cartes qui interrogent des ensembles de données très volumineux. Pour en savoir plus, consultez la section Obtenir le LookML global d'une table à partir d'un tableau de bord de la page de documentation sur le paramètre aggregate_table.
Ajouter des tables agrégées à votre projet
Pour que les données globales soient accessibles, les tables agrégées doivent être conservées dans la base de données. Étant donné que les tables agrégées sont un type de table dérivée persistante (PDT), elles ont les mêmes exigences que les tables dérivées persistantes. Pour en savoir plus, consultez la page de documentation Tableaux dérivés dans Looker.
Les développeurs de Looker peuvent créer des tables globales stratégiques qui réduisent le nombre de requêtes requises sur les grandes tables d'une base de données. Les tables agrégées doivent être conservées dans votre base de données afin d'être accessibles pour bénéficier d'une meilleure visibilité. Les tables agrégées sont donc un type de table dérivée persistante (PDT).
Un tableau cumulé est défini à l'aide du paramètre aggregate_table sous un paramètre explore dans votre projet LookML.
Voici un exemple de explore avec une table agrégée dans LookML:
explore: orders {
label: "Sales Totals"
join: order_items {
sql_on: ${orders.id} = ${order_items.id} ;;
}
aggregate_table: sales_monthly {
materialization: {
datagroup_trigger: orders_datagroup
}
query: {
dimensions: [created_month]
measures: [order_items.total_sales]
}
}
# other explore parameters
}
Pour créer une table agrégée, vous pouvez écrire le LookML à partir de zéro ou en obtenir un à partir d'une exploration ou d'un tableau de bord. Consultez la page de documentation sur le paramètre aggregate_table pour en savoir plus sur le paramètre aggregate_table et ses sous-paramètres.
Concevoir des tables agrégées
Pour qu'une requête Explorer utilise un tableau cumulé, celui-ci doit être en mesure de fournir des données précises. Looker peut utiliser un tableau cumulé pour une requête d'exploration si toutes les conditions suivantes sont remplies:
- Les champs de la requête Explorer constituent un sous-ensemble des champs du tableau cumulé (consultez la section Facteurs de champ de cette page). Ou, pour les périodes, les périodes de la requête Explorer peuvent être dérivées de celles de la table agrégée (consultez la section Facteurs horaires de cette page).
- La requête Explorer contient des types de mesures pris en charge par la notoriété globale (consultez la section Facteurs de type de mesure sur cette page), ou la requête Explorer comporte un tableau cumulé correspondant (consultez la section Créer des tableaux cumulés correspondant exactement aux requêtes Explorer de cette page).
- Le fuseau horaire de la requête Explorer correspond à celui utilisé par le tableau cumulé (consultez la section Facteurs de fuseau horaire de cette page).
- Les champs de la requête Explorer explorent les champs disponibles en tant que dimensions dans le tableau cumulé, ou chacun des filtres de la requête Explorer correspond à un filtre du tableau cumulé (consultez la section Facteurs de filtrage de cette page).
Pour vous assurer qu'une table agrégée peut fournir des données précises pour une requête "Explorer", vous pouvez simplement créer une table agrégée correspondant exactement à une requête Explorer. Pour en savoir plus, consultez la section Créer des tableaux cumulés correspondant exactement aux requêtes Explorer de cette page.
Facteurs de champ
Pour utiliser une requête Explorer, un tableau cumulé doit comporter toutes les dimensions et mesures nécessaires, y compris les champs utilisés pour les filtres. Si une requête Explorer contient une dimension ou une mesure qui ne se trouve pas dans un tableau cumulé, Looker ne pourra pas utiliser le tableau cumulé, mais le tableau de base.
Par exemple, si une requête regroupe les données en fonction des dimensions A et B, les regroupe à l'aide de la mesure C, puis les filtre en fonction de la dimension D, alors le tableau cumulé doit comporter au minimum les dimensions A, B et D pour les dimensions, et la mesure C pour la mesure.
La table agrégée peut également comporter d'autres champs, mais elle doit au moins comporter les champs de requête Explorer afin de permettre l'optimisation. La seule exception concerne les dimensions de période, car les périodes plus précises peuvent être déduites de périodes plus précises.
De ce fait, un tableau cumulé est spécifique à l'exploration dans laquelle il est défini. Un tableau cumulé défini sous une exploration ne sera pas utilisé pour les requêtes sur une autre exploration.
Facteurs de temps
La logique de notoriété agrégée de Looker peut déduire une période à partir d'une autre. Vous pouvez utiliser un tableau cumulé pour une requête, à condition que sa période soit plus précise (ou égale) que la requête Explorer. Par exemple, un tableau cumulé basé sur des données quotidiennes peut être utilisé pour une requête Explorer qui appelle d'autres périodes, comme des requêtes quotidiennes, mensuelles et annuelles, ou même des données de jour, de jour de l'année et de mois. Toutefois, vous ne pouvez pas utiliser de tableau cumulé annuel pour une requête Explorer qui appelle des données horaires, car les données de la table globale ne sont pas suffisamment précises pour la requête Explorer.
Il en va de même pour les sous-ensembles de périodes. Par exemple, si une table globale est filtrée pour les trois derniers mois et qu'un utilisateur interroge les données avec un filtre pour les deux derniers mois, Looker pourra utiliser la table agrégée pour cette requête.
De plus, la même logique s'applique aux requêtes avec des filtres de période: vous pouvez utiliser un tableau cumulé pour une requête avec un filtre de période, à condition que la période du tableau cumulé soit plus précise (ou égale) que celle utilisée dans la requête Explorer. Par exemple, vous pouvez utiliser un tableau cumulé avec une dimension de période quotidienne pour une requête d'exploration par jour, semaine ou mois.
Mesurer les facteurs de type
Pour qu'une requête Explorer utilise un tableau cumulé, les mesures correspondantes doivent fournir des données précises.
C'est pourquoi seuls certains types de mesures sont acceptés, comme décrit dans les sections suivantes:
- Mesures avec des types de mesures acceptés
- Mesures définies par des expressions SQL
- Mesures non définies avec
${TABLE} - Mesures approximatifs
Si une requête Explorer utilise un autre type de mesure, Looker utilisera la table d'origine, et non la table agrégée, pour renvoyer les résultats. Seule exception : si la requête Explorer correspond exactement à une requête de table globale, comme décrit dans la section Créer des tables agrégées correspondant exactement aux requêtes Explorer.
Sinon, Looker utilisera la table d'origine, et non la table agrégée, pour renvoyer les résultats.
Mesures avec des types de mesures compatibles
La notoriété globale peut être utilisée pour les requêtes d'exploration utilisant des mesures avec les types de mesures suivants:
Si une exploration joint plusieurs tables de base de données, Looker peut afficher les mesures de type
SUM,COUNTetAVERAGErespectivement en tant queSUM DISTINCT,COUNT DISTINCTetAVERAGE DISTINCT. Looker permet ainsi d'éviter les erreurs de calcul de fan-out, comme décrit dans la section Agrégations symétriques pour les explorations avec jointures de cette page.
Afin d'utiliser un tableau cumulé pour une requête Explorer, Looker doit être en mesure d'exploiter les mesures du tableau cumulé pour fournir des données précises dans la requête Explorer. Par exemple, une mesure avec type: sum peut être utilisée pour la notoriété globale, car vous pouvez additionner plusieurs sommes: vous pouvez ajouter un tableau cumulé de sommes hebdomadaires pour obtenir une somme mensuelle précise. De même, vous pouvez utiliser une mesure avec type: max, car vous pouvez utiliser un tableau cumulé des valeurs maximales quotidiennes pour déterminer la valeur hebdomadaire hebdomadaire exacte.
Dans le cas des mesures effectuées avec type: average, la notoriété globale est prise en charge, car Looker utilise la somme des données pour déduire les valeurs moyennes à partir des tables agrégées.
Mesures définies avec des expressions SQL
La notoriété globale peut également être utilisée avec des mesures définies avec des expressions dans le paramètre sql. Lorsqu'ils sont définis avec des expressions SQL, les types de mesures suivants sont également acceptés:
La notoriété globale est acceptée pour les mesures définies comme des combinaisons d'autres mesures, telles que:
measure: total_revenue_in_dollars {
type: number
sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}
La notoriété globale est également compatible avec les mesures pour lesquelles les calculs sont définis dans le paramètre sql, par exemple:
measure: wholesale_value {
type: number
sql: (${order_items.total_sale_price} * 0.60) ;;
}
La détection globale est acceptée pour les mesures pour lesquelles les opérations MIN, MAX et COUNT sont définies dans le paramètre sql, par exemple:
measure: most_recent_order_date {
type: date
sql: MAX(${users.created_at_raw})
}
La notoriété globale n'est disponible que pour les opérations
MIN(),MAX()etCOUNT(). Si vous souhaitez utiliser une mesure moyenne ou une somme dans votre tableau cumulé, vous pouvez créer une mesure detype: averageoutype: sum, qui sont compatibles avec la couverture globale.
Mesures faisant référence aux champs LookML
Lorsque des expressions sql sont utilisées dans les mesures, la notoriété globale accepte les types de références de champ suivants:
- Références au format
${view_name.field_name}, qui indique les champs dans d'autres vues - Références utilisant le format
${field_name}, qui indique des champs dans la même vue
La notoriété agrégée n'est pas compatible avec les mesures définies au format ${TABLE}.column_name, qui indique une colonne dans une table. Pour en savoir plus sur l'utilisation de références dans LookML, consultez la page de documentation Intégrer le langage SQL et la documentation sur les objets LookML.
Par exemple, une mesure définie avec ce paramètre sql ne serait pas acceptée dans un tableau cumulé, car elle utilise le format ${TABLE}.column_name:
measure: wholesale_value {
type: number
sql: (${TABLE}.total_sale_price * 0.60) ;;
}
Si vous souhaitez inclure cette mesure dans un tableau cumulé, vous pouvez créer une dimension définie au format ${TABLE}.column_name, puis créer une mesure qui référence la dimension, comme suit:
dimension: total_sale_price {
sql: (${TABLE}.total_sale_price) ;;
}
measure: wholesale_value {
type: number
sql: (${total_sale_price} * 0.60) ;;
}
Vous pouvez maintenant utiliser la mesure wholesale_value dans votre tableau cumulé.
Mesures qui représentent approximativement des nombres distincts
En général, les nombres distincts ne sont pas compatibles avec la notoriété globale, car vous ne pouvez pas obtenir de données précises si vous essayez de les cumuler. Par exemple, si vous comptabilisez les utilisateurs distincts sur un site Web, il est possible qu'un utilisateur ait visité le site deux fois, à trois semaines d'intervalle. Si vous essayez d'appliquer un tableau cumulé hebdomadaire pour obtenir le nombre mensuel d'utilisateurs distincts sur votre site Web, ces utilisateurs seront comptabilisés deux fois dans votre requête de décompte mensuel, et les données seront incorrectes.
Pour contourner ce problème, vous pouvez créer un tableau cumulé correspondant exactement à une requête Explorer, comme décrit dans la section Créer des tableaux cumulés correspondant exactement aux requêtes Explorer de cette page. Lorsque la requête Explorer et la requête Tableau sont identiques, des mesures de comptabilisation distinctes fournissent des données précises et peuvent donc être utilisées pour améliorer la notoriété globale.
Une autre option consiste à utiliser des approximations pour des nombres distincts. Pour les dialectes compatibles avec les sketches HyperLogLog, Looker peut exploiter l'algorithme HyperLogLog afin d'estimer le nombre approximatif de tables agrégées.
L'algorithme HyperLogLog présente une erreur d'environ 2 %. Pour le paramètre allow_approximate_optimization: yes, vos développeurs Looker doivent confirmer qu'ils peuvent utiliser des données approximatives pour effectuer la mesure, de sorte qu'elle puisse être calculée approximativement à partir de tableaux cumulés.
Pour en savoir plus et pour obtenir la liste des dialectes compatibles avec le décompte distinct à l'aide d'HyperLogLog, consultez la page de documentation sur le paramètre allow_approximate_optimization.
Facteurs de fuseau horaire
Dans de nombreux cas, les administrateurs de bases de données utilisent le fuseau horaire UTC pour les bases de données. Cependant, il est possible que de nombreux utilisateurs ne se trouvent pas dans le fuseau horaire UTC. Looker propose plusieurs options de conversion des fuseaux horaires, de sorte que vos utilisateurs reçoivent les résultats des requêtes dans leur propre fuseau horaire:
- Fuseau horaire des requêtes, qui s'applique à toutes les requêtes sur la connexion à la base de données. Si tous vos utilisateurs se trouvent dans le même fuseau horaire, vous pouvez définir un fuseau horaire unique pour les requêtes, afin de le faire passer de celui de la base de données à celui de la requête.
- Fuseaux horaires spécifiques à l'utilisateur : vous pouvez attribuer des fuseaux horaires individuels. Dans ce cas, les requêtes sont converties du fuseau horaire de la base de données vers celui de l'utilisateur individuel.
Pour en savoir plus sur ces options, consultez la page Utiliser les paramètres de fuseau horaire.
Ces concepts sont importants pour la compréhension de l'agrégation, car pour qu'un tableau cumulé soit utilisé pour une requête avec des dimensions de date ou des filtres de date, le fuseau horaire du tableau cumulé doit correspondre au paramètre de fuseau horaire utilisé pour la requête d'origine.
Les tables agrégées utilisent le fuseau horaire de la base de données si aucune valeur timezone n'est spécifiée. Votre connexion à la base de données utilisera également le fuseau horaire de la base de données si l'une des conditions suivantes est remplie:
- Votre base de données n'est pas compatible avec les fuseaux horaires.
- Le fuseau horaire des requêtes de votre connexion à la base de données est défini sur le même fuseau horaire que celui de la base de données.
- La connexion à votre base de données ne comporte aucun fuseau horaire de requête ni des fuseaux horaires spécifiques à l'utilisateur. Dans ce cas, la connexion à votre base de données utilisera le fuseau horaire de la base de données.
Si l'une de ces conditions est remplie, vous pouvez omettre le paramètre timezone pour vos tables agrégées.
Sinon, le fuseau horaire du tableau cumulé doit être défini de manière à correspondre aux requêtes possibles, de sorte qu'il soit plus susceptible d'être utilisé:
- Si la connexion à votre base de données utilise un seul fuseau horaire pour les requêtes, la valeur
timezonedu tableau cumulé doit correspondre à la valeur du fuseau horaire de la requête. - Si votre connexion à la base de données utilise des fuseaux horaires spécifiques à l'utilisateur, vous devez créer des tables agrégées identiques, chacune avec une valeur
timezonedifférente correspondant aux fuseaux horaires possibles de vos utilisateurs.
Looker ne peut pas utiliser un tableau cumulé pour une requête Explorer si le fuseau horaire du tableau cumulé ne correspond pas à celui de la requête Explorer. Si la connexion à votre base de données comprend des fuseaux horaires spécifiques à l'utilisateur, cela signifie que vous avez besoin d'une table globale distincte pour chacun d'entre eux.
Filtrer les facteurs
Soyez prudent lorsque vous ajoutez des filtres dans votre tableau cumulé. Les filtres appliqués à un tableau cumulé peuvent affiner les résultats jusqu'à ce que le tableau cumulé soit inutilisable. Imaginons par exemple que vous créiez une table agrégée pour le nombre de commandes quotidiennes, et que la table globale regroupe uniquement les commandes de lunettes de soleil provenant d'Australie. Si un utilisateur exécute une requête d'exploration pour connaître le nombre quotidien de commandes de lunettes de soleil dans le monde, Looker ne peut pas utiliser le tableau cumulé de cette requête, car ce tableau ne contient que les données pour l'Australie. Le tableau cumulé filtre les données de façon trop étroite pour que la requête Explorer puisse les utiliser.
Tenez également compte des filtres que vos développeurs Looker peuvent avoir intégrés à votre exploration, par exemple:
access_filters: applique des restrictions de données spécifiques à l'utilisateur.always_filter: obliger les utilisateurs à inclure un certain ensemble de filtres pour une requête Explorer. Les utilisateurs peuvent modifier la valeur de filtre par défaut de leur requête, mais ils ne peuvent pas supprimer complètement le filtre.conditionally_filter: définit un ensemble de filtres par défaut que les utilisateurs peuvent ignorer s'ils appliquent au moins un filtre d'une deuxième liste également défini dans l'exploration.
Ces types de filtres sont basés sur des champs spécifiques. Si votre exploration comporte ces filtres, vous devez inclure leurs champs dans le paramètre dimensions de aggregate_table.
Par exemple, voici une exploration avec un filtre d'accès basé sur le champ orders.region:
explore: orders {
access_filter: {
field: orders.region
user_attribute: region
}
}
Pour créer un tableau cumulé utilisé pour cette exploration, il doit inclure le champ sur lequel se base le filtre d'accès. Dans l'exemple suivant, le filtre d'accès est basé sur le champ orders.region et ce même champ est inclus en tant que dimension dans le tableau cumulé:
explore: orders {
access_filter: {
field: orders.region # <-- orders.region field
user_attribute: region
}
aggregate_table: sales_monthly {
materialization: {
datagroup_trigger: orders_datagroup
}
query: {
dimensions: [orders.created_day, orders.region] # <-- orders.region field
measures: [orders.total_sales]
timezone: America/Los_Angeles
}
}
}
Étant donné que la requête de tableau cumulé inclut la dimension orders.region, Looker peut filtrer les données du tableau agrégé de manière dynamique pour les faire correspondre au filtre de la requête Explorer. Par conséquent, Looker peut toujours utiliser le tableau cumulé pour les requêtes de l'exploration, même si celle-ci dispose d'un filtre d'accès.
Cela s'applique également aux requêtes Explorer qui utilisent une table dérivée native configurée avec bind_filters. Le paramètre bind_filters transmet les filtres spécifiés d'une requête d'exploration à la sous-requête de table dérivée native. Dans le cas de la visibilité globale, si votre requête Explorer nécessite une table dérivée native utilisant bind_filters, la requête Explorer ne peut utiliser une table agrégée que si tous les champs utilisés dans le paramètre bind_filters de la table dérivée native ont exactement les mêmes valeurs de filtre dans la requête Explorer que dans la table globale.
Créer des tableaux cumulés correspondant exactement aux requêtes Explorer
Pour vous assurer qu'une table agrégée peut être utilisée pour une requête Explorer, vous pouvez simplement créer une table agrégée correspondant exactement à la requête Explorer. Si la requête Explorer et le tableau cumulé utilisent les mêmes mesures, dimensions, filtres, fuseaux horaires et autres paramètres, les résultats du tableau cumulé s'appliqueront à la requête Explorer. Si un tableau cumulé correspond exactement à une requête Explorer, Looker peut utiliser des tableaux cumulés qui incluent n'importe quel type de mesure.
Vous pouvez créer une table agrégée à partir d'une page "Explorer" à l'aide de l'option Obtenir LookML du menu en forme de roue dentée d'une page Explorer. Vous pouvez également créer des correspondances exactes pour toutes les tuiles d'un tableau de bord en utilisant l'option Obtenir LookML dans le menu en forme de roue dentée d'un tableau de bord.
Déterminer la table agrégée utilisée pour une requête
Les utilisateurs disposant des autorisations see_sql peuvent utiliser les commentaires de l'onglet SQL d'une page "Explorer" pour voir le tableau cumulé utilisé pour une requête. Les commentaires de l'onglet SQL sont également affichés en mode Développement. Les développeurs peuvent ainsi tester de nouvelles tables agrégées pour voir comment Looker les utilise avant de les mettre en production.
Par exemple, en fonction du tableau cumulé mensuel affiché précédemment, vous pouvez accéder à la section "Explorer" et exécuter une requête pour obtenir le total des ventes annuelles. Vous pouvez ensuite cliquer sur l'onglet SQL pour afficher les détails de la requête créée par Looker. Si vous êtes en mode développement, Looker affiche des commentaires pour indiquer la table globale qu'il a utilisée pour la requête.
Grâce aux commentaires de l'onglet SQL, vous pouvez constater que Looker utilise la table agrégée sales_monthly pour cette requête, ainsi que des informations sur les raisons pour lesquelles d'autres tables agrégées n'ont pas été utilisées pour la requête:
-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date
Consultez la section Dépannage de cette page. Vous y trouverez des commentaires susceptibles de s'afficher dans l'onglet SQL ainsi que des suggestions pour les résoudre.
Estimations des économies de calculs pour la notoriété globale
Si votre connexion à la base de données est compatible avec les estimations de coûts et qu'une table agrégée peut être utilisée pour une requête, la fenêtre Explorer affiche les économies réalisées en calculant la table globale au lieu d'interroger la base de données directement. Les économies cumulées sur la notoriété sont affichées à gauche du bouton Exécuter dans l'onglet "Explorer" avant l'exécution de la requête:
Avant d'exécuter la requête, si vous souhaitez savoir quelle table globale sera utilisée pour la requête, vous pouvez cliquer sur l'onglet SQL, comme indiqué dans la section Déterminer quelle table globale est utilisée pour une requête de cette page de documentation.
Une fois la requête exécutée, la fenêtre Explorer affiche le tableau cumulé utilisé pour répondre à la requête à côté du bouton Exécuter.
Les économies agrégées de notoriété sont affichées pour les connexions à la base de données pour lesquelles les estimations de coûts sont activées. Pour en savoir plus, consultez la page Explorer les données dans Looker .
Looker réunit les nouvelles données dans vos tables agrégées
Pour les tables agrégées avec filtres de temps, Looker peut associer des données récentes à votre table agrégée. Vous disposez peut-être d'un tableau cumulé qui inclut les données des trois derniers jours, mais qui a peut-être été créé hier. Les informations du jour ne figurent pas dans le tableau cumulé. Vous ne devriez donc pas l'utiliser pour une requête "Explorer" sur les dernières informations quotidiennes.
Cependant, Looker peut toujours utiliser les données de cette table agrégée pour la requête, car il exécute une requête sur les données les plus récentes, puis associe ces résultats aux résultats de la table agrégée.
Looker peut unifier des données récentes avec les données globales de votre table dans les cas suivants:
- Le tableau cumulé comporte un filtre horaire.
- Le tableau cumulé inclut une dimension basée sur le même champ d'heure que le filtre de période.
Par exemple, le tableau cumulé suivant comporte une dimension basée sur le champ orders.created_date et un filtre de temps ("3 days") basé sur le même champ:
aggregate_table: sales_last_3_days {
query: {
dimensions: [orders.created_date]
measures: [order_items.total_sales]
filters: [orders.created_date: "3 days"] # <-- time filter
timezone: America/Los_Angeles
}
...
}
Si cette table agrégée a été créée hier, Looker récupère les données les plus récentes qui ne sont pas encore incluses dans la table agrégée, puis associe les nouveaux résultats aux résultats de la table agrégée. Vos utilisateurs auront ainsi accès aux données les plus récentes tout en optimisant les performances grâce à la notoriété globale.
En mode de développement, vous pouvez cliquer sur l'onglet SQL d'une page "Explorer" pour afficher la table agrégée utilisée par Looker pour la requête et sur l'instruction UNION utilisée par Looker pour importer les données plus récentes qui n'étaient pas incluses dans la table agrégée.
Actuellement, si Looker ne peut pas unifier les nouvelles données avec votre table agrégée, Looker utilisera les données existantes de la table agrégée.
Les tables d'agrégation doivent être conservées
Pour que vous puissiez y accéder, votre table doit être conservée dans votre base de données. La stratégie de persistance est spécifiée dans le paramètre materialization du tableau cumulé. Étant donné que les tables agrégées sont un type de table dérivée persistante (PDT), elles ont les mêmes exigences que les tables dérivées persistantes. Pour en savoir plus, consultez la page de documentation Tableaux dérivés dans Looker.
Vous pouvez créer des PDT incrémentiels dans votre projet si votre dialecte les accepte. Looker crée des tables dérivées persistantes incrémentielles en ajoutant des données récentes à la table au lieu de la recompiler entièrement. Étant donné que les tables agrégées sont elles-mêmes un type de PDT, vous pouvez également créer des tables agrégées incrémentielles. Pour en savoir plus, consultez la page PDT incrémentiel. Pour obtenir un exemple de tableau cumulé incrémentiel, consultez la page de documentation sur le paramètre increment_key.
Un utilisateur disposant de l'autorisation develop peut ignorer les paramètres de persistance et recréer toutes les tables agrégées d'une requête pour obtenir les données les plus récentes. Pour recréer les tables d'une requête, sélectionnez le bouton Explore actions (Explorer les actions) en forme de roue dentée, puis Rerived Tables & Run (Recompiler les tables dérivées et l'exécution) dans le menu Explore actions (Explorer les actions).
Vous devez attendre le chargement de la requête Explore avant que cette option soit disponible.
L'option Recompiler Tables & Run (Recompiler les tables dérivées et les exécutions) recompile les tables dérivées référencées dans la requête, ainsi que les tables dérivées dont dépendent les tables dans la requête. Cela inclut les tables agrégées, qui sont elles-mêmes un type de table dérivée persistante.
Si vous activez l'option Recompiler les tables dérivées et exécuter, la requête attend que les tables se recompilent avant de charger les résultats. Les requêtes des autres utilisateurs continueront d'utiliser les tables existantes. Une fois les tables persistantes régénérées, tous les utilisateurs s'en servent.
Pour en savoir plus sur l'option Recompiler des tables dérivées et l'exécution, consultez la page de documentation Tables dérivées dans Looker.
Dépannage
Comme décrit dans la section Déterminer quelle table globale est utilisée pour une requête, vous pouvez exécuter des requêtes en mode Développement dans l'onglet "Explorer" et cliquer sur l'onglet SQL pour afficher les commentaires concernant la table globale utilisée pour la requête (le cas échéant).
L'onglet SQL inclut également des commentaires expliquant pourquoi les tables agrégées n'ont pas été utilisées pour une requête, le cas échéant. Pour les tables agrégées non utilisées, le commentaire commence par:
Did not use [explore name]::[aggregate table name];
Par exemple, voici un commentaire expliquant pourquoi la table agrégée sales_daily définie dans la fonction order_items "Explorer" n'a pas été utilisée pour une requête:
-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.
Dans ce cas, les filtres de la requête ont empêché l'utilisation de la table agrégée.
Le tableau suivant présente d'autres raisons possibles pour lesquelles un tableau cumulé ne peut pas être utilisé, ainsi que les étapes à suivre pour améliorer sa facilité d'utilisation.
| Motif de la non-utilisation du tableau cumulé |
Explication et étapes possibles |
|---|---|
| Aucun champ de ce type dans l'exploration. | Une erreur de type de validation LookML s'est produite. Cela est probablement dû au fait que la table agrégée n'est pas correctement définie ou qu'une faute de frappe apparaît dans le LookML pour votre table agrégée. Un nom de champ incorrect est probablement à l'origine d'une irrégularité. Pour résoudre ce problème, vérifiez que les dimensions et mesures du tableau cumulé correspondent aux noms de champs indiqués dans l'exploration. Consultez la page de documentation sur le paramètre aggregate_table pour savoir comment définir une table agrégée. |
| Le tableau cumulé ne contient pas les champs suivants dans la requête. | Pour utiliser une requête Explorer, un tableau cumulé doit comporter toutes les dimensions et mesures nécessaires, y compris les champs utilisés pour les filtres. Si une requête Explorer contient une dimension ou une mesure qui ne se trouve pas dans un tableau cumulé, Looker ne pourra pas utiliser le tableau cumulé, mais le tableau de base. Pour en savoir plus, consultez la section Facteurs de champ de cette page. La seule exception concerne les dimensions de période, car les périodes plus précises peuvent être déduites de périodes plus précises. Pour résoudre ce problème, vérifiez que les champs de la requête Explorer sont inclus dans la définition du tableau cumulé. |
| La requête contenait les filtres suivants qui n'étaient pas inclus en tant que champs ou qui ne correspondaient pas exactement aux filtres du tableau cumulé. | Les filtres de la requête Explorer empêchent Looker d'utiliser la table agrégée. Pour résoudre ce problème, vous pouvez effectuer l'une des opérations suivantes :
|
| La requête contient les mesures suivantes qui ne peuvent pas être regroupées. | La requête contient un ou plusieurs types de mesures qui ne sont pas compatibles avec la notoriété globale, tels que nombre distinct, médiane ou centile. Pour résoudre ce problème, vérifiez le type de chaque mesure dans la requête et assurez-vous qu'il s'agit de l'un des types de mesures compatibles. De plus, si votre exploration comporte des jointures, vérifiez que vos mesures ne sont pas converties en mesures distinctes (agrégations symétriques) via des jointures étendues. Pour en savoir plus, consultez la section Agrégations symétriques pour les explorations avec jointures de cette page. |
| Un autre tableau cumulé était plus adapté à l'optimisation. | Il y avait plusieurs tables agrégées viables pour la requête, et Looker a trouvé une table agrégée plus adaptée. Dans ce cas, aucune action n'est requise de votre part. |
Looker n'a effectué aucun regroupement (en raison d'un paramètre primary_key ou cancel_grouping_fields). La requête ne peut donc pas être regroupée. |
La requête fait référence à une dimension qui l'empêche d'avoir une clause GROUP BY. Par conséquent, Looker ne peut utiliser aucune table agrégée pour la requête.
Pour résoudre ce problème, vérifiez que les paramètres primary_key de la vue et cancel_grouping_fields de l'exploration sont correctement configurés. |
| La table agrégée contient des filtres qui ne figurent pas dans la requête. | Le tableau cumulé comporte un filtre non temporel qui ne figure pas dans la requête. Pour résoudre ce problème, vous pouvez supprimer le filtre du tableau cumulé. Pour en savoir plus, consultez la section Filtrer les facteurs de cette page. |
Un champ est défini comme étant un filtre uniquement dans la requête Explorer, mais il est répertorié dans le paramètre dimensions du tableau cumulé. |
Le paramètre dimensions du tableau cumulé répertorie un champ défini uniquement en tant que champ filter dans la requête Explorer.Pour résoudre ce problème, supprimez le champ de la liste dimensions du tableau cumulé. Si ce champ est nécessaire pour la table agrégée, ajoutez-le à la liste filters dans la requête associée. |
| L'optimiseur ne peut pas déterminer la raison pour laquelle la table agrégée n'a pas été utilisée. | Ce commentaire est réservé aux cas d'angle. Si vous voyez ceci pour une requête Explorer souvent utilisée, vous pouvez créer un tableau cumulé correspondant exactement à la requête Explorer. Vous pouvez facilement obtenir un LookML agrégé de table à partir d'une exploration, comme décrit sur la page des paramètres aggregate_table. |
Éléments à prendre en compte
Agrégations symétriques des explorations avec jointures
Il est important de noter que, dans l'exploration, qui joint plusieurs tables de base de données, Looker peut afficher les mesures de type SUM, COUNT et AVERAGE respectivement en tant que SUM DISTINCT, COUNT DISTINCT et AVERAGE DISTINCT. Looker procède ainsi pour éviter les erreurs de calcul de fan-out. Par exemple, une mesure count est affichée en tant que type de mesure count_distinct. Cela permet d'éviter les erreurs de calcul des fans lors des jointures. Cette fonction est intégrée à la fonctionnalité d'agrégation symétrique de Looker. Pour en savoir plus sur cette fonctionnalité de Looker, consultez la page Bonnes pratiques concernant les agrégations symétriques.
La fonctionnalité d'agrégation symétrique empêche les erreurs de calcul, mais peut également empêcher l'utilisation de vos tables agrégées dans certains cas. Il est donc important de comprendre ces informations.
Pour les types de mesures compatibles avec la notoriété globale, cela s'applique à sum, count et average. Looker affichera ces types de mesures sous la forme DISTINCT si:
- La mesure provient de la vue "un" d'une jointure plusieurs à un ou un à plusieurs.
- La mesure provient de l'une ou l'autre des vues associées à une jointure plusieurs à plusieurs.
Pour en savoir plus sur ces types de jointures, consultez la page de documentation sur le paramètre relationship.
Si votre table agrégée n'est pas utilisée pour cette raison, vous pouvez créer une table agrégée correspondant exactement à une requête d'exploration afin d'utiliser ces types de mesures pour une exploration avec des jointures. Pour en savoir plus, consultez la section Créer des tableaux cumulés correspondant exactement aux requêtes Explorer de cette page.
De plus, si vous disposez d'un dialecte SQL compatible avec HyperLogLog, vous pouvez ajouter le paramètre allow_approximate_optimization: yes à la mesure. Lorsqu'une mesure du nombre est définie avec allow_approximate_optimization: yes, Looker peut l'utiliser pour la notoriété globale, même si elle s'affiche en tant que compteur distinct.
Pour en savoir plus, consultez la page de documentation sur le paramètre allow_approximate_optimization et consultez la liste des dialectes SQL compatibles avec les croquis HyperLogLog.
Compatibilité avec Dialecte pour une notoriété globale
La possibilité d'utiliser la fonction Aggregate Awareness dépend du dialecte de base de données de votre connexion Looker. Dans la dernière version de Looker, les dialectes suivants sont compatibles avec la notoriété globale:
L'ancien SQL Google BigQuery permet de prendre en compte les données globales, mais pas d'associer les données récentes aux données de votre table agrégée.
Dialecte compatible avec la création incrémentielle de tables agrégées
Pour que Looker accepte les tables agrégées incrémentielles dans votre projet Looker, votre dialecte de base de données doit également les accepter. Le tableau suivant présente les dialectes compatibles avec les tables agrégées et la génération incrémentielle de tables dérivées persistantes dans la dernière version de Looker: