allow_approximate_optimization

Penggunaan

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

Nilai Default
no

Menerima
Boolean (ya atau tidak)

Definisi

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

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

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

Secara umum, jumlah unik tidak dapat didukung dengan penggabungan karena Anda tidak bisa mendapatkan data yang akurat jika mencoba menggabungkan jumlah unik. Misalnya, jika Anda menghitung pengguna unik di situs, mungkin ada pengguna yang mengunjungi situs dua kali, dengan selisih 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 solusi untuk masalah ini adalah membuat tabel gabungan yang sama persis dengan kueri Jelajah, seperti yang dijelaskan di halaman dokumentasi Pengenalan agregasi. Jika kueri Eksplorasi dan kueri tabel gabungan sama, ukuran jumlah unik memberikan data yang akurat, sehingga dapat digunakan untuk mengetahui kesadaran agregat.

Opsi lainnya adalah menggunakan perkiraan untuk jumlah unik. Algoritma HyperLogLog diketahui memiliki potensi error sekitar 2%. Parameter allow_approximate_optimization mengharuskan developer Looker Anda mengonfirmasi 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 unik berperan:

  • 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 perhitungan fanout di Eksplorasi 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 Eksplorasi cocok persis dengan dimensi dalam tabel gabungan, Looker dapat memberikan data yang tepat untuk jumlah unik, tanpa harus melakukan perkiraan. Dalam hal ini, Anda akan melihat di tab SQL Explore bahwa ukuran jumlah unik 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 bahwa 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 agregat

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

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+
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

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