Visibilité globale

Présentation

Looker utilise la logique de sensibilisation agrégée pour trouver la table la plus petite et la plus efficace disponible dans votre base de données pour exécuter une requête tout en maintenant la justesse.

Pour les très grandes tables de votre base de données, les développeurs Looker peuvent créer des tables agrégées de données plus petites, regroupées par différentes combinaisons d'attributs. Les tables agrégées agissent comme des tables d'ensemble ou des tables récapitulatives que Looker peut utiliser pour des requêtes dans la mesure du possible, à la place de la grande table d'origine. Lorsqu'elle est implémentée de manière stratégique, la détection agrégée peut accélérer la requête moyenne d'un ordre de grandeur.

Par exemple, vous pouvez disposer d'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 de ventes quotidiennes. Si votre site Web reçoit 1 000 commandes par jour, votre tableau cumulé quotidien représentera 999 lignes en moins par jour par rapport à votre tableau d'origine. Vous pouvez créer un autre tableau cumulé avec les totaux des ventes mensuelles qui sera encore plus efficace. Ainsi, si un utilisateur exécute une requête sur les ventes quotidiennes ou hebdomadaires, Looker utilise le tableau du total des ventes quotidiennes. Si un utilisateur exécute une requête sur les ventes annuelles et que vous n'avez pas de table agrégée annuelle, Looker utilisera la deuxième meilleure chose qui est la table agrégée des ventes mensuelles dans cet exemple.

Dans la mesure du possible, Looker répond aux questions de vos utilisateurs avec les plus petites tables agrégées. Exemple :

  • Pour une requête sur les ventes mensuelles totales, Looker utilise le tableau cumulé basé sur les ventes mensuelles (sales_monthly_aggregate_table).
  • Pour une requête sur le total de chaque vente d'une journée, il n'existe pas de table agrégée avec cette précision. Looker récupère donc les résultats de requête à partir 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 créer une table agrégée pour celle-ci.
  • Pour une requête sur les ventes hebdomadaires, il n'existe pas de table agrégée hebdomadaire. Looker utilise donc la deuxième meilleure option, à savoir le tableau cumulé basé sur les ventes quotidiennes (sales_daily_aggregate_table).

En utilisant la logique de prise en compte de l'agrégation, Looker interrogera la plus petite table agrégée possible pour répondre aux questions de vos utilisateurs. La table d'origine ne serait utilisée que pour les requêtes nécessitant une précision plus fine que celle fournie par les tableaux cumulés.

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 de manière dynamique la clause FROM de la requête d'exploration pour accéder au tableau agrégé le plus adapté à la requête. Ainsi, vos analyses sont gérées et peuvent être regroupées. Grâce à la reconnaissance d'agrégats, une exploration peut automatiquement exploiter les tableaux cumulés, tout en continuant à explorer en profondeur des données précises si nécessaire.

Vous pouvez également exploiter les tables agrégées pour améliorer considérablement les performances des tableaux de bord, en particulier pour les vignettes qui interrogent de vastes ensembles de données. Pour en savoir plus, consultez la section Obtenir le code LookML d'une table agrégée à partir d'un tableau de bord sur la page de documentation du paramètre aggregate_table.

Ajouter des tableaux cumulés à votre projet

Les développeurs Looker peuvent créer des tables agrégées stratégiques qui réduiront le nombre de requêtes requises sur les grands tableaux d'une base de données. Les tables agrégées doivent être persistées dans votre base de données afin qu'elles soient accessibles pour la reconnaissance d'agrégats. Les tables agrégées sont donc un type de table dérivée persistante (PDT).

Une table agrégée est définie à l'aide du paramètre aggregate_table sous un paramètre explore dans votre projet LookML.

Voici un exemple de propriété 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 code LookML à partir de zéro, ou vous pouvez obtenir le code LookML de la table agrégée à partir d'une exploration ou d'un tableau de bord. Consultez la page de documentation du paramètre aggregate_table pour en savoir plus sur le paramètre aggregate_table et ses sous-paramètres.

Concevoir des tableaux cumulés

Pour qu'une requête d'exploration puisse utiliser une table agrégée, cette table doit fournir des données précises pour la requête d'exploration. Looker peut utiliser une table agrégée pour une requête d'exploration si toutes les conditions suivantes sont remplies:

  • Les champs de la requête d'exploration sont un sous-ensemble des champs de la table agrégée (consultez la section Facteurs de champ sur cette page). Pour les périodes, celles de la requête d'exploration peuvent également être dérivées des périodes du tableau cumulé (voir la section Facteurs temporels sur cette page).
  • La requête d'exploration contient des types de mesures compatibles avec Aggregate Awareness (consultez la section Mesurer les facteurs de type de cette page) ou la requête d'exploration contient une table agrégée correspondant exactement (consultez la section Créer des tables agrégées correspondant exactement aux requêtes d'exploration sur cette page).
  • Le fuseau horaire de la requête d'exploration correspond à celui utilisé par le tableau cumulé (consultez la section Facteurs de fuseau horaire sur cette page).
  • Les filtres de la requête d'exploration font référence à des champs disponibles en tant que dimensions dans le tableau cumulé, ou chacun des filtres de la requête d'exploration correspond à un filtre du tableau cumulé (consultez la section Facteurs de filtre sur cette page).

Pour s'assurer qu'un tableau cumulé peut fournir des données précises pour une requête d'exploration, vous pouvez créer un tableau cumulé qui correspond exactement à une requête d'exploration. Pour en savoir plus, consultez la section Créer des tables agrégées correspondant exactement aux requêtes d'exploration de cette page.

Facteurs de champ

Pour être utilisée dans une requête d'exploration, une table agrégée doit comporter toutes les dimensions et mesures nécessaires pour cette requête, y compris les champs utilisés pour les filtres de cette requête. Si une requête d'exploration contient une dimension ou une mesure qui ne figure pas dans une table agrégée, Looker ne peut pas utiliser la table agrégée et utilisera la table de base à la place.

Par exemple, si une requête regroupe par dimensions A et B, effectue des agrégations par mesure C et filtre la dimension D, le tableau cumulé doit comporter au minimum A, B et D comme dimensions et C comme mesure.

La table agrégée peut également comporter d'autres champs, mais elle doit au moins contenir les champs de requête d'exploration pour être viable pour l'optimisation. La seule exception concerne les dimensions de période, car des périodes plus précises peuvent être dérivées de périodes plus précises.

En raison de ces considérations relatives aux champs, une table agrégée est spécifique à l'exploration dans laquelle elle est définie. Un tableau cumulé défini dans une exploration ne sera pas utilisé pour les requêtes d'une autre exploration.

Facteurs liés aux délais

La logique de sensibilisation globale de Looker peut déduire un délai d'un autre. Une table agrégée peut être utilisée pour une requête à condition que la période de la table agrégée ait une précision plus fine (ou égale) que la requête d'exploration. Par exemple, une table agrégée basée sur des données quotidiennes peut être utilisée pour une requête d'exploration qui appelle d'autres périodes, comme des requêtes sur des données quotidiennes, mensuelles et annuelles, ou même des données du jour du mois, du jour de l'année et de la semaine de l'année. Toutefois, une table agrégée annuelle ne peut pas être utilisée pour une requête d'exploration qui appelle des données horaires, car les données de la table agrégée n'ont pas une précision suffisante pour la requête d'exploration.

Il en va de même pour les sous-ensembles de périodes. Par exemple, si vous disposez d'une table agrégée filtrée sur 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 filtres de période: une table agrégée peut être utilisée pour une requête avec un filtre de période, à condition que la période de la table agrégée ait une granularité plus fine (ou égale) que le filtre de période utilisé dans la requête d'exploration. Par exemple, une table agrégée avec une dimension de période quotidienne peut être utilisée pour une requête d'exploration qui filtre par jour, semaine ou mois.

Facteurs de type de mesure

Pour qu'une requête d'exploration puisse utiliser une table agrégée, les mesures de la table agrégée doivent pouvoir fournir des données précises pour la requête d'exploration.

Pour cette raison, seuls certains types de mesures sont acceptés, comme décrit dans les sections suivantes:

Si une requête d'exploration utilise un autre type de mesure, Looker utilise la table d'origine, et non la table agrégée, pour renvoyer les résultats. Seule exception : la requête d'exploration correspond exactement à une requête de table agrégée, comme décrit dans la section Créer des tables agrégées correspondant exactement aux requêtes d'exploration.

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 reconnaissance d'agrégats peut être utilisée pour les requêtes d'exploration qui utilisent des mesures avec les types de mesures suivants:

Pour utiliser une table agrégée pour une requête d'exploration, Looker doit pouvoir agir sur les mesures de la table agrégée afin de fournir des données précises dans la requête d'exploration. Par exemple, une mesure avec type: sum peut être utilisée pour la notoriété agrégée, car vous pouvez additionner plusieurs sommes: un tableau cumulé de sommes hebdomadaires peut être additionné pour obtenir une somme mensuelle précise. De même, une mesure avec type: max peut être utilisée, car un tableau cumulé des limites quotidiennes peut être utilisé pour trouver la limite hebdomadaire exacte.

Pour les mesures avec type: average, la détection d'agrégats est prise en charge, car Looker utilise les données de somme et de nombre pour déduire avec précision les valeurs moyennes à partir de tables agrégées.

Mesures définies avec des expressions SQL

Vous pouvez également utiliser la reconnaissance d'agrégats 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 mesure suivants sont également acceptés:

La reconnaissance d'agrégats est compatible avec les mesures définies comme des combinaisons d'autres mesures, comme dans cet exemple:

measure: total_revenue_in_dollars {
  type: number
  sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}

La reconnaissance d'agrégats est également prise en charge pour les mesures où les calculs sont définis dans le paramètre sql, comme cette mesure:

measure: wholesale_value {
  type: number
    sql: (${order_items.total_sale_price} * 0.60) ;;
}

Enfin, la détection d'agrégats est prise en charge pour les mesures où les opérations MIN, MAX et COUNT sont définies dans le paramètre sql, comme dans cette mesure:

measure: most_recent_order_date {
  type: date
  sql: MAX(${users.created_at_raw})
}

Mesures faisant référence aux champs LookML

Lorsque des expressions sql sont utilisées dans des mesures, Aggregate Awareness accepte les types suivants de références de champ:

  • Références utilisant le format ${view_name.field_name}, qui indique les champs dans les autres vues
  • Références au format ${field_name}, qui indiquent les champs dans la même vue

La reconnaissance d'agrégats n'est pas compatible avec les mesures définies à l'aide du format ${TABLE}.column_name, qui indique une colonne dans une table. Pour en savoir plus sur l'utilisation des références dans LookML, consultez la page de documentation Intégration de SQL et référence aux 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 proches des nombres distincts

En général, les nombres distincts ne sont pas compatibles avec la reconnaissance agrégée, car vous ne pouvez pas obtenir de données précises si vous essayez de regrouper des nombres distincts. Par exemple, si vous comptez les utilisateurs distincts d'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, cet utilisateur sera comptabilisé deux fois dans votre requête de décompte mensuel distinct. Les données seront alors incorrectes.

Pour contourner ce problème, vous pouvez créer une table agrégée correspondant exactement à une requête d'exploration, comme décrit dans la section Créer des tables agrégées correspondant exactement aux requêtes d'exploration de cette page. Lorsque la requête d'exploration et une requête de table agrégée sont identiques, les mesures de décompte distinctes fournissent des données précises, et peuvent donc être utilisées pour la reconnaissance d'agrégats.

Une autre option consiste à utiliser des approximations pour des décomptes distincts. Pour les dialectes compatibles avec les synthèses HyperLogLog, Looker peut exploiter l'algorithme HyperLogLog pour estimer le nombre de nombres distincts de tables agrégées.

On sait que l'algorithme HyperLogLog génère une erreur d'environ 2 %. Le paramètre allow_approximate_optimization: yes exige que vos développeurs Looker acceptent d'utiliser des données approximatives pour la mesure afin que celle-ci puisse être calculée approximativement à partir de tables agrégées.

Consultez la page de documentation du paramètre allow_approximate_optimization pour en savoir plus et pour obtenir la liste des dialectes prenant en charge la méthode COUNT DISTINCT à l'aide de HyperLogLog.

Facteurs de fuseau horaire

Dans de nombreux cas, les administrateurs de bases de données utilisent UTC comme fuseau horaire 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 pour convertir les fuseaux horaires afin que vos utilisateurs obtiennent les résultats des requêtes dans leur propre fuseau horaire:

  • Fuseau horaire de la requête : paramètre 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 de requête unique afin que toutes les requêtes soient converties du fuseau horaire de la base de données dans celui de la requête.
  • Fuseaux horaires spécifiques à l'utilisateur, où les utilisateurs peuvent être attribués et sélectionner des fuseaux horaires individuellement. Dans ce cas, les requêtes sont converties du fuseau horaire de la base de données dans celui de l'utilisateur.

Pour en savoir plus sur ces options, consultez la page de documentation Utiliser les paramètres de fuseau horaire.

Ces concepts sont importants pour comprendre la reconnaissance d'agrégations, car, pour qu'une table agrégée puisse être utilisée pour une requête avec des dimensions de date ou des filtres de date, le fuseau horaire de la table agrégée 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 ne prend pas en charge les fuseaux horaires.
  • Le fuseau horaire de la requête de votre connexion à la base de données est défini sur le même fuseau horaire de la base de données.
  • Votre connexion à la base de données n'a pas de fuseau horaire spécifié pour la requête, ni de fuseau horaire propre à l'utilisateur. Dans ce cas, votre connexion à la 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 tableaux cumulés.

Sinon, le fuseau horaire de la table agrégée doit être défini pour correspondre aux requêtes possibles, afin que la table agrégée ait plus de chances d'être utilisée:

  • Si votre connexion à la base de données utilise un seul fuseau horaire de requête, vous devez faire correspondre la valeur timezone de votre tableau cumulé avec la valeur du fuseau horaire de la requête.
  • Si votre connexion à la base de données utilise des fuseaux horaires spécifiques aux utilisateurs, vous devez créer des tableaux cumulés identiques, chacun avec une valeur timezone différente pour correspondre aux différents fuseaux horaires de vos utilisateurs.

Facteurs de filtrage

Soyez prudent lorsque vous incluez des filtres dans votre tableau cumulé. Les filtres appliqués à un tableau cumulé peuvent limiter les résultats au point où le tableau cumulé est inutilisable. Par exemple, imaginons que vous créiez un tableau cumulé pour le nombre de commandes quotidiennes, et des filtres de tableau cumulé pour uniquement les commandes de lunettes de soleil en provenance d'Australie. Si un utilisateur exécute une requête d'exploration pour le nombre quotidien de commandes de lunettes de soleil dans le monde entier, Looker ne peut pas utiliser la table agrégée pour cette requête d'exploration, car la table agrégée ne contient que les données pour l'Australie. Le tableau cumulé filtre les données de manière trop précise pour être utilisées par la requête d'exploration.

Tenez également compte des filtres que vos développeurs Looker ont pu intégrer à votre exploration, tels que:

  • access_filters: applique des restrictions de données spécifiques à l'utilisateur.
  • always_filter: oblige les utilisateurs à inclure un certain ensemble de filtres pour une requête d'exploration. 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 remplacer s'ils appliquent au moins un filtre d'une deuxième liste également définie 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é qui sera utilisé pour cette exploration, le tableau cumulé doit inclure le champ sur lequel le filtre d'accès est basé. 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 table agrégée inclut la dimension orders.region, Looker peut filtrer dynamiquement les données de la table agrégée pour qu'elles correspondent au filtre de la requête d'exploration. Par conséquent, Looker peut toujours utiliser la table agrégée 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 d'exploration 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 détection d'agrégations, si votre requête d'exploration nécessite une table dérivée native utilisant bind_filters, la requête d'exploration 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 d'exploration que dans la table agrégée.

Créer des tables agrégées correspondant exactement aux requêtes d'exploration

Pour vous assurer qu'une table agrégée peut être utilisée pour une requête d'exploration, vous pouvez créer une table agrégée correspondant exactement à la requête d'exploration. Si la requête d'exploration et la table agrégée utilisent les mêmes mesures, dimensions, filtres, fuseaux horaires et autres paramètres, les résultats du tableau cumulé s'appliqueront par définition à la requête d'exploration. Si une table agrégée correspond exactement à une requête d'exploration, Looker peut utiliser des tables agrégées incluant n'importe quel type de mesure.

Vous pouvez créer une table agrégée à partir d'une exploration en utilisant l'option Obtenir LookML du menu Outils d'une exploration. Vous pouvez également créer des correspondances exactes pour toutes les vignettes d'un tableau de bord à l'aide de l'option Obtenir LookML du menu Outils d'un tableau de bord.

Déterminer quelle table agrégée est utilisée pour une requête

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. Les commentaires de l'onglet SQL s'affichent également en mode Développement. Les développeurs peuvent ainsi tester de nouvelles tables agrégées pour voir comment Looker les utilise avant que vous les mettiez en production.

Par exemple, en vous basant sur l'exemple de tableau cumulé mensuel présenté précédemment, vous pouvez accéder à l'exploration et exécuter une requête pour obtenir les totaux 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 agrégée utilisée pour la requête.

Les commentaires suivants de l'onglet SQL indiquent que Looker utilise la table agrégée sales_monthly pour cette requête. Nous obtenons également des informations sur la raison pour laquelle 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 pour connaître les éventuels commentaires susceptibles de s'afficher dans l'onglet SQL et des suggestions de résolution.

Estimations des économies de calcul pour la notoriété agrégée

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" indiquera les économies de calcul liées à l'utilisation de la table agrégée au lieu d'interroger directement la base de données. Les économies agrégées liées à la prise de conscience sont affichées à côté du bouton Run (Exécuter) dans une exploration avant l'exécution de la requête.

Avant d'exécuter la requête, si vous souhaitez voir quelle table agrégée sera utilisée pour la requête, vous pouvez cliquer sur l'onglet SQL, comme décrit dans la section Déterminer quelle table agrégée 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 la table agrégée utilisée pour répondre à la requête, à côté du bouton Exécuter.

Les économies agrégées liées à la notoriété sont affichées pour les connexions de base de données pour lesquelles les estimations de coûts sont activées. Pour en savoir plus, consultez la page de documentation Explorer les données dans Looker .

Looker associe de nouvelles données à vos tables agrégées

Pour les tables agrégées avec des filtres temporels, Looker peut unifier les nouvelles données dans votre table agrégée. Vous avez peut-être un tableau cumulé qui inclut les données des trois derniers jours, mais ce tableau cumulé peut avoir été créé hier. Les informations du jour seraient manquantes dans le tableau cumulé. Vous ne vous attendez donc pas à l'utiliser pour une requête d'exploration sur les dernières informations quotidiennes.

Toutefois, Looker peut toujours utiliser les données de cette table agrégée pour la requête, car Looker exécute une requête sur les données les plus récentes, puis unifie ces résultats dans les résultats de la table agrégée.

Looker peut unir des données récentes avec celles de votre table agrégée dans les cas suivants:

  • Le tableau cumulé a un filtre temporel.
  • Le tableau cumulé inclut une dimension basée sur le même champ d'heure que le filtre de temps.

Par exemple, le tableau cumulé suivant comporte une dimension basée sur le champ orders.created_date, ainsi qu'un filtre de période ("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érera les données les plus récentes qui ne sont pas encore incluses dans la table agrégée, puis unira les nouveaux résultats avec ceux de la table agrégée. Cela signifie que vos utilisateurs obtiendront les données les plus récentes tout en optimisant les performances à l'aide de la notoriété globale.

Si vous êtes en mode Développement, vous pouvez cliquer sur l'onglet SQL d'une exploration pour afficher la table agrégée utilisée par Looker pour la requête et l'instruction UNION utilisée par Looker pour importer des données plus récentes qui n'étaient pas incluses dans la table agrégée.

Les tables agrégées doivent être persistantes

Pour être accessible à Aggregate Awareness, votre table agrégée doit être persistée dans votre base de données. La stratégie de persistance est spécifiée dans le paramètre materialization du tableau cumulé. Les tables agrégées étant un type de table dérivée persistante (PDT), elles ont les mêmes exigences que les tables PDT. Pour en savoir plus, consultez la page de documentation Tables dérivées dans Looker.

Vous pouvez créer des PDT incrémentielles dans votre projet si votre dialecte le permet. Looker génère des augmentations de tables PDT en ajoutant de nouvelles données à la table, au lieu de régénérer la table dans son intégralité. Étant donné que les tableaux cumulés sont eux-mêmes un type de table PDT, vous pouvez également créer des tableaux cumulés incrémentiels. Reportez-vous à la page de documentation sur l'augmentation de tables PDT pour plus d'informations. Consultez la page de documentation du paramètre increment_key pour obtenir un exemple de table agrégée incrémentielle.

Un utilisateur disposant de l'autorisation develop peut remplacer les paramètres de persistance et recréer tous les tableaux cumulés pour une requête afin d'obtenir les données les plus récentes. Pour recréer les tables d'une requête, sélectionnez l'option Rebuild Derived Tables & Run (Recompiler les tables dérivées et exécuter les tables) dans le menu Outils Explorer les actions.

Vous devez attendre le chargement de la requête Explore avant que cette option soit disponible.

L'option Rebuild Derived Tables & Run (Recompiler les tables dérivées et exécuter les tables dérivées) permet de recompiler toutes les tables dérivées référencées dans la requête, ainsi que toutes les tables dérivées dont elles dépendent. Cela inclut les tables agrégées, qui sont elles-mêmes un type de table dérivée persistante.

Pour l'utilisateur qui lance l'option Rebuild Derived Tables & Run (Recompiler les tables dérivées et exécuter les tables), la requête attendra que les tables soient recréées 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.

Consultez la page de documentation Tables dérivées dans Looker pour en savoir plus sur l'option Recompiler les tables dérivées et exécuter.

Dépannage

Comme décrit dans la section Déterminer quelle table agrégée est utilisée pour une requête, si vous êtes en mode Développement, vous pouvez exécuter des requêtes sur l'exploration et cliquer sur l'onglet SQL pour afficher les commentaires sur la table agrégée 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 tableaux cumulés qui ne sont pas utilisés, le commentaire commencera 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 l'exploration order_items 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 empêchaient l'utilisation du tableau cumulé.

Le tableau suivant montre d'autres raisons possibles pour lesquelles un tableau cumulé ne peut pas être utilisé, ainsi que les étapes à suivre pour faciliter l'utilisation de ce tableau.

Raison pour laquelle vous n'utilisez pas le tableau cumulé Explication et étapes possibles
Ce champ n'existe pas 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'a pas été correctement définie ou qu'il y avait une faute de frappe dans le code LookML de votre table agrégée. L'une des causes probables est l'utilisation d'un nom de champ incorrect, par exemple.

Pour résoudre ce problème, vérifiez que les dimensions et les mesures de la table agrégée correspondent aux noms des champs de l'exploration. Pour en savoir plus sur la définition d'une table agrégée, consultez la page de documentation sur le paramètre aggregate_table.
Le tableau cumulé n'inclut pas les champs suivants dans la requête. Pour être utilisée dans une requête d'exploration, une table agrégée doit comporter toutes les dimensions et mesures nécessaires pour cette requête, y compris les champs utilisés pour les filtres de cette requête. Si une requête d'exploration contient une dimension ou une mesure qui ne figure pas dans une table agrégée, Looker ne peut pas utiliser la table agrégée et utilisera la table de base à la place. Pour en savoir plus, consultez la section Facteurs de champ sur cette page. La seule exception concerne les dimensions de période, car des périodes plus précises peuvent être dérivées de périodes plus précises.

Pour résoudre ce problème, vérifiez que les champs de la requête d'exploration sont inclus dans la définition de la table agrégée.
La requête contenait les filtres suivants qui n'étaient ni inclus en tant que champs, ni correspondent exactement aux filtres de la table agrégée. Les filtres de la requête d'exploration 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 :
  • Ajoutez le même filtre à votre tableau cumulé.
  • Ajoutez le champ utilisé par le filtre à votre tableau cumulé.
  • Supprimez les filtres de la requête d'exploration.
Pour en savoir plus, consultez la section Facteurs de filtrage sur cette page.
La requête contient les mesures suivantes qui ne peuvent pas être regroupées. La requête contient un ou plusieurs types de mesure qui ne sont pas compatibles avec la reconnaissance agrégée, comme distinct count (nombre distinct), median (médiane) ou percentile (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 mesure compatibles. De plus, si votre exploration comporte des jointures, vérifiez que vos mesures ne sont pas converties en mesures distinctes (agrégats symétriques) via des jointures ramifiées. 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. Plusieurs tables agrégées viables étaient disponibles pour la requête, et Looker a trouvé une table agrégée plus optimale à utiliser à la place. Dans ce cas, aucune action de votre part n'est requise.
Looker n'a effectué aucun regroupement (en raison d'un paramètre primary_key ou cancel_grouping_fields), et la requête ne peut donc pas être déployée. La requête fait référence à une dimension qui l'empêche de comporter une clause GROUP BY. Looker ne peut donc 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.
Le tableau cumulé contenait des filtres non inclus 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 Facteurs de filtrage sur cette page.
Un champ est défini en tant que champ de filtre uniquement dans la requête d'exploration, mais il est répertorié dans le paramètre dimensions du tableau cumulé. Le paramètre dimensions du tableau cumulé indique un champ défini uniquement en tant que champ filter dans la requête d'exploration.

Pour résoudre ce problème, supprimez le champ de la liste dimensions du tableau cumulé. Si ce champ est nécessaire pour le tableau cumulé, ajoutez-le à la liste filters dans la requête du tableau cumulé.
L'optimiseur ne peut pas déterminer pourquoi le tableau cumulé n'a pas été utilisé. Ce commentaire est réservé aux cas particuliers. Si vous voyez ceci pour une requête d'exploration souvent utilisée, vous pouvez créer un tableau cumulé qui correspond exactement à la requête d'exploration. Vous pouvez facilement obtenir le code LookML d'une table agrégée à partir d'une exploration, comme décrit sur la page des paramètres aggregate_table.

Éléments à prendre en compte

Agrégations symétriques pour les explorations avec jointures

Il est important de noter que dans une exploration qui joint plusieurs tables de base de données, Looker peut afficher les mesures de type SUM, COUNT et AVERAGE sous la forme SUM DISTINCT, COUNT DISTINCT et AVERAGE DISTINCT, respectivement. Looker procède ainsi afin d'éviter les erreurs de calcul de la distribution ramifiée. Par exemple, une mesure count est affichée en tant que type de mesure count_distinct. Cela permet d'éviter les erreurs de calcul de distribution ramifiée pour les jointures et fait partie de la fonctionnalité d'agrégations symétriques de Looker. Pour en savoir plus sur cette fonctionnalité de Looker, consultez la page Bonnes pratiques sur les agrégations symétriques.

La fonctionnalité d'agrégation symétrique évite les erreurs de calcul, mais elle peut également empêcher l'utilisation de vos tableaux cumulés dans certains cas. Il est donc important de la comprendre.

Pour les types de mesure compatibles avec Aggregate Awareness, cela s'applique à sum, count et average. Looker indiquera ces types de mesures comme DISTINCT si:

Pour en savoir plus sur ces types de jointures, consultez la page de documentation sur le paramètre relationship.

Si vous constatez que 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 jointures. Pour en savoir plus, consultez la section Créer des tables agrégées correspondant exactement aux requêtes d'exploration sur cette page.

De plus, si votre dialecte SQL est compatible avec les sketchs HyperLogLog, vous pouvez ajouter le paramètre allow_approximate_optimization: yes à la mesure. Lorsqu'une mesure de comptage est définie avec allow_approximate_optimization: yes, Looker peut l'utiliser pour la prise de conscience globale, même si elle s'affiche sous la forme d'un nombre distinct.

Pour en savoir plus et obtenir la liste des dialectes SQL compatibles avec les résumés HyperLogLog, consultez la page de documentation du paramètre allow_approximate_optimization.

Prise en charge du dialecte pour la reconnaissance d'agrégats

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 prennent en charge la détection d'agrégats:

Dialecte Compatible ?
Avalanche d'Actian
Oui
Amazon Athena
Oui
Amazon Aurora MySQL
Oui
Amazon Redshift
Oui
Apache Druid
Non
Apache Druid 0.13 et versions ultérieures
Non
Apache Druid 0.18 et versions ultérieures
Non
Apache Hive 2.3 et versions ultérieures
Oui
Apache Hive 3.1.2 et versions ultérieures
Oui
Apache Spark 3 et versions ultérieures
Oui
ClickHouse
Non
Cloudera Impala 3.1+
Oui
Cloudera Impala 3.1+ avec pilote natif
Oui
Cloudera Impala avec Native Driver
Oui
DataVirtuality
Non
Databricks
Oui
Denodo 7
Non
Denodo 8
Non
Dremio
Non
Dremio 11 et versions ultérieures
Non
Exasol
Oui
Feu
Non
Ancien SQL de Google BigQuery
Oui
SQL standard Google BigQuery
Oui
Google Cloud PostgreSQL
Oui
Google Cloud SQL
Non
Google Spanner
Non
Greenplum
Oui
HyperSQL
Non
IBM Netezza
Oui
MariaDB
Oui
Microsoft Azure PostgreSQL
Oui
Base de données Microsoft Azure SQL
Oui
Microsoft Azure Synapse Analytics
Oui
Microsoft SQL Server 2008 et versions ultérieures
Oui
Microsoft SQL Server 2012 et versions ultérieures
Oui
Microsoft SQL Server 2016
Oui
Microsoft SQL Server 2017 et versions ultérieures
Oui
MongoBI
Non
MySQL
Oui
MySQL 8.0.12 et versions ultérieures
Oui
Oracle
Oui
Oracle ADWC
Oui
PostgreSQL 9.5 et versions ultérieures
Oui
PostgreSQL version antérieure à 9.5
Oui
PrestoDB
Oui
PrestoSQL
Oui
SAP HANA 2 et versions ultérieures
Oui
SingleStore
Oui
SingleStore 7 et versions ultérieures
Oui
Snowflake
Oui
Teradata
Oui
Trino
Oui
Vecteur
Oui
Vertica
Oui

Prise en charge du dialecte pour la création incrémentielle de tables agrégées

Pour que Looker prenne en charge les tables agrégées incrémentielles dans votre projet, votre dialecte de base de données doit également les prendre en charge. Le tableau suivant présente les dialectes prenant en charge la création incrémentielle de tables PDT dans la dernière version de Looker:

Dialecte Compatible ?
Avalanche d'Actian
Non
Amazon Athena
Non
Amazon Aurora MySQL
Non
Amazon Redshift
Oui
Apache Druid
Non
Apache Druid 0.13 et versions ultérieures
Non
Apache Druid 0.18 et versions ultérieures
Non
Apache Hive 2.3 et versions ultérieures
Non
Apache Hive 3.1.2 et versions ultérieures
Non
Apache Spark 3 et versions ultérieures
Non
ClickHouse
Non
Cloudera Impala 3.1+
Non
Cloudera Impala 3.1+ avec pilote natif
Non
Cloudera Impala avec Native Driver
Non
DataVirtuality
Non
Databricks
Oui
Denodo 7
Non
Denodo 8
Non
Dremio
Non
Dremio 11 et versions ultérieures
Non
Exasol
Non
Feu
Non
Ancien SQL de Google BigQuery
Non
SQL standard Google BigQuery
Oui
Google Cloud PostgreSQL
Oui
Google Cloud SQL
Non
Google Spanner
Non
Greenplum
Oui
HyperSQL
Non
IBM Netezza
Non
MariaDB
Non
Microsoft Azure PostgreSQL
Oui
Base de données Microsoft Azure SQL
Non
Microsoft Azure Synapse Analytics
Oui
Microsoft SQL Server 2008 et versions ultérieures
Non
Microsoft SQL Server 2012 et versions ultérieures
Non
Microsoft SQL Server 2016
Non
Microsoft SQL Server 2017 et versions ultérieures
Non
MongoBI
Non
MySQL
Oui
MySQL 8.0.12 et versions ultérieures
Oui
Oracle
Non
Oracle ADWC
Non
PostgreSQL 9.5 et versions ultérieures
Oui
PostgreSQL version antérieure à 9.5
Oui
PrestoDB
Non
PrestoSQL
Non
SAP HANA 2 et versions ultérieures
Non
SingleStore
Non
SingleStore 7 et versions ultérieures
Non
Snowflake
Oui
Teradata
Non
Trino
Non
Vecteur
Non
Vertica
Oui