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 qui acceptent les esquisses HyperLogLog, Looker peut exploiter l'algorithme HyperLogLog pour approximer les nombres distincts des tables agrégées.
L'instruction allow_approximate_optimization: yes permet à Looker de stocker des esquisses HyperLogLog dans des tables agrégées. Cela signifie que Looker peut utiliser des approximations pour les nombres distincts afin de connaître les agrégats.
Pour obtenir la liste des dialectes qui acceptent les nombres distincts pour les tables agrégées à l'aide d'esquisses HyperLogLog, consultez la section Compatibilité des dialectes avec les nombres distincts et la connaissance des agrégats sur cette page.
En général, les nombres distincts ne peuvent pas être compatibles avec la connaissance des agrégats, 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 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 un nombre mensuel d'utilisateurs distincts sur votre site Web, cet utilisateur sera compté deux fois dans votre requête mensuelle de nombre distinct, et les données seront incorrectes.
Pour contourner ce problème, vous pouvez créer un tableau cumulé qui correspond exactement à une requête d'exploration, comme décrit sur la page de documentation Connaissance des agrégats. Lorsque la requête d'exploration et une requête de tableau cumulé sont identiques, les mesures de nombre distinct fournissent des données précises. Elles peuvent donc être utilisées pour la connaissance 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 des agrégats, les nombres distincts interviennent dans deux cas :
- Le premier cas concerne les mesures de
type: count_distinct. - Le deuxième cas concerne les mesures de
type: countqui sont en fait rendues par Looker en tant que types de mesurescount_distinct. Comme indiqué sur la page de documentation Connaissance des agrégats, Looker affiche les mesurescounten tant quecount_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 accepte 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 tables agrégées.
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 approximer. Dans ce cas, vous verrez dans l'onglet SQL de l'exploration que les mesures de nombre distinct sont utilisées pour la connaissance 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 une aggregate_table.
measure: apx_unique_count {
type: count_distinct
allow_approximate_optimization: yes # default value is no
sql: ${id} ;;
}
Compatibilité des dialectes avec les nombres distincts et la connaissance des agrégats
Looker peut utiliser des nombres distincts pour la connaissance des agrégats avec des dialectes de base de données qui acceptent les esquisses HyperLogLog. Dans la dernière version de Looker, les dialectes SQL suivants sont compatibles avec les nombres distincts et la connaissance des agrégats :
| 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.