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 bocetos de HyperLogLog, Looker puede aprovechar el algoritmo HyperLogLog para aproximar los recuentos distintos de las tablas de datos agregados.
La instrucción 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 datos agregados.
Consulta la sección Compatibilidad de dialectos con recuentos distintos con reconocimiento de datos agregados en esta página para obtener 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 datos agregados porque no puedes obtener datos precisos si intentas agregar recuentos distintos. Por ejemplo, si cuentas los usuarios distintos en un sitio web, es posible que haya un usuario que haya ingresado al sitio web dos veces, con tres semanas de diferencia. Si intentas aplicar una tabla de datos agregados semanal para obtener un recuento mensual de usuarios distintos en tu sitio web, ese usuario se contará dos veces en tu consulta de recuento mensual distinto, y los datos serán 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 de reconocimiento de datos agregados. Cuando la consulta de exploración y una consulta de tabla de datos agregados son las mismas, las medidas de recuento distinto proporcionan datos precisos, por lo que se pueden usar para el reconocimiento de datos agregados.
La otra opción es usar aproximaciones para recuentos distintos. Se sabe que el algoritmo HyperLogLog tiene un error potencial de aproximadamente el 2%. El parámetro allow_approximate_optimization requiere que tus desarrolladores de Looker reconozcan que está bien usar datos aproximados para la medida, de modo que la medida se pueda calcular de forma aproximada a partir de tablas de datos agregados.
Con el reconocimiento de datos agregados, hay dos casos en los que entran en juego los recuentos distintos:
- El primer caso es con medidas de
type: count_distinct. - El segundo caso es con medidas de
type: countque Looker renderiza como tipos de medidascount_distinct. Como se explica en la página de documentación de reconocimiento de datos agregados, Looker renderiza las medidascountcomocount_distinctpara evitar errores de cálculo de expansión en las exploraciones que unen varias tablas de bases de datos.
En ambos casos, si tu dialecto admite bocetos de HyperLogLog, puedes agregar la instrucción allow_approximate_optimization: yes a las medidas para habilitar valores aproximados. Luego, puedes incluir estas medidas en tablas de datos agregados.
Incluso para las medidas definidas con
allow_approximate_optimization: yes, Looker mostrará 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 recuentos distintos, sin tener que aproximarse. En este caso, verás en la pestaña SQL de la exploración que se usan medidas de recuento distinto para el reconocimiento de datos agregados sin emplear el algoritmo HyperLogLog.
Ejemplo
La medida apx_unique_count que se muestra en este ejemplo se establece en allow_approximate_optimization: yes, lo que significa que la medida se puede usar en una aggregate_table.
measure: apx_unique_count {
type: count_distinct
allow_approximate_optimization: yes # default value is no
sql: ${id} ;;
}
Compatibilidad de dialectos con recuentos distintos con reconocimiento de datos agregados
Looker puede usar recuentos distintos para el reconocimiento de datos agregados 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 recuentos distintos con reconocimiento de datos agregados:
| 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 | |
| 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 |
Consulta la documentación de tu dialecto de SQL para comprender las compensaciones de velocidad y precisión de este método.