allow_approximate_optimization

Penggunaan

view: view_name {
  measure: field_name {
    allow_approximate_optimization: yes 
  }
}
Hierarki
view
Jenis Kolom
allow_approximate_optimization
Kemungkinan Jenis Kolom
Ukur

Nilai Default
no

Menerima
Boolean (ya atau tidak)

Definisi

Untuk dialek yang mendukung sketsa HyperLogLog, Looker dapat memanfaatkan algoritma HyperLogLog untuk memperkirakan jumlah yang berbeda untuk tabel gabungan.

Pernyataan allow_approximate_optimization: yes memungkinkan Looker menyimpan sketsa HyperLogLog dalam tabel gabungan, yang berarti Looker dapat menggunakan perkiraan untuk jumlah yang berbeda untuk aggregate awareness.

Lihat bagian Dukungan dialek untuk jumlah yang berbeda dengan awareness gabungan di halaman ini untuk mengetahui daftar dialek yang mendukung jumlah yang berbeda untuk tabel gabungan menggunakan sketsa HyperLogLog.

Secara umum, jumlah yang berbeda tidak dapat didukung dengan awareness gabungan karena Anda tidak bisa mendapatkan data yang akurat jika mencoba menggabungkan jumlah yang berbeda. Misalnya, jika Anda menghitung pengguna yang berbeda di situs, mungkin ada pengguna yang mengunjungi situs dua kali, dengan selisih waktu tiga minggu. Jika Anda mencoba menerapkan tabel gabungan mingguan untuk mendapatkan jumlah bulanan pengguna unik di situs Anda, pengguna tersebut akan dihitung dua kali dalam kueri jumlah unik bulanan Anda, dan datanya akan salah.

Salah satu solusinya adalah membuat tabel gabungan yang sama persis dengan kueri Explore, seperti yang dijelaskan di halaman dokumentasi Aggregate awareness. Jika kueri Eksplorasi dan kueri tabel gabungan sama, ukuran jumlah yang berbeda akan memberikan data yang akurat, sehingga dapat digunakan untuk awareness gabungan.

Opsi lainnya adalah menggunakan perkiraan untuk jumlah yang berbeda. Algoritma HyperLogLog diketahui memiliki potensi error sekitar 2%. Parameter allow_approximate_optimization mengharuskan developer Looker Anda mengonfirmasi bahwa data perkiraan boleh digunakan untuk ukuran tersebut sehingga ukuran tersebut dapat dihitung secara perkiraan dari tabel gabungan.

Dengan awareness gabungan, ada dua kasus yang melibatkan penghitungan yang berbeda:

  • Kasus pertama adalah dengan ukuran type: count_distinct.
  • Kasus kedua adalah dengan ukuran type: count yang sebenarnya dirender oleh Looker sebagai jenis ukuran count_distinct. Seperti yang dibahas di halaman dokumentasi Aggregate awareness, Looker merender ukuran count sebagai count_distinct untuk menghindari kesalahan penghitungan fanout di Explore yang menggabungkan beberapa tabel database.

Dalam kedua kasus ini, jika dialek Anda mendukung sketsa HyperLogLog, Anda dapat menambahkan pernyataan allow_approximate_optimization: yes ke ukuran untuk mengaktifkan nilai perkiraan. Kemudian, Anda dapat menyertakan ukuran ini dalam tabel gabungan.

Bahkan untuk ukuran yang ditentukan dengan allow_approximate_optimization: yes, Looker akan menampilkan data yang akurat jika memungkinkan. Misalnya, jika dimensi dalam kueri Explore sama persis dengan dimensi dalam tabel gabungan, Looker dapat memberikan data yang tepat untuk jumlah yang berbeda, tanpa harus melakukan perkiraan. Dalam hal ini, Anda akan melihat di tab SQL Explore bahwa ukuran jumlah yang berbeda digunakan untuk awareness gabungan tanpa menggunakan algoritma HyperLogLog.

Contoh

Ukuran apx_unique_count yang ditampilkan dalam contoh ini ditetapkan untuk allow_approximate_optimization: yes, yang berarti ukuran tersebut dapat digunakan dalam aggregate_table.

measure: apx_unique_count {
  type: count_distinct
    allow_approximate_optimization: yes   # default value is no
  sql: ${id} ;;
}

Dukungan dialek untuk jumlah yang berbeda dengan awareness gabungan

Looker dapat menggunakan jumlah yang berbeda untuk awareness gabungan dengan dialek database yang mendukung sketsa HyperLogLog. Dalam rilis Looker terbaru, dialek SQL berikut didukung untuk jumlah yang berbeda dengan awareness gabungan:

Dialek Didukung?
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

Periksa dokumentasi dialek SQL Anda untuk memahami konsekuensi kecepatan dan akurasi metode ini.