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 aceitam sketches do HyperLogLog, o Looker pode usar 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 no reconhecimento de agregação.
Consulte a seção Suporte a dialetos para contagens distintas com reconhecimento de agregação nesta página para conferir a lista de dialetos que oferecem suporte a contagens distintas para tabelas de agregação usando esboços do HyperLogLog.
Em geral, as contagens distintas não podem ser usadas com a percepção de agregação porque não é possível obter 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 um intervalo de três semanas. 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 agregada que corresponda exatamente a uma consulta do recurso Detalhar, conforme descrito na página de documentação Reconhecimento de agregação. Quando a consulta da Análise e a consulta de uma tabela agregada são iguais, as medidas de contagem distinta fornecem dados precisos e podem ser usadas para reconhecimento de agregação.
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 confirmem que é permitido usar dados aproximados para a métrica, de modo que ela possa ser calculada aproximadamente em tabelas agregadas.
Com a percepção de agregação, há dois casos em que 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 medidacount_distinct. Conforme discutido na página de documentação Reconhecimento agregado, o Looker renderiza medidascountcomocount_distinctpara evitar erros de cálculo de fanout em análises detalhadas que combinam várias tabelas de banco de dados.
Em ambos os casos, se o dialeto for compatível com esboços HyperLogLog, você poderá adicionar a instrução allow_approximate_optimization: yes às métricas para ativar valores aproximados. Em seguida, é possível incluir 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 detalhada corresponderem perfeitamente às dimensões em uma tabela agregada, o Looker poderá fornecer dados exatos para contagens distintas, sem precisar fazer uma aproximação. Nesse caso, você vai ver na guia SQL da análise detalhada que medidas de contagem distintas estão sendo usadas para o 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 ela pode ser usada em um 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 de agregação 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 de agregação:
| 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+ | |
| 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 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 | |
| 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.