Uso
view: view_name {
measure: field_name {
allow_approximate_optimization: yes
}
}
|
Hierarquia
allow_approximate_optimization |
Possíveis tipos de campo
Medida
Valor padrão
no
Aceita
Um booleano (sim ou não)
|
Definição
Para dialetos que aceitam esboços do HyperLogLog, o Looker pode usar o algoritmo HyperLogLog para aproximar contagens distintas de tabelas de agregação.
A instrução allow_approximate_optimization: yes permite que o Looker armazene esboços do HyperLogLog em tabelas de agregação, o que significa que o Looker pode usar aproximações para contagens distintas para reconhecimento de agregação.
Consulte a seção Suporte de dialeto para contagens distintas com reconhecimento de agregação nesta página para ver 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 são compatíveis com o reconhecimento de agregação porque não é possível receber dados precisos se você 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 de contagem mensal distinta, e os dados estariam incorretos.
Uma solução alternativa é criar uma tabela de agregação que corresponda exatamente a uma consulta de Análise, conforme descrito na página de documentação Reconhecimento de agregação. Quando a consulta da Análise e a consulta de uma tabela de agregação são iguais, as medidas de contagem distinta fornecem dados precisos, então podem ser usadas para reconhecimento de agregação.
A outra opção é usar aproximações para contagens distintas. O algoritmo HyperLogLog é conhecido por ter um erro potencial de cerca de 2%. O parâmetro allow_approximate_optimization exige que os desenvolvedores do Looker confirmem que é aceitável usar dados aproximados para a medição, de modo que ela possa ser calculada de forma aproximada com base em tabelas de agregação.
Com o reconhecimento de agregação, há dois casos em que as contagens distintas entram em jogo:
- O primeiro caso é com medidas de
type: count_distinct. - O segundo caso é com métricas de
type: countque estão sendo renderizadas pelo Looker como tipos de métricacount_distinct. Como discutido na página de documentação Reconhecimento agregado, o Looker renderiza as mediçõescountcomocount_distinctpara evitar erros de cálculo de fan-out em análises que unem várias tabelas de banco de dados.
Em ambos os casos, se o dialeto for compatível com esboços do HyperLogLog, você poderá adicionar a instrução allow_approximate_optimization: yes às métricas para ativar valores aproximados. Depois, inclua essas medições em tabelas de agregação.
Mesmo para medições 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 fazer aproximações. Nesse caso, você vai notar na guia SQL da Análise que as medições de contagem distinta estão sendo usadas para reconhecimento de agregação sem o algoritmo HyperLogLog.
Exemplo
A medição apx_unique_count mostrada neste exemplo está definida para 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 de dialeto para contagens distintas com reconhecimento de agregados
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 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.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 |
Consulte a documentação do seu dialeto SQL para entender as vantagens e desvantagens de velocidade e precisão desse método.