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
Une valeur booléenne (oui ou non)
|
Définition
Pour les dialectes compatibles avec les esquisses HyperLogLog, Looker peut utiliser l'algorithme HyperLogLog pour estimer les décomptes distincts pour les tables agrégées.
L'instruction allow_approximate_optimization: yes permet à Looker de stocker des croquis HyperLogLog dans des tables agrégées, ce qui signifie que Looker peut utiliser des approximations pour les décomptes distincts pour la reconnaissance d'agrégats.
Consultez la section Compatibilité des dialectes pour les décomptes distincts avec l'awareness d'agrégation sur cette page pour obtenir la liste des dialectes compatibles avec les décomptes distincts pour les tables d'agrégation à l'aide de croquis HyperLogLog.
En général, les décomptes distincts ne sont pas compatibles avec la reconnaissance d'agrégats, car vous ne pouvez pas obtenir de données précises si vous essayez d'agréger des décomptes distincts. Par exemple, si vous comptez les utilisateurs distincts sur un site Web, il est possible qu'un utilisateur ait visité 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 distincts sur votre site Web, cet utilisateur sera comptabilisé deux fois dans votre requête de nombre mensuel d'utilisateurs distincts, 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 sur la page de documentation Reconnaissance d'agrégats. Lorsque la requête d'exploration et une requête de tableau cumulé sont identiques, les mesures de décompte distinct fournissent des données précises. Elles peuvent donc être utilisées pour l'Aggregate Awareness.
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 acceptent l'utilisation de données approximatives pour la mesure, afin que celle-ci puisse être calculée de manière approximative à partir de tables agrégées.
Avec la reconnaissance d'agrégation, il existe deux cas où les décomptes distincts entrent en jeu :
- Le premier cas concerne les mesures de
type: count_distinct. - Le deuxième cas concerne les mesures de
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 fanout dans les explorations qui joignent plusieurs tables de base de données.
Dans les deux cas, si votre dialecte est compatible avec les esquisses 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 cumulés.
Même pour les mesures définies avec
allow_approximate_optimization: yes, Looker renvoie des données exactes lorsque cela est possible. Par exemple, si les dimensions d'une requête d'exploration correspondent parfaitement aux dimensions d'un tableau cumulé, Looker peut fournir des données exactes pour les nombres distincts, sans avoir à les estimer. Dans ce cas, vous verrez dans l'onglet SQL de l'exploration que des mesures de décompte distinct sont utilisées pour l'aggregate awareness sans utiliser l'algorithme HyperLogLog.
Exemple
La mesure apx_unique_count présentée dans cet exemple est définie pour 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 décomptes distincts avec la fonction Aggregate Awareness
Looker peut utiliser des décomptes distincts pour la reconnaissance d'agrégats avec des dialectes de base de données qui prennent en charge les croquis HyperLogLog. Dans la dernière version de Looker, les dialectes SQL suivants sont compatibles avec les décomptes distincts avec l'aggregate awareness :
| 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 | |
| ClickHouse 26+ | |
| 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+ | |
| Dremio 26+ with Arrow Flight SQL | |
| 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.