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 approximer les décomptes distincts des tableaux agrégés.
L'instruction allow_approximate_optimization: yes permet à Looker de stocker des croquis HyperLogLog dans des tables agrégées. Cela signifie que Looker peut 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 Compatibilité des dialectes pour les nombres distincts avec la reconnaissance des agrégats 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 fois, à trois semaines d'intervalle. Si vous essayez d'appliquer un tableau cumulé hebdomadaire pour obtenir un nombre mensuel d'utilisateurs uniques sur votre site Web, cet utilisateur sera comptabilisé deux fois dans votre requête de nombre mensuel d'utilisateurs uniques, et les données seront incorrectes.
Pour contourner ce problème, vous pouvez créer un tableau cumulé qui correspond exactement à une requête Explorer, comme décrit sur la page de documentation Reconnaissance d'agrégats. Lorsque la requête d'exploration et la requête de tableau cumulé sont identiques, les mesures de nombre de valeurs distinctes fournissent des données précises. Elles peuvent donc être utilisées pour la reconnaissance 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 qu'elle puisse être calculée approximativement à partir de tables agrégées.
Avec la connaissance agrégée, 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
type: countqui sont en fait 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 fan-out 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'un tableau cumulé, 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 distinct sont utilisées pour la reconnaissance des agrégats 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} ;;
}
Prise en charge 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 décomptes 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.x - 0.17.x | |
| 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 AlloyDB for PostgreSQL | |
| 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 | |
| MongoSQL | |
| 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.