Uso
view: view_name {
measure: field_name {
allow_approximate_optimization: yes
}
}
|
Hierarquia
allow_approximate_optimization |
Tipos de campo possíveis
Medida
Valor padrão
no
Aceita
Um booleano (sim ou não)
|
Definição
Para dialetos que oferecem suporte a esboços do HyperLogLog, o Looker pode aproveitar o algoritmo HyperLogLog para aproximar contagens distintas de tabelas agregadas.
A instrução allow_approximate_optimization: yes permite que o Looker armazene esboços do HyperLogLog em tabelas agregadas, o que significa que o Looker pode usar aproximações para contagens distintas de reconhecimento agregado.
Consulte a seção Suporte a dialetos para contagens distintas com reconhecimento agregado nesta página para conferir a lista de dialetos que oferecem suporte a contagens distintas de tabelas agregadas usando esboços do HyperLogLog.
Em geral, as contagens distintas não podem ser oferecidas com reconhecimento agregado porque não é possível receber dados precisos ao tentar agregar contagens distintas. Por exemplo, se você estiver contando os usuários distintos em um site, pode haver um usuário que acessou o site duas vezes, com três semanas de diferença. Se você tentasse aplicar uma tabela de agregação semanal para receber uma contagem mensal de usuários distintos no seu site, esse usuário seria contado duas vezes na consulta mensal de contagem distinta, e os dados estariam incorretos.
Uma solução alternativa para isso é criar uma tabela de agregação que corresponda exatamente a uma consulta de Análise, conforme descrito na página de documentação sobre reconhecimento agregado. Quando a consulta de Análise e uma consulta de tabela de agregação são iguais, as medidas de contagem distinta fornecem dados precisos, para que possam ser usadas para reconhecimento agregado.
A outra opção é usar aproximações para contagens distintas. O algoritmo HyperLogLog tem um erro potencial de cerca de 2%. O parâmetro allow_approximate_optimization exige que os desenvolvedores do Looker reconheçam que é possível usar dados aproximados para a medida, para que ela possa ser calculada aproximadamente em tabelas agregadas.
Com o reconhecimento agregado, há dois casos em que as contagens distintas entram em jogo:
- O primeiro caso é com medidas de
type: count_distinct. - O segundo caso é com medidas de
type: countque estão sendo renderizadas pelo Looker como tipos de medidascount_distinct. Conforme discutido na página de documentação sobre reconhecimento agregado, o Looker renderiza medidascountcomocount_distinctpara evitar erros de cálculo de fanout em análises que unem várias tabelas de banco de dados.
Em ambos os casos, se o dialeto oferece suporte a esboços do HyperLogLog, você pode adicionar a instrução allow_approximate_optimization: yes às medidas para ativar valores aproximados. Em seguida, inclua essas medidas em tabelas agregadas.
Mesmo para medidas definidas com
allow_approximate_optimization: yes, o Looker vai retornar dados exatos quando possível. Por exemplo, se as dimensões em uma consulta de Análise forem uma correspondência perfeita das dimensões em uma tabela de agregação, o Looker poderá fornecer dados exatos para contagens distintas, sem precisar aproximar. Nesse caso, você verá na guia SQL da análise que as medidas de contagem distinta estão sendo usadas para reconhecimento agregado sem empregar o algoritmo HyperLogLog.
Exemplo
A medida apx_unique_count mostrada neste exemplo está definida como allow_approximate_optimization: yes, o que significa que a medida pode ser usada em uma aggregate_table.
measure: apx_unique_count {
type: count_distinct
allow_approximate_optimization: yes # default value is no
sql: ${id} ;;
}
Suporte a dialetos para contagens distintas com reconhecimento agregado
O Looker pode usar contagens distintas para reconhecimento agregado com dialetos de banco de dados que oferecem suporte a esboços do HyperLogLog. Na versão mais recente do Looker, os seguintes dialetos SQL são compatíveis com contagens distintas com reconhecimento agregado:
| Dialeto | Compatível? |
|---|---|
| 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 |
Consulte a documentação do dialeto SQL para entender as compensações de velocidade e precisão desse método.