Uso
view: view_name {
measure: field_name {
allow_approximate_optimization: yes
}
}
|
Jerarquía
allow_approximate_optimization |
Tipos de campos posibles
Medir
Valor predeterminado
no
Acepta
Un valor booleano (sí o no)
|
Definición
En el caso de los dialectos que admiten esbozos de HyperLogLog, Looker puede aprovechar el algoritmo de HyperLogLog para aproximar los recuentos distintos de las tablas de datos agregados.
La sentencia allow_approximate_optimization: yes permite que Looker almacene bocetos de HyperLogLog en tablas de datos agregados, lo que significa que Looker puede usar aproximaciones para recuentos distintos para el reconocimiento de agregaciones.
Consulta la sección Compatibilidad de dialectos con recuentos distintos con reconocimiento de agregación en esta página para ver la lista de dialectos que admiten recuentos distintos para tablas de datos agregados con bocetos de HyperLogLog.
En general, los recuentos distintos no se pueden admitir con el reconocimiento de agregación porque no puedes obtener datos precisos si intentas agregar recuentos distintos. Por ejemplo, si cuentas los usuarios distintos de un sitio web, es posible que haya un usuario que haya visitado el sitio web dos veces, con tres semanas de diferencia. Si intentaras aplicar una tabla de datos agregados semanal para obtener un recuento mensual de usuarios únicos en tu sitio web, ese usuario se contaría dos veces en tu consulta de recuento mensual de usuarios únicos, y los datos serían incorrectos.
Una solución alternativa para esto es crear una tabla de datos agregados que coincida exactamente con una consulta de exploración, como se describe en la página de documentación Reconocimiento de datos agregados. Cuando la consulta de exploración y la consulta de la tabla de datos agregados son iguales, las mediciones de recuento de valores distintos proporcionan datos precisos, por lo que se pueden usar para el reconocimiento de datos agregados.
La otra opción es usar aproximaciones para los recuentos de valores distintos. Se sabe que el algoritmo HyperLogLog tiene un error potencial de alrededor del 2%. El parámetro allow_approximate_optimization requiere que tus desarrolladores de Looker confirmen que es correcto usar datos aproximados para la medición, de modo que esta se pueda calcular de forma aproximada a partir de tablas de datos agregados.
Con el reconocimiento de agregación, hay dos casos en los que entran en juego los recuentos distintos:
- El primer caso es con mediciones de
type: count_distinct. - El segundo caso es con mediciones de
type: countque Looker renderiza como tipos de medicióncount_distinct. Como se explica en la página de documentación Reconocimiento de agregaciones, Looker renderiza las mediciones decountcomocount_distinctpara evitar errores de cálculo de fanout en las exploraciones que unen varias tablas de bases de datos.
En ambos casos, si tu dialecto admite bocetos de HyperLogLog, puedes agregar la sentencia allow_approximate_optimization: yes a las mediciones para habilitar los valores aproximados. Luego, puedes incluir estas mediciones en tablas de datos agregados.
Incluso para las mediciones definidas con
allow_approximate_optimization: yes, Looker devolverá datos exactos cuando sea posible. Por ejemplo, si las dimensiones de una consulta de exploración coinciden perfectamente con las dimensiones de una tabla de datos agregados, Looker puede proporcionar datos exactos para los recuentos distintos, sin tener que realizar aproximaciones. En este caso, verás en la pestaña SQL de la exploración que se usan mediciones de recuento distintas para el reconocimiento de agregaciones sin emplear el algoritmo HyperLogLog.
Ejemplo
La medición apx_unique_count que se muestra en este ejemplo se establece para allow_approximate_optimization: yes, lo que significa que se puede usar en un aggregate_table.
measure: apx_unique_count {
type: count_distinct
allow_approximate_optimization: yes # default value is no
sql: ${id} ;;
}
Compatibilidad de dialectos para recuentos distintos con reconocimiento de agregación
Looker puede usar recuentos distintos para el reconocimiento de agregaciones con dialectos de bases de datos que admiten bocetos de HyperLogLog. En la versión más reciente de Looker, se admiten los siguientes dialectos de SQL para los recuentos distintos con reconocimiento de agregación:
| Dialecto | ¿Es compatible? |
|---|---|
| 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 |
Consulta la documentación de tu dialecto de SQL para comprender las ventajas y desventajas de la velocidad y la precisión de este método.