Utilizzo
view: view_name {
measure: field_name {
allow_approximate_optimization: yes
}
}
|
Gerarchia
allow_approximate_optimization |
Tipi di campi disponibili
Misura
Valore predefinito
no
Accetta
Un valore booleano (sì o no)
|
Definizione
Per i dialetti che supportano gli sketch HyperLogLog, Looker può utilizzare l'algoritmo HyperLogLog per approssimare i conteggi distinti per le tabelle aggregate.
L'istruzione allow_approximate_optimization: yes consente a Looker di archiviare gli sketch HyperLogLog nelle tabelle aggregate, il che significa che Looker può utilizzare approssimazioni per i conteggi distinti per l'aggregate awareness.
Per l'elenco dei dialetti che supportano i conteggi distinti per le tabelle aggregate utilizzando gli sketch HyperLogLog, consulta la sezione Supporto dei dialetti per i conteggi distinti con l'awareness aggregata in questa pagina.
In generale, i conteggi distinti non possono essere supportati con l'awareness aggregata perché non è possibile ottenere dati accurati se si tenta di aggregare conteggi distinti. Ad esempio, se conteggi gli utenti unici su un sito web, potrebbe esserci un utente che ha visitato il sito web due volte, a distanza di tre settimane. Se provassi ad applicare una tabella aggregata settimanale per ottenere un conteggio mensile degli utenti distinti sul tuo sito web, l'utente verrebbe conteggiato due volte nella query di conteggio distinto mensile e i dati sarebbero errati.
Una soluzione alternativa consiste nel creare una tabella aggregata che corrisponda esattamente a una query di Esplora, come descritto nella pagina della documentazione relativa all'awareness aggregata. Quando la query di Esplora e una query della tabella aggregata sono uguali, le misure di conteggio distinte forniscono dati accurati, quindi possono essere utilizzate per l'awareness aggregata.
L'altra opzione è utilizzare le approssimazioni per i conteggi distinti. L'algoritmo HyperLogLog è noto per avere un potenziale errore di circa il 2%. Il parametro allow_approximate_optimization richiede agli sviluppatori Looker di confermare che è possibile utilizzare dati approssimativi per la misura, in modo che questa possa essere calcolata in modo approssimativo dalle tabelle aggregate.
Con l'awareness aggregata, esistono due casi in cui entrano in gioco i conteggi distinti:
- Il primo caso riguarda le misure di
type: count_distinct. - Il secondo caso riguarda le misure di
type: countche vengono effettivamente visualizzate da Looker come tipi di misuracount_distinct. Come descritto nella pagina della documentazione relativa alla consapevolezza aggregata, Looker esegue il rendering delle misurecountcomecount_distinctper evitare errori di calcolo del fanout nelle esplorazioni che uniscono più tabelle di database.
In entrambi i casi, se il tuo dialetto supporta gli sketch HyperLogLog, puoi aggiungere l'istruzione allow_approximate_optimization: yes alle misure per attivare i valori approssimativi. Puoi quindi includere queste misure nelle tabelle aggregate.
Anche per le misure definite con
allow_approximate_optimization: yes, Looker restituirà dati esatti, se possibile. Ad esempio, se le dimensioni di una query di esplorazione corrispondono perfettamente alle dimensioni di una tabella aggregata, Looker può fornire dati esatti per i conteggi distinti, senza doverli approssimare. In questo caso, nella scheda SQL di Esplora vedrai che vengono utilizzate misure di conteggio distinte per l'awareness aggregata senza l'utilizzo dell'algoritmo HyperLogLog.
Esempio
La misura apx_unique_count mostrata in questo esempio è impostata su allow_approximate_optimization: yes, il che significa che può essere utilizzata in un aggregate_table.
measure: apx_unique_count {
type: count_distinct
allow_approximate_optimization: yes # default value is no
sql: ${id} ;;
}
Supporto dei dialetti per i conteggi distinti con l'awareness aggregata
Looker può utilizzare i conteggi distinti per l'awareness aggregata con i dialetti del database che supportano gli sketch HyperLogLog. Nell'ultima release di Looker, i seguenti dialetti SQL sono supportati per i conteggi distinti con l'aggregate awareness:
| Dialetto | Supportata? |
|---|---|
| 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 documentazione del tuo dialetto SQL per comprendere i compromessi tra velocità e accuratezza di questo metodo.