allow_approximate_optimization

Penggunaan

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

Nilai Default
no

Menerima
Boolean (ya atau tidak)

Definisi

Untuk dialek yang mendukung sketsa HyperLogLog, Looker dapat memanfaatkan algoritma HyperLogLog untuk memperkirakan jumlah 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 berbeda untuk kesadaran gabungan.

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

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

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

Pilihan lainnya adalah menggunakan perkiraan untuk jumlah berbeda. Algoritma HyperLogLog diketahui memiliki potensi error sekitar 2%. Parameter allow_approximate_optimization mengharuskan developer Looker Anda mengakui bahwa tidak masalah menggunakan data perkiraan untuk ukuran sehingga ukuran dapat dihitung secara perkiraan dari tabel gabungan.

Dengan kesadaran gabungan, ada dua kasus saat jumlah berbeda berperan:

  • Kasus pertama adalah dengan ukuran type: count_distinct.
  • Kasus kedua adalah dengan ukuran type: count yang sebenarnya dirender oleh Looker sebagai count_distinct jenis ukuran. Seperti yang dibahas di halaman dokumentasi Kesadaran gabungan, Looker merender ukuran count sebagai count_distinct untuk menghindari kesalahan perhitungan fanout di Jelajah 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 tepat jika memungkinkan. Misalnya, jika dimensi dalam kueri Jelajah cocok dengan dimensi dalam tabel gabungan, Looker dapat memberikan data yang tepat untuk jumlah berbeda, tanpa harus memperkirakan. Dalam hal ini, Anda akan melihat di tab SQL Jelajah bahwa ukuran jumlah berbeda digunakan untuk kesadaran 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 berbeda dengan kesadaran gabungan

Looker dapat menggunakan jumlah berbeda untuk kesadaran gabungan dengan dialek database yang mendukung sketsa HyperLogLog. Dalam rilis Looker terbaru, dialek SQL berikut didukung untuk jumlah berbeda dengan kesadaran 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
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

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