Utilisation
view: view_name {
measure: field_name {
allow_approximate_optimization: yes
}
}
|
Hiérarchie
allow_approximate_optimization |
Types de champs possibles
Mesure
Valeur par défaut
no
Acceptation
Booléen (oui ou non)
|
Définition
Pour les dialectes compatibles avec les résumés HyperLogLog, Looker peut utiliser l'algorithme HyperLogLog pour estimer les nombres distincts pour les tableaux agrégés.
L'instruction allow_approximate_optimization: yes permet à Looker de stocker des schémas HyperLogLog dans des tables agrégées. Looker peut ainsi utiliser des approximations pour les nombres distincts pour la reconnaissance des agrégats.
Pour obtenir la liste des dialectes qui acceptent les nombres distincts pour les tables agrégées à l'aide de croquis HyperLogLog, consultez la section Prise en charge des dialectes pour les nombres distincts avec agrégation sur cette page.
En général, les nombres distincts ne sont pas compatibles avec la prise en compte de l'agrégation, car vous ne pouvez pas obtenir de données précises si vous essayez d'agréger des nombres distincts. Par exemple, si vous comptez les utilisateurs distincts sur un site Web, il peut y avoir un utilisateur qui est venu sur le site Web à deux reprises, à trois semaines d'intervalle. Si vous avez essayé d'appliquer un tableau agrégé hebdomadaire pour obtenir un nombre mensuel d'utilisateurs uniques sur votre site Web, cet utilisateur aurait été comptabilisé deux fois dans votre requête de nombre mensuel d'utilisateurs uniques, et les données auraient été incorrectes.
Pour contourner ce problème, vous pouvez créer une table agrégée qui correspond exactement à une requête Explorer, comme décrit sur la page de documentation Connaissance des agrégats. Lorsque la requête d'exploration et la requête de table agrégée sont identiques, les mesures de nombre de valeurs distinctes fournissent des données précises. Elles peuvent donc être utilisées pour la prise en compte des agrégats.
L'autre option consiste à utiliser des approximations pour les nombres distincts. L'algorithme HyperLogLog est connu pour avoir une marge d'erreur potentielle d'environ 2 %. Le paramètre allow_approximate_optimization exige que vos développeurs Looker reconnaissent qu'il est acceptable d'utiliser des données approximatives pour la mesure afin que celle-ci puisse être calculée approximativement à partir de tableaux agrégés.
Avec la prise de conscience globale, il existe deux cas où les nombres distincts entrent en jeu :
- Le premier cas concerne les mesures
type: count_distinct. - Le deuxième cas concerne les mesures de
type: countqui sont réellement affichées par Looker en tant que types de mesurescount_distinct. Comme indiqué sur la page de documentation Reconnaissance d'agrégats, Looker affiche les mesurescountsous la formecount_distinctpour éviter les erreurs de calcul de l'expansion dans les explorations qui joignent plusieurs tables de base de données.
Dans les deux cas, si votre dialecte est compatible avec les sketches HyperLogLog, vous pouvez ajouter l'instruction allow_approximate_optimization: yes aux mesures pour activer les valeurs approximatives. Vous pouvez ensuite inclure ces mesures dans des tableaux agrégés.
Même pour les mesures définies avec
allow_approximate_optimization: yes, Looker renverra des données exactes lorsque cela sera possible. Par exemple, si les dimensions d'une requête d'exploration correspondent parfaitement à celles d'une table agrégée, Looker peut fournir des données exactes pour les nombres distincts, sans avoir à les approximer. Dans ce cas, vous verrez dans l'onglet "SQL" de l'exploration que des mesures de nombre de valeurs distinctes sont utilisées pour la notoriété agrégée sans utiliser l'algorithme HyperLogLog.
Exemple
La mesure apx_unique_count présentée dans cet exemple est définie sur allow_approximate_optimization: yes, ce qui signifie qu'elle peut être utilisée dans un aggregate_table.
measure: apx_unique_count {
type: count_distinct
allow_approximate_optimization: yes # default value is no
sql: ${id} ;;
}
Compatibilité des dialectes pour les nombres distincts avec Aggregate Awareness
Looker peut utiliser des nombres distincts pour la fonction Aggregate Awareness avec les dialectes de base de données compatibles avec les croquis HyperLogLog. Dans la dernière version de Looker, les dialectes SQL suivants sont compatibles avec les nombres distincts avec agrégation :
| Dialecte | Compatibilité |
|---|---|
| Actian Avalanche | |
| Amazon Athena | |
| Amazon Aurora MySQL | |
| Amazon Redshift | |
| Amazon Redshift 2.1+ | |
| Amazon Redshift Serverless 2.1+ | |
| Apache Druid | |
| Apache Druid 0.13+ | |
| Apache Druid 0.18+ | |
| Apache Hive 2.3+ | |
| Apache Hive 3.1.2+ | |
| Apache Spark 3+ | |
| ClickHouse | |
| Cloudera Impala 3.1+ | |
| Cloudera Impala 3.1+ with Native Driver | |
| Cloudera Impala with Native Driver | |
| DataVirtuality | |
| Databricks | |
| Denodo 7 | |
| Denodo 8 & 9 | |
| Dremio | |
| Dremio 11+ | |
| Exasol | |
| Google BigQuery Legacy SQL | |
| Google BigQuery Standard SQL | |
| Google Cloud PostgreSQL | |
| Google Cloud SQL | |
| Google Spanner | |
| Greenplum | |
| HyperSQL | |
| IBM Netezza | |
| MariaDB | |
| Microsoft Azure PostgreSQL | |
| Microsoft Azure SQL Database | |
| Microsoft Azure Synapse Analytics | |
| Microsoft SQL Server 2008+ | |
| Microsoft SQL Server 2012+ | |
| Microsoft SQL Server 2016 | |
| Microsoft SQL Server 2017+ | |
| MongoBI | |
| MySQL | |
| MySQL 8.0.12+ | |
| Oracle | |
| Oracle ADWC | |
| PostgreSQL 9.5+ | |
| PostgreSQL pre-9.5 | |
| PrestoDB | |
| PrestoSQL | |
| SAP HANA | |
| SAP HANA 2+ | |
| SingleStore | |
| SingleStore 7+ | |
| Snowflake | |
| Teradata | |
| Trino | |
| Vector | |
| Vertica |
Consultez la documentation de votre dialecte SQL pour comprendre les compromis entre vitesse et précision de cette méthode.