Reconnaissance d'agrégats

Remarque :Pour obtenir un guide sur l'implémentation de la connaissance globale, consultez également la page des bonnes pratiques de notre tutoriel sur la connaissance globale.

Présentation

Looker utilise la logique de connaissance des agrégats 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 conservant la précision.

Pour les très grandes tables de votre base de données, les développeurs Looker peuvent créer des tables de données agrégées plus petites, regroupées par diverses combinaisons d'attributs. Les tables agrégées fonctionnent comme des agrégations ou des tableaux récapitulatifs que Looker peut utiliser pour les requêtes, dans la mesure du possible, au lieu de la grande table d'origine. Lorsqu'elle est implémentée de manière stratégique, la connaissance globale peut accélérer la requête moyenne de plusieurs ordres de grandeur.

Par exemple, vous pouvez avoir une table de données de plusieurs pétaoctets 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 agrégé contenant les totaux de vos ventes quotidiennes. Si votre site Web reçoit 1 000 commandes par jour, votre table récapitulative quotidienne comportera 999 lignes de moins que votre table d'origine. Vous pouvez créer une autre table agrégée avec les totaux des ventes mensuelles, qui sera encore plus efficace. Désormais, si un utilisateur exécute une requête pour les ventes quotidiennes ou hebdomadaires, Looker utilisera la table du total des ventes quotidiennes. Si un utilisateur exécute une requête sur les ventes annuelles et que vous ne disposez pas d'une table agrégative annuelle, Looker utilisera la table agrégative mensuelle dans cet exemple.

Lorsque cela est possible, Looker répond aux questions de vos utilisateurs à l'aide des tables agrégées les plus petites. Exemple :

• Pour une requête sur le total des ventes mensuelles, Looker utilise la table agrégée basée sur les ventes mensuelles (sales_monthly_aggregate_table).
• Pour une requête sur le total de chaque vente par jour, il n'existe pas de table agrégée avec cette granularité. Looker obtient donc les résultats de la 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 cela.
• Pour une requête sur les ventes hebdomadaires, il n'existe pas de table agrégée hebdomadaire. Looker utilise donc la table agrégée basée sur les ventes quotidiennes (sales_daily_aggregate_table).

Grâce à la logique de connaissance des agrégats, Looker interroge le plus petit tableau agrégé possible pour répondre aux questions de vos utilisateurs. La table d'origine ne sera utilisée que pour les requêtes nécessitant une granularité plus fine que celle des tables agrégées.

Les tables agrégées n'ont pas besoin d'être jointes ni ajoutées à une exploration distincte. À la place, Looker ajuste dynamiquement la clause FROM de la requête d'exploration pour accéder à la meilleure table agrégée pour la requête. Cela signifie que vos analyses sont conservées et que les explorations peuvent être consolidées. Grâce à la prise en compte des données agrégées, une exploration peut exploiter automatiquement des tableaux agrégables, tout en analysant en détail les données détaillées si nécessaire.

Vous pouvez également utiliser des tableaux agrégatifs pour améliorer considérablement les performances des tableaux de bord, en particulier pour les cartes qui interrogent des ensembles de données volumineux. Pour en savoir plus, consultez la section Extraire 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 agrégatifs à votre projet

Remarque :Pour être accessibles à la connaissance globale, les tables agrégées doivent être persistantes dans votre 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 PDT. Pour en savoir plus, consultez la page de documentation Tables dérivées dans Looker.

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 grandes tables d'une base de données. Les tables agrégées doivent être persistantes dans votre base de données afin qu'elles soient accessibles pour la connaissance globale. 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 d'explore avec un tableau agrégé en 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 obtenir le code LookML de la table agrégée à partir d'une exploration ou d'un tableau de bord. Pour en savoir plus sur le paramètre aggregate_table et ses sous-paramètres, consultez la page de documentation du paramètre aggregate_table.

Concevoir des tableaux cumulés

Pour qu'une requête d'exploration puisse utiliser une table agrégée, celle-ci doit pouvoir fournir des données précises à la requête d'exploration. Looker peut utiliser un tableau agrégé pour une requête Explore 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égative (voir la section Facteurs de champ de cette page). Pour les périodes, les périodes de la requête d'exploration peuvent être dérivées des périodes de la table agrégative (voir la section Facteurs de période sur cette page).
• La requête d'exploration contient des types de mesures compatibles avec la notoriété globale (voir la section Facteurs liés au type de mesure sur cette page) ou la requête d'exploration comporte une table globale qui est une correspondance exacte (voir la section Créer des tables globales qui correspondent exactement aux requêtes d'exploration sur cette page).
• Le fuseau horaire de la requête Exploration correspond à celui utilisé par la table agrégative (voir 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 la table agrégée, ou chacun des filtres de la requête d'exploration correspond à un filtre de la table agrégée (voir 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 créer une table agrégée qui correspond exactement à une requête Explorer. Pour en savoir plus, consultez la section Créer des tables agrégées correspondant exactement aux requêtes Explorer sur cette page.

Facteurs sur le terrain

Pour être utilisée dans une requête d'exploration, une table agrégée doit contenir toutes les dimensions et mesures nécessaires à cette requête, y compris les champs utilisés pour les filtres. 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 utilise à la place la table de base.

Par exemple, si une requête regroupe les données par dimensions A et B, les agrège par mesure C et filtre les données en fonction de la dimension D, le tableau agrégé doit comporter au moins les dimensions A, B et D, ainsi que la mesure C.

Le tableau agrégé peut également contenir d'autres champs, mais il doit comporter au moins les champs de la requête d'exploration pour pouvoir être optimisé. La seule exception concerne les dimensions de période, car les périodes de granularité plus élevée peuvent être dérivées de celles de granularité plus fine.

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

Facteurs de période

La logique de visibilité globale de Looker peut dériver une période d'une autre. Une table agrégée peut être utilisée pour une requête tant que la période de la table agrégée a une granularité plus fine (ou égale) que celle de 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, telles que des requêtes pour des données quotidiennes, mensuelles et annuelles, ou même des données par jour, par mois et par semaine. 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 ne sont pas assez précises 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 sur 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: une table agrégée peut être utilisée pour une requête avec un filtre de période tant que la période de la table agrégée a 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 avec un filtrage par jour, par semaine ou par mois.

Facteurs liés au type de mesure

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

C'est pourquoi seuls certains types de mesures sont acceptés, comme décrit dans les sections suivantes:

• Mesures avec types de mesures acceptés
• Mesures définies par des expressions SQL
• Mesures qui ne sont pas définies avec ${TABLE}
• Mesures qui approximatives le nombre d'éléments distincts

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. La seule exception est si 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 qui correspondent 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 types de mesures compatibles

La connaissance globale peut être utilisée pour les requêtes Explore qui utilisent des mesures avec les types de mesures suivants:

• sum
• count
• min
• max
• average

Remarque :Si une exploration 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 pour éviter les erreurs de calcul de la diffusion, comme décrit dans la section Agrégations symétriques pour les explorations avec des jointures de cette page.

Pour utiliser une table agrégée dans une requête d'exploration, Looker doit pouvoir effectuer des opérations 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é globale, car vous pouvez additionner plusieurs sommes: une table globale des sommes hebdomadaires peut être additionnée pour obtenir une somme mensuelle précise. De même, vous pouvez utiliser une mesure avec type: max, car une table agrégée des maxima quotidiens peut être utilisée pour trouver le maximum hebdomadaire précis.

Dans le cas des mesures avec type: average, la prise en compte des agrégations est prise en charge, car Looker utilise les données de somme et de nombre pour dériver précisément les valeurs moyennes à partir des tableaux agrégatifs.

Mesures définies avec des expressions SQL

La visibilité globale peut également être utilisée avec des mesures définies avec des expressions dans le paramètre sql. Lorsqu'elles sont définies avec des expressions SQL, les types de mesures suivants sont également acceptés:

• number
• date
• string
• yesno

La visibilité globale est prise en charge pour 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 prise de conscience globale est également prise en charge pour les mesures dont 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) ;;
}

La prise en compte des agrégations est également compatible avec les mesures dans lesquelles les opérations MIN, MAX et COUNT sont définies dans le paramètre sql, comme cette mesure:

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

Avertissement :La reconnaissance d'agrégats n'est compatible qu'avec les opérations MIN(), MAX() et COUNT(). Si vous souhaitez utiliser une mesure de la moyenne ou de la somme dans votre tableau agrégé, vous pouvez créer une mesure de type: average ou de type: sum, qui sont tous deux compatibles avec la notoriété agrégée.

Mesures qui font référence à des champs LookML

Lorsque des expressions sql sont utilisées dans des mesures, la connaissance globale est compatible avec les types de références de champ suivants:

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

La prise en compte des agrégations n'est pas disponible pour les mesures définies à l'aide du format ${TABLE}.column_name, qui indique une colonne dans un tableau. (Pour en savoir plus sur l'utilisation des références dans LookML, consultez la page de documentation Intégrer des objets SQL et faire référence à des objets LookML.)

Par exemple, une mesure définie avec ce paramètre sql ne serait pas compatible avec une table agrégée, 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 agrégé, vous pouvez créer une dimension définie avec le format ${TABLE}.column_name, puis une mesure qui fait 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 désormais utiliser la mesure wholesale_value dans votre table agrégée.

Mesures qui approximatives le nombre d'éléments distincts

En général, les comptes distincts ne sont pas compatibles avec la visibilité globale, car vous ne pouvez pas obtenir de données précises si vous essayez d'agréger des comptes distincts. Par exemple, si vous comptez les utilisateurs distincts sur un site Web, il est possible qu'un utilisateur ait accédé au site Web deux fois, à trois semaines d'intervalle. Si vous essayez d'appliquer un tableau agrégé hebdomadaire pour obtenir un nombre mensuel d'utilisateurs distincts sur votre site Web, cet utilisateur sera compté deux fois dans votre requête de nombre distinct mensuel, et les données seront incorrectes.

Pour contourner ce problème, vous pouvez créer une table agrégée qui correspond exactement à une requête d'exploration, comme décrit dans la section Créer des tables agrégées qui correspondent 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 nombre distinctes fournissent des données précises. Elles peuvent donc être utilisées pour la sensibilisation globale.

Vous pouvez également utiliser des approximations pour les nombres distincts. Pour les dialectes compatibles avec les résumés HyperLogLog, Looker peut exploiter l'algorithme HyperLogLog pour estimer les nombres distincts des tableaux agrégatifs.

L'algorithme HyperLogLog est connu pour présenter 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 qu'elle puisse être calculée approximativement à partir de tables agrégées.

Pour en savoir plus et obtenir la liste des dialectes compatibles avec la fonction count distinct avec HyperLogLog, consultez la page de documentation du paramètre allow_approximate_optimization.

Facteurs liés au fuseau horaire

Dans de nombreux cas, les administrateurs de base de données utilisent le fuseau horaire UTC. Toutefois, de nombreux utilisateurs ne se trouvent pas dans le fuseau horaire UTC. Looker propose plusieurs options de conversion de fuseaux horaires afin que vos utilisateurs obtiennent les résultats de leurs 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 de base de données. Si tous vos utilisateurs se trouvent dans le même fuseau horaire, vous pouvez définir un seul fuseau horaire de requête afin que toutes les requêtes soient converties du fuseau horaire de la base de données vers celui de la requête.
• Fuseaux horaires spécifiques à l'utilisateur, où les fuseaux horaires peuvent être attribués et sélectionnés individuellement par les utilisateurs. 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 de documentation Utiliser les paramètres de fuseau horaire.

Ces concepts sont importants pour comprendre la prise en compte des agrégations, car pour qu'une table agrégée puisse être utilisée pour une requête avec des dimensions 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 n'est pas compatible avec 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 que le fuseau horaire de la base de données.
• Votre connexion à la base de données ne comporte ni fuseau horaire de requête spécifié, ni fuseaux horaires spécifiques à 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 tables agrégées.

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

• Si votre connexion de base de données utilise un seul fuseau horaire de requête, vous devez faire correspondre la valeur timezone de votre table agrégative à celle du fuseau horaire de la requête.
• Si votre connexion de 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 timezone différente pour correspondre aux fuseaux horaires possibles de vos utilisateurs.

Avertissement :Looker ne peut pas utiliser une table agrégée pour une requête d'exploration si le fuseau horaire de la table agrégée ne correspond pas à celui de la requête d'exploration. Si votre connexion de base de données comporte des fuseaux horaires spécifiques à l'utilisateur, vous avez besoin d'une table agrégative distincte pour chacun des fuseaux horaires de vos utilisateurs.

Facteurs de filtrage

Soyez prudent lorsque vous incluez des filtres dans votre tableau agrégé. Les filtres appliqués à un tableau agrégé peuvent réduire les résultats au point où le tableau agrégé devient inutilisable. Par exemple, imaginons que vous créiez une table agrégative pour le nombre de commandes quotidiennes, et que cette table ne filtre que les commandes de lunettes de soleil provenant d'Australie. Si un utilisateur exécute une requête Explore pour connaître le nombre de commandes quotidiennes de lunettes de soleil dans le monde entier, Looker ne peut pas utiliser le tableau agrégé pour cette requête Explore, car il ne contient que les données pour l'Australie. La table agrégée filtre les données trop précisément pour être utilisée par la requête d'exploration.

Tenez également compte des filtres que vos développeurs Looker ont peut-être intégrés à votre exploration, par exemple:

• 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 par défaut du filtre pour leur requête, mais pas le supprimer complètement.
• 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 contient ces filtres, vous devez inclure leurs champs dans le paramètre dimensions de aggregate_table.

Voici, par exemple, 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 une table agrégée à utiliser pour cette exploration, celle-ci 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 agrégé:

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 la 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 l'exploration comporte 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 la table dérivée native. En cas de prise en compte des agrégats, si votre requête d'exploration nécessite une table dérivée native qui utilise bind_filters, elle 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 qui correspondent 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 qui correspond 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 de la table agrégée s'appliquent 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 qui incluent n'importe quel type de mesure.

Vous pouvez créer une table agrégée à partir d'une exploration à l'aide de l'option Obtenir le code LookML dans le menu en forme de roue dentée d'une exploration. Vous pouvez également créer des correspondances exactes pour toutes les cartes d'un tableau de bord à l'aide de l'option Obtenir le code 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 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 les nouvelles tables agrégées pour voir comment Looker les utilise avant de les mettre en production.

Par exemple, en vous basant sur l'exemple de tableau agrégé mensuel présenté précédemment, vous pouvez accéder à l'exploration 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 le tableau agrégé utilisé pour la requête.

Les commentaires suivants de l'onglet SQL indiquent que Looker utilise la table agrégative sales_monthly pour cette requête et expliquent pourquoi d'autres tables agrégatives 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 commentaires que vous pouvez voir dans l'onglet SQL et les suggestions pour les résoudre.

Estimations des économies de calcul pour la notoriété globale

Si votre connexion à la base de données est compatible avec les estimations de coûts et si une table agrégée peut être utilisée pour une requête, la fenêtre "Explorer" affiche les économies de calcul réalisées en utilisant la table agrégée au lieu d'interroger directement la base de données. L'économie globale de notoriété s'affiche à côté du bouton 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 d'agrégation sera utilisée pour la requête, vous pouvez cliquer sur l'onglet SQL, comme décrit dans la section Déterminer la table d'agrégation utilisée pour une requête de cette page de documentation.

Une fois la requête exécutée, la fenêtre "Explorer" indique le tableau agrégé utilisé pour répondre à la requête à côté du bouton Run (Exécuter).

Les économies globales liées à la sensibilisation 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 de documentation Explorer les données dans Looker .

Looker associe les nouvelles données à vos tableaux cumulés.

Pour les tables agrégées avec des filtres temporels, Looker peut union les données fraîches dans votre table agrégée. Vous pouvez disposer d'un tableau agrégé qui inclut les données des trois derniers jours, mais ce tableau agrégé a peut-être été créé hier. Le tableau agrégé ne contient pas les informations d'aujourd'hui. Vous ne pouvez donc pas l'utiliser pour une requête d'exploration sur les informations quotidiennes les plus récentes.

Toutefois, 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 joint ces résultats à ceux de la table agrégée.

Looker peut associer des données fraîches aux données de votre table agrégée dans les cas suivants:

• Le tableau agrégé comporte un filtre temporel.
• Le tableau agrégé inclut une dimension basée sur le même champ temporel que le filtre temporel.

Par exemple, le tableau agrégé suivant comporte une dimension basée sur le champ orders.created_date et un filtre temporel ("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égative 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égative, puis joint les résultats récents aux résultats de la table agrégative. Cela signifie que vos utilisateurs recevront les dernières données tout en optimisant leurs performances grâce à la sensibilisation globale.

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

Remarque :Si Looker ne parvient pas à joindre de nouvelles données à votre table agrégée, il utilisera les données existantes de la table agrégée.

Les tables agrégées doivent être conservées

Pour être accessible à la connaissance globale, votre table agrégative doit être persistante dans votre base de données. La stratégie de persistance est spécifiée dans le paramètre materialization de la table agrégative. É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 PDT. Pour en savoir plus, consultez la page de documentation Tables dérivées dans Looker.

Vous pouvez créer des tables PDT incrémentielles dans votre projet si votre dialecte les prend en charge. Looker crée des augmentations de table PDT en ajoutant de nouvelles données à la table, au lieu de la régénérer dans son intégralité. Étant donné que les tables agrégées sont elles-mêmes un type de table PDT, vous pouvez également créer des tables agrégées incrémentielles. Pour en savoir plus sur les PDT incrémentaux, consultez la page de documentation PDT incrémentaux. Pour obtenir un exemple de table agrégative incrémentielle, consultez la page de documentation du paramètre increment_key.

Un utilisateur disposant de l'autorisation develop peut remplacer 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 l'option Recréer les tables dérivées et exécuter dans le menu en forme de roue dentée Actions d'exploration.

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

L'option Régénérer les tables dérivées et exécuter regénère toutes les tables dérivées référencées dans la requête, ainsi que toutes les tables dérivées sur lesquelles les tables de la requête 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 sélectionne l'option Rebuild Derived Tables & Run (Régénérer les tables dérivées et exécuter), la requête attend que les tables soient régénérées avant de charger des résultats. Les requêtes des autres utilisateurs continuent 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 Recréer les tables dérivées et exécuter, consultez la page de documentation Tables dérivées dans Looker.

Dépannage

Comme décrit dans la section Déterminer le tableau agrégé utilisé 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 le tableau agrégé utilisé pour la requête, le cas échéant.

L'onglet SQL inclut également des commentaires sur les raisons pour lesquelles 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 qui ne sont pas utilisées, le commentaire commence par:

Did not use [explore name]::[aggregate table name];

Par exemple, voici un commentaire expliquant pourquoi le tableau agrégé sales_daily défini dans l'exploration order_items n'a pas été utilisé 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égative.

Le tableau suivant présente d'autres raisons possibles pour lesquelles une table agrégative ne peut pas être utilisée, ainsi que les mesures que vous pouvez prendre pour améliorer son usabilité.

Motif de 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 le tableau agrégé n'a pas été correctement défini ou qu'il y a une faute de frappe dans le code LookML de votre tableau agrégé. Le problème est probablement lié à un nom de champ incorrect, etc. Pour résoudre ce problème, vérifiez que les dimensions et les mesures de la table agrégée correspondent aux noms de champ de l'exploration. Pour en savoir plus sur la définition d'un tableau agrégé, consultez la page de documentation du paramètre aggregate_table.
Le tableau agrégé 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 contenir toutes les dimensions et mesures nécessaires à cette requête, y compris les champs utilisés pour les filtres. 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 utilise à la place la table 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 de granularité plus élevée peuvent être dérivées de celles de granularité plus fine. 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 exactement correspondants aux filtres du tableau agrégé.	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 agrégé. Ajoutez le champ utilisé par le filtre à votre table agrégée. Supprimez les filtres de la requête d'exploration. Pour en savoir plus, consultez la section Facteurs de filtrage de cette page.
La requête contient les mesures suivantes qui ne peuvent pas être agrégées.	La requête contient un ou plusieurs types de métriques non compatibles avec la visibilité 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 étalées. Pour en savoir plus, consultez la section Agrégations symétriques pour les explorations avec des jointures sur cette page.
Un autre tableau agrégé était plus adapté à l'optimisation.	Plusieurs tables agrégées étaient possibles pour la requête, et Looker a trouvé une table agrégée plus optimale à utiliser à la place. Aucune action de votre part n'est nécessaire.
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 agrégé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 le paramètre primary_key de la vue et le paramètre cancel_grouping_fields de l'exploration sont correctement configurés.
Le tableau cumulé contenait des filtres qui ne figuraient pas dans la requête.	La table agrégée contient 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 agrégé. Pour en savoir plus, consultez la section Facteurs de filtrage de cette page.
Un champ est défini comme un champ de filtre uniquement dans la requête d'exploration, mais il est listé dans le paramètre dimensions de la table agrégée.	Le paramètre dimensions de la table agrégée liste un champ qui n'est défini que comme champ filter dans la requête d'exploration. Pour résoudre ce problème, supprimez le champ de la liste dimensions du tableau agrégé. Si ce champ est nécessaire pour la table agrégative, ajoutez-le à la liste filters dans la requête de la table agrégative.
L'optimiseur ne peut pas déterminer pourquoi la table agrégative n'a pas été utilisée.	Ce commentaire est réservé aux cas particuliers. Si vous voyez ce message pour une requête Exploration fréquemment utilisée, vous pouvez créer une table agrégée qui correspond exactement à la requête 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

Notez qu'une exploration qui joint plusieurs tables de base de données peut afficher les mesures de type SUM, COUNT et AVERAGE sous la forme SUM DISTINCT, COUNT DISTINCT et AVERAGE DISTINCT, respectivement. Looker fait cela pour éviter les erreurs de calcul du fanout. 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 fanouts pour les jointures. Cette fonctionnalité fait partie des agrégations symétriques de Looker. Consultez la page des bonnes pratiques sur les agrégations symétriques pour en savoir plus sur cette fonctionnalité de Looker.

La fonctionnalité d'agrégation symétrique empêche les erreurs de calcul, mais elle peut également empêcher l'utilisation de vos tables agrégées dans certains cas. Il est donc important de bien la comprendre.

Pour les types de mesures compatibles avec la notoriété globale, cela s'applique à sum, count et average. Looker affiche ces types de mesures en tant que DISTINCT si:

• La mesure provient de la vue "un" d'une jointure plusieurs-à-un ou un-à-plusieurs.
• La mesure provient de l'une des vues d'une jointure plusieurs-à-plusieurs.

Pour en savoir plus sur ces types de jointures, consultez la page de documentation du 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 des jointures. Pour en savoir plus, consultez la section Créer des tables agrégées correspondant exactement aux requêtes Explorer sur cette page.

De plus, si vous disposez d'un dialecte SQL compatible avec les esquisses HyperLogLog, vous pouvez ajouter le paramètre allow_approximate_optimization: yes à la mesure. Lorsqu'une mesure de nombre est définie avec allow_approximate_optimization: yes, Looker peut l'utiliser pour la notoriété 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 croquis HyperLogLog, consultez la page de documentation du paramètre allow_approximate_optimization.

Prise en charge des dialectes pour la sensibilisation 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 prise en compte des agrégations:

Remarque :L'ancien langage SQL BigQuery est compatible avec la connaissance des agrégations, mais pas avec l'association de données fraîches aux données de votre table agrégative.

Dialecte	Compatibilité
Actian Avalanche	Oui
Amazon Athena	Oui
Amazon Aurora MySQL	Oui
Amazon Redshift	Oui
Apache Druid	Non
Apache Druid 0.13 ou version ultérieure	Non
Apache Druid 0.18 ou version ultérieure	Non
Apache Hive 2.3 ou version ultérieure	Oui
Apache Hive 3.1.2 ou version ultérieure	Oui
Apache Spark 3 ou version ultérieure	Oui
ClickHouse	Non
Cloudera Impala 3.1 ou version ultérieure	Oui
Cloudera Impala 3.1 ou version ultérieure avec pilote natif	Oui
Cloudera Impala avec pilote natif	Oui
DataVirtuality	Non
Databricks	Oui
Denodo 7	Non
Denodo 8	Non
Dremio	Non
Dremio 11 ou version ultérieure	Non
Exasol	Oui
Flèche de feu	Non
Google BigQuery Legacy SQL	Oui
SQL standard de 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
Microsoft Azure SQL Database	Oui
Microsoft Azure Synapse Analytics	Oui
Microsoft SQL Server 2008 ou version ultérieure	Oui
Microsoft SQL Server 2012 ou version ultérieure	Oui
Microsoft SQL Server 2016	Oui
Microsoft SQL Server 2017 ou version ultérieure	Oui
MongoBI	Non
MySQL	Oui
MySQL 8.0.12 ou version ultérieure	Oui
Oracle	Oui
Oracle ADWC	Oui
PostgreSQL 9.5 ou version ultérieure	Oui
PostgreSQL version antérieure à 9.5	Oui
PrestoDB	Oui
PrestoSQL	Oui
SAP HANA 2 ou version ultérieure	Oui
SingleStore	Oui
SingleStore 7+	Oui
Snowflake	Oui
Teradata	Oui
Trino	Oui
Vecteur	Oui
Vertica	Oui

Prise en charge des dialectes pour la création incrémentielle de tables agrégées

Pour que Looker prenne en charge les tables agrégatives incrémentielles dans votre projet, votre dialecte de base de données doit également les prendre en charge. La table suivante indique les dialectes compatibles avec la création incrémentielle de tables PDT dans la dernière version de Looker:

Dialecte	Compatibilité
Actian Avalanche	Non
Amazon Athena	Non
Amazon Aurora MySQL	Non
Amazon Redshift	Oui
Apache Druid	Non
Apache Druid 0.13 ou version ultérieure	Non
Apache Druid 0.18 ou version ultérieure	Non
Apache Hive 2.3 ou version ultérieure	Non
Apache Hive 3.1.2 ou version ultérieure	Non
Apache Spark 3 ou version ultérieure	Non
ClickHouse	Non
Cloudera Impala 3.1 ou version ultérieure	Non
Cloudera Impala 3.1 ou version ultérieure avec pilote natif	Non
Cloudera Impala avec pilote natif	Non
DataVirtuality	Non
Databricks	Oui
Denodo 7	Non
Denodo 8	Non
Dremio	Non
Dremio 11 ou version ultérieure	Non
Exasol	Non
Flèche de feu	Non
Google BigQuery Legacy SQL	Non
SQL standard de 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
Microsoft Azure SQL Database	Non
Microsoft Azure Synapse Analytics	Oui
Microsoft SQL Server 2008 ou version ultérieure	Non
Microsoft SQL Server 2012 ou version ultérieure	Non
Microsoft SQL Server 2016	Non
Microsoft SQL Server 2017 ou version ultérieure	Non
MongoBI	Non
MySQL	Oui
MySQL 8.0.12 ou version ultérieure	Oui
Oracle	Non
Oracle ADWC	Non
PostgreSQL 9.5 ou version ultérieure	Oui
PostgreSQL version antérieure à 9.5	Oui
PrestoDB	Non
PrestoSQL	Non
SAP HANA 2 ou version ultérieure	Non
SingleStore	Non
SingleStore 7+	Non
Snowflake	Oui
Teradata	Non
Trino	Non
Vecteur	Non
Vertica	Oui