Kesadaran agregat

Catatan: Untuk panduan tentang cara menerapkan kesadaran agregat, lihat juga halaman Praktik Terbaik tutorial kesadaran agregat kami.

Ringkasan

Looker menggunakan logika kesadaran gabungan untuk menemukan tabel terkecil dan paling efisien yang tersedia di database Anda untuk menjalankan kueri sekaligus tetap mempertahankan akurasi.

Untuk tabel yang sangat besar di database Anda, developer Looker dapat membuat tabel gabungan data yang lebih kecil, yang dikelompokkan menurut berbagai kombinasi atribut. Tabel gabungan berfungsi sebagai tabel gabungan atau ringkasan yang dapat digunakan Looker untuk kueri jika memungkinkan, bukan tabel besar asli. Jika diterapkan secara strategis, kesadaran gabungan dapat mempercepat kueri rata-rata dengan urutan magnitudo.

Misalnya, Anda mungkin memiliki tabel data skala petabyte dengan satu baris untuk setiap pesanan yang telah terjadi di situs Anda. Dari database ini, Anda dapat membuat tabel gabungan dengan total penjualan harian. Jika situs Anda menerima 1.000 pesanan setiap hari, tabel gabungan harian akan mewakili setiap hari dengan 999 baris lebih sedikit daripada tabel asli Anda. Anda dapat membuat tabel gabungan lain dengan total penjualan bulanan yang akan lebih efisien. Jadi, sekarang, jika pengguna menjalankan kueri untuk penjualan harian atau mingguan, Looker akan menggunakan tabel total penjualan harian. Jika pengguna menjalankan kueri tentang penjualan tahunan dan Anda tidak memiliki tabel gabungan tahunan, Looker akan menggunakan alternatif terbaik berikutnya, yaitu tabel gabungan penjualan bulanan dalam contoh ini.

Looker menjawab pertanyaan pengguna dengan tabel gabungan terkecil jika memungkinkan. Contoh:

• Untuk kueri tentang total penjualan bulanan, Looker menggunakan tabel gabungan berdasarkan penjualan bulanan (sales_monthly_aggregate_table).
• Untuk kueri tentang total setiap penjualan dalam sehari, tidak ada tabel gabungan dengan tingkat perincian tersebut, sehingga Looker mendapatkan hasil kueri dari tabel database asli (orders_database). (Namun, jika pengguna sering menjalankan jenis kueri ini, Anda dapat membuat tabel gabungan untuknya.)
• Untuk kueri tentang penjualan mingguan, tidak ada tabel gabungan mingguan, sehingga Looker menggunakan hal terbaik berikutnya, yaitu tabel gabungan berdasarkan penjualan harian (sales_daily_aggregate_table).

Dengan menggunakan logika kesadaran gabungan, Looker akan membuat kueri tabel gabungan terkecil untuk menjawab pertanyaan pengguna Anda. Tabel asli hanya akan digunakan untuk kueri yang memerlukan perincian yang lebih baik daripada yang dapat disediakan tabel agregat.

Tabel gabungan tidak perlu digabungkan atau ditambahkan ke Jelajahi terpisah. Sebagai gantinya, Looker secara dinamis menyesuaikan klausa FROM kueri Jelajah untuk mengakses tabel gabungan terbaik untuk kueri. Artinya, latihan Anda akan dipertahankan dan Jelajah dapat digabungkan. Dengan kesadaran gabungan, satu Jelajah dapat otomatis memanfaatkan tabel gabungan, tetapi tetap dapat mempelajari data terperinci jika diperlukan.

Anda juga dapat memanfaatkan tabel gabungan untuk meningkatkan performa dasbor secara drastis, terutama untuk kartu yang mengkueri set data besar. Untuk mengetahui detailnya, lihat bagian Mendapatkan LookML tabel gabungan dari dasbor di halaman dokumentasi parameter aggregate_table.

Menambahkan tabel gabungan ke project

Catatan: Agar dapat diakses untuk mengetahui agregat, tabel agregat harus dipertahankan di database Anda. Karena tabel gabungan adalah jenis tabel turunan persisten (PDT), tabel gabungan memiliki persyaratan yang sama dengan PDT. Lihat halaman dokumentasi Tabel turunan di Looker untuk mengetahui detailnya.

Developer Looker dapat membuat tabel agregat strategis yang akan meminimalkan jumlah kueri yang diperlukan pada tabel besar dalam database. Tabel gabungan harus dipertahankan ke database Anda agar dapat diakses untuk mengetahui gabungan. Oleh karena itu, tabel gabungan adalah jenis tabel turunan persisten (PDT).

Tabel gabungan ditentukan menggunakan parameter aggregate_table pada parameter explore di project LookML Anda.

Berikut adalah contoh explore dengan tabel gabungan di LookML:

explore: orders {
  label: "Sales Totals"
  join: order_items {
    sql_on: ${orders.id} = ${order_items.id} ;;
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [created_month]
      measures: [order_items.total_sales]
    }
  }
  # other explore parameters
}

Untuk membuat tabel gabungan, Anda dapat menulis LookML dari awal, atau mendapatkan LookML tabel gabungan dari Jelajah atau dari dasbor. Lihat halaman dokumentasi parameter aggregate_table untuk mengetahui detail parameter aggregate_table dan subparameternya.

Mendesain tabel gabungan

Agar kueri Eksplorasi dapat menggunakan tabel agregat, tabel agregat harus dapat memberikan data yang akurat untuk kueri Eksplorasi. Looker dapat menggunakan tabel gabungan untuk kueri Jelajahi jika semua hal berikut benar:

• Kolom kueri Jelajahi adalah subkumpulan kolom tabel gabungan (lihat bagian Faktor kolom di halaman ini). Atau, untuk jangka waktu, jangka waktu kueri Jelajah dapat berasal dari jangka waktu dalam tabel gabungan (lihat bagian Faktor jangka waktu di halaman ini).
• Kueri Jelajahi berisi jenis pengukuran yang didukung oleh kesadaran gabungan (lihat bagian Faktor jenis pengukuran di halaman ini), atau kueri Jelajahi memiliki tabel gabungan yang cocok persis (lihat bagian Membuat tabel gabungan yang cocok persis dengan kueri Jelajahi di halaman ini).
• Zona waktu kueri Jelajah cocok dengan zona waktu yang digunakan oleh tabel gabungan (lihat bagian Faktor zona waktu di halaman ini).
• Filter kueri Jelajah mereferensikan kolom yang tersedia sebagai dimensi dalam tabel gabungan, atau setiap filter kueri Jelajah cocok dengan filter dalam tabel gabungan (lihat bagian Faktor filter di halaman ini).

Salah satu cara untuk memastikan bahwa tabel gabungan dapat memberikan data yang akurat untuk kueri Jelajah adalah dengan membuat tabel gabungan yang sama persis dengan kueri Jelajah. Lihat bagian Membuat tabel gabungan yang sama persis dengan kueri Jelajahi di halaman ini untuk mengetahui detailnya.

Faktor kolom

Agar dapat digunakan untuk kueri Jelajah, tabel gabungan harus memiliki semua dimensi dan ukuran yang diperlukan untuk kueri Jelajah tersebut, termasuk kolom yang digunakan untuk filter dalam kueri Jelajah. Jika kueri Jelajahi berisi dimensi atau ukuran yang tidak ada dalam tabel gabungan, Looker tidak dapat menggunakan tabel gabungan dan akan menggunakan tabel dasar.

Misalnya, jika kueri mengelompokkan menurut dimensi A dan B, menggabungkan menurut ukuran C, dan memfilter pada dimensi D, tabel gabungan minimal harus memiliki A, B, dan D sebagai dimensi dan C sebagai ukuran.

Tabel gabungan juga dapat memiliki kolom lain, tetapi harus memiliki minimal kolom kueri Jelajahi agar dapat dioptimalkan. Satu-satunya pengecualian adalah dimensi jangka waktu, karena jangka waktu dengan perincian yang lebih kasar dapat berasal dari jangka waktu dengan perincian yang lebih halus.

Karena pertimbangan kolom ini, tabel gabungan bersifat khusus untuk Jelajah tempat tabel tersebut ditentukan. Tabel gabungan yang ditentukan di satu Jelajah tidak akan digunakan untuk kueri di Jelajah lain.

Faktor jangka waktu

Logika awareness gabungan Looker dapat memperoleh satu jangka waktu dari jangka waktu lainnya. Tabel gabungan dapat digunakan untuk kueri selama jangka waktu tabel gabungan memiliki tingkat perincian yang lebih baik (atau sama) seperti kueri Jelajahi. Misalnya, tabel gabungan berdasarkan data harian dapat digunakan untuk kueri Jelajahi yang memanggil jangka waktu lain, seperti kueri untuk data harian, bulanan, dan tahunan, atau bahkan data hari dalam sebulan, hari dalam setahun, dan minggu dalam setahun. Namun, tabel gabungan tahunan tidak dapat digunakan untuk kueri Jelajah yang memanggil data per jam, karena data tabel gabungan tidak memiliki tingkat perincian yang cukup baik untuk kueri Jelajah.

Hal yang sama berlaku untuk subset rentang waktu. Misalnya, jika Anda memiliki tabel gabungan yang difilter selama tiga bulan terakhir dan pengguna membuat kueri data dengan filter selama dua bulan terakhir, Looker akan dapat menggunakan tabel gabungan untuk kueri tersebut.

Selain itu, logika yang sama berlaku untuk kueri dengan filter jangka waktu: tabel gabungan dapat digunakan untuk kueri dengan filter jangka waktu selama jangka waktu tabel gabungan memiliki tingkat perincian yang lebih baik (atau sama) dengan filter jangka waktu yang digunakan dalam kueri Jelajahi. Misalnya, tabel gabungan yang memiliki dimensi jangka waktu harian dapat digunakan untuk kueri Jelajah yang memfilter berdasarkan hari, minggu, atau bulan.

Faktor jenis pengukuran

Agar kueri Eksplorasi dapat menggunakan tabel agregat, ukuran di tabel agregat harus dapat memberikan data yang akurat untuk kueri Eksplorasi.

Oleh karena itu, hanya jenis pengukuran tertentu yang didukung, seperti yang dijelaskan di bagian berikut:

• Pengukuran dengan jenis pengukuran yang didukung
• Pengukuran yang ditentukan oleh ekspresi SQL
• Ukuran yang tidak ditentukan dengan ${TABLE}
• Pengukuran yang mendekati jumlah yang berbeda

Jika kueri Jelajah menggunakan jenis pengukuran lainnya, Looker akan menggunakan tabel asli, bukan tabel gabungan, untuk menampilkan hasil. Satu-satunya pengecualian adalah jika kueri Jelajahi sama persis dengan kueri tabel gabungan, seperti yang dijelaskan di bagian Membuat tabel gabungan yang sama persis dengan kueri Jelajahi.

Jika tidak, Looker akan menggunakan tabel asli, bukan tabel gabungan, untuk menampilkan hasil.

Pengukuran dengan jenis pengukuran yang didukung

Awareness gabungan dapat digunakan untuk kueri Jelajahi yang menggunakan ukuran dengan jenis ukuran berikut:

• sum
• count
• min
• max
• average

Catatan: Jika Eksplorasi menggabungkan beberapa tabel database, Looker dapat merender ukuran dari jenis SUM, COUNT, dan AVERAGE sebagai SUM DISTINCT, COUNT DISTINCT, dan AVERAGE DISTINCT. Looker melakukan hal ini untuk menghindari kesalahan penghitungan fanout, seperti yang dijelaskan di bagian Aggregate simetris untuk Jelajah dengan join di halaman ini.

Untuk menggunakan tabel gabungan untuk kueri Jelajah, Looker harus dapat beroperasi pada ukuran tabel gabungan untuk memberikan data yang akurat dalam kueri Jelajah. Misalnya, ukuran dengan type: sum dapat digunakan untuk mengetahui jumlah total karena Anda dapat menjumlahkan beberapa jumlah: Tabel gabungan jumlah mingguan dapat ditambahkan untuk mendapatkan jumlah bulanan yang akurat. Demikian pula, ukuran dengan type: max dapat digunakan karena tabel gabungan maksimum harian dapat digunakan untuk menemukan maksimum mingguan yang akurat.

Dalam kasus pengukuran dengan type: average, kesadaran gabungan didukung karena Looker menggunakan data jumlah dan jumlah untuk memperoleh nilai rata-rata secara akurat dari tabel gabungan.

Metrik yang ditentukan dengan ekspresi SQL

Kesadaran gabungan juga dapat digunakan dengan ukuran yang ditentukan dengan ekspresi dalam parameter sql. Jika ditentukan dengan ekspresi SQL, jenis pengukuran berikut juga didukung:

• number
• date
• string
• yesno

Kesadaran gabungan didukung untuk tindakan yang ditentukan sebagai kombinasi tindakan lain, seperti contoh ini:

measure: total_revenue_in_dollars {
  type: number
  sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}

Kesadaran gabungan juga didukung untuk pengukuran yang penghitungannya ditentukan dalam parameter sql, seperti pengukuran ini:

measure: wholesale_value {
  type: number
    sql: (${order_items.total_sale_price} * 0.60) ;;
}

Selain itu, kesadaran agregat didukung untuk ukuran yang operasi MIN, MAX, dan COUNT-nya ditentukan dalam parameter sql, seperti ukuran ini:

measure: most_recent_order_date {
  type: date
  sql: MAX(${users.created_at_raw})
}

Peringatan: Kesadaran agregat hanya didukung untuk operasi MIN(), MAX(), dan COUNT(). Jika ingin menggunakan ukuran rata-rata atau jumlah di tabel gabungan, Anda dapat membuat ukuran type: average atau type: sum, yang keduanya didukung untuk awareness gabungan.

Pengukuran yang merujuk ke kolom LookML

Saat ekspresi sql digunakan dalam pengukuran, kesadaran gabungan mendukung jenis referensi kolom berikut:

• Referensi yang menggunakan format ${view_name.field_name}, yang menunjukkan kolom di tampilan lain
• Referensi menggunakan format ${field_name}, yang menunjukkan kolom dalam tampilan yang sama

Kesadaran gabungan tidak didukung untuk ukuran yang ditentukan menggunakan format ${TABLE}.column_name, yang menunjukkan kolom dalam tabel. (Lihat halaman dokumentasi Menggabungkan SQL dan merujuk ke objek LookML untuk mengetahui ringkasan penggunaan referensi di LookML.)

Misalnya, ukuran yang ditentukan dengan parameter sql ini tidak akan didukung dalam tabel gabungan, karena menggunakan format ${TABLE}.column_name:

measure: wholesale_value {
  type: number
  sql: (${TABLE}.total_sale_price * 0.60) ;;
}

Jika ingin menyertakan ukuran ini dalam tabel gabungan, Anda dapat membuat dimensi yang ditentukan dengan format ${TABLE}.column_name, lalu membuat ukuran yang mereferensikan dimensi tersebut, seperti ini:

 dimension: total_sale_price {
    sql: (${TABLE}.total_sale_price) ;;
  }

  measure: wholesale_value {
    type: number
    sql: (${total_sale_price} * 0.60) ;;
}

Sekarang Anda dapat menggunakan ukuran wholesale_value di tabel gabungan.

Pengukuran yang memperkirakan jumlah yang berbeda

Secara umum, jumlah yang berbeda tidak didukung dengan awareness gabungan karena Anda tidak bisa mendapatkan data yang akurat jika mencoba menggabungkan jumlah yang berbeda. Misalnya, jika Anda menghitung pengguna unik 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 unik di situs Anda, pengguna tersebut akan dihitung dua kali dalam kueri jumlah unik bulanan, dan datanya akan salah.

Salah satu solusi untuk hal ini adalah membuat tabel gabungan yang sama persis dengan kueri Jelajahi, seperti yang dijelaskan di bagian Membuat tabel gabungan yang sama persis dengan kueri Jelajahi di halaman ini. Jika kueri Eksplorasi dan kueri tabel gabungan sama, ukuran jumlah yang berbeda akan memberikan data yang akurat, sehingga dapat digunakan untuk mengetahui jumlah total.

Opsi lainnya adalah menggunakan perkiraan untuk jumlah yang berbeda. Untuk dialek yang mendukung sketsa HyperLogLog, Looker dapat memanfaatkan algoritma HyperLogLog untuk memperkirakan jumlah yang berbeda untuk tabel agregat.

Algoritma HyperLogLog diketahui memiliki error sekitar 2%. Parameter allow_approximate_optimization: yes mengharuskan developer Looker Anda mengonfirmasi bahwa penggunaan data perkiraan untuk ukuran tidak masalah sehingga ukuran dapat dihitung secara perkiraan dari tabel gabungan.

Lihat halaman dokumentasi parameter allow_approximate_optimization untuk mengetahui informasi selengkapnya dan daftar dialek yang mendukung count distinct menggunakan HyperLogLog.

Faktor zona waktu

Dalam banyak kasus, admin database menggunakan UTC sebagai zona waktu untuk database. Namun, banyak pengguna mungkin tidak berada di zona waktu UTC. Looker memiliki beberapa opsi untuk mengonversi zona waktu sehingga pengguna akan mendapatkan hasil kueri di zona waktu mereka sendiri:

• Zona waktu kueri, setelan yang berlaku untuk semua kueri pada koneksi database. Jika semua pengguna berada di zona waktu yang sama, Anda dapat menetapkan satu zona waktu kueri sehingga semua kueri dikonversi dari zona waktu database menjadi zona waktu kueri.
• Zona waktu khusus pengguna, tempat pengguna dapat ditetapkan dan memilih zona waktu satu per satu. Dalam hal ini, kueri dikonversi dari zona waktu database menjadi zona waktu pengguna individual.

Lihat halaman dokumentasi Menggunakan setelan zona waktu untuk mengetahui informasi selengkapnya tentang opsi ini.

Konsep ini penting untuk memahami kesadaran gabungan karena, agar tabel gabungan dapat digunakan untuk kueri dengan dimensi tanggal atau filter tanggal, zona waktu di tabel gabungan harus cocok dengan setelan zona waktu yang digunakan untuk kueri asli.

Tabel gabungan menggunakan zona waktu database jika tidak ada nilai timezone yang ditentukan. Koneksi database Anda juga akan menggunakan zona waktu database jika salah satu kondisi berikut benar:

• Database Anda tidak mendukung zona waktu.
• Zona waktu kueri koneksi database Anda ditetapkan ke zona waktu yang sama dengan zona waktu database.
• Koneksi database Anda tidak memiliki zona waktu kueri yang ditentukan atau zona waktu khusus pengguna. Jika demikian, koneksi database Anda akan menggunakan zona waktu database.

Jika salah satu hal di atas benar, Anda dapat menghapus parameter timezone untuk tabel agregat.

Jika tidak, zona waktu tabel gabungan harus ditentukan agar cocok dengan kemungkinan kueri sehingga tabel gabungan lebih cenderung digunakan:

• Jika koneksi database Anda menggunakan satu zona waktu kueri, Anda harus mencocokkan nilai timezone tabel agregat dengan nilai zona waktu kueri.
• Jika koneksi database Anda menggunakan zona waktu khusus pengguna, Anda harus membuat tabel gabungan yang identik, masing-masing dengan nilai timezone yang berbeda untuk mencocokkan kemungkinan zona waktu pengguna Anda.

Peringatan: Looker tidak dapat menggunakan tabel gabungan untuk kueri Jelajahi jika zona waktu di tabel gabungan tidak cocok dengan zona waktu di kueri Jelajahi. Jika koneksi database Anda memiliki zona waktu khusus pengguna, artinya Anda memerlukan tabel gabungan terpisah untuk setiap zona waktu pengguna.

Faktor filter

Berhati-hatilah saat menyertakan filter dalam tabel gabungan. Filter pada tabel gabungan dapat mempersempit hasil hingga titik tabel gabungan tidak dapat digunakan. Misalnya, Anda membuat tabel gabungan untuk jumlah pesanan harian, dan tabel gabungan tersebut memfilter hanya pesanan kacamata hitam yang berasal dari Australia. Jika pengguna menjalankan kueri Jelajah untuk jumlah pesanan kacamata hitam harian di seluruh dunia, Looker tidak dapat menggunakan tabel gabungan untuk kueri Jelajah tersebut, karena tabel gabungan hanya memiliki data untuk Australia. Tabel gabungan memfilter data terlalu sempit untuk digunakan oleh kueri Jelajahi.

Selain itu, perhatikan filter yang mungkin telah dibuat oleh developer Looker ke dalam Jelajahi, seperti:

• access_filters: Menerapkan pembatasan data khusus pengguna.
• always_filter: Mewajibkan pengguna menyertakan kumpulan filter tertentu untuk kueri Jelajahi. Pengguna dapat mengubah nilai filter default untuk kueri mereka, tetapi tidak dapat menghapus filter sepenuhnya.
• conditionally_filter: Menentukan kumpulan filter default yang dapat diganti pengguna jika mereka menerapkan setidaknya satu filter dari daftar kedua yang juga ditentukan di Jelajahi.

Jenis filter ini didasarkan pada kolom tertentu. Jika Jelajah memiliki filter ini, Anda harus menyertakan kolomnya dalam parameter dimensions dari aggregate_table.

Misalnya, berikut adalah Eksplorasi dengan filter akses yang didasarkan pada kolom orders.region:

explore: orders {
  access_filter: {
    field: orders.region
    user_attribute: region
  }
}

Untuk membuat tabel gabungan yang akan digunakan untuk Jelajah ini, tabel gabungan harus menyertakan kolom yang menjadi dasar filter akses. Pada contoh berikutnya, filter akses didasarkan pada kolom orders.region, dan kolom yang sama ini disertakan sebagai dimensi dalam tabel gabungan:

explore: orders {
  access_filter: {
    field: orders.region  # <-- orders.region field
    user_attribute: region
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [orders.created_day, orders.region] # <-- orders.region field
      measures: [orders.total_sales]
      timezone: America/Los_Angeles
    }
  }
}

Karena kueri tabel gabungan menyertakan dimensi orders.region, Looker dapat memfilter data secara dinamis dalam tabel gabungan agar cocok dengan filter dari kueri Eksplorasi. Oleh karena itu, Looker masih dapat menggunakan tabel gabungan untuk kueri Jelajah, meskipun Jelajah memiliki filter akses.

Hal ini juga berlaku untuk kueri Jelajah yang menggunakan tabel turunan native yang dikonfigurasi dengan bind_filters. Parameter bind_filters meneruskan filter yang ditentukan dari kueri Jelajahi ke subkueri tabel turunan native. Dalam kasus awareness gabungan, jika kueri Jelajah Anda memerlukan tabel turunan native yang menggunakan bind_filters, kueri Jelajah hanya dapat menggunakan tabel gabungan jika semua kolom yang digunakan dalam parameter bind_filters tabel turunan native memiliki nilai filter yang sama persis dalam kueri Jelajah seperti dalam tabel gabungan.

Membuat tabel gabungan yang sama persis dengan kueri Jelajahi

Salah satu cara untuk memastikan bahwa tabel agregat dapat digunakan untuk kueri Jelajah adalah dengan membuat tabel agregat yang sama persis dengan kueri Jelajah. Jika kueri Jelajahi dan tabel gabungan menggunakan ukuran, dimensi, filter, zona waktu, dan parameter lainnya yang sama, maka menurut definisi, hasil tabel gabungan akan berlaku untuk kueri Jelajahi. Jika tabel gabungan cocok persis dengan kueri Jelajahi, Looker dapat menggunakan tabel gabungan yang menyertakan jenis pengukuran apa pun.

Anda dapat membuat tabel gabungan dari Jelajahi menggunakan opsi Dapatkan LookML dari menu roda gigi Jelajahi. Anda juga dapat membuat kecocokan persis untuk semua kartu di dasbor menggunakan opsi Get LookML dari menu roda gigi di dasbor.

Menentukan tabel agregat yang digunakan untuk kueri

Pengguna dengan izin see_sql dapat menggunakan komentar di tab SQL pada Jelajah untuk melihat tabel gabungan mana yang akan digunakan untuk kueri. Komentar tab SQL juga ditampilkan dalam Mode Pengembangan, sehingga developer dapat menguji tabel gabungan baru untuk melihat cara Looker menggunakannya sebelum Anda mendorong tabel baru ke produksi.

Misalnya, berdasarkan contoh tabel gabungan bulanan yang ditampilkan sebelumnya, Anda dapat membuka Jelajahi dan menjalankan kueri untuk total penjualan tahunan. Kemudian, Anda dapat mengklik tab SQL untuk melihat detail kueri yang dibuat Looker. Jika Anda berada dalam Mode Pengembangan, Looker akan menampilkan komentar untuk menunjukkan tabel agregat yang digunakan untuk kueri.

Dari komentar berikut di tab SQL, kita dapat melihat bahwa Looker menggunakan tabel gabungan sales_monthly untuk kueri ini, dan informasi tentang alasan tabel gabungan lainnya tidak digunakan untuk kueri:

-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date

Lihat bagian Pemecahan masalah di halaman ini untuk mengetahui kemungkinan komentar yang mungkin Anda lihat di tab SQL dan saran tentang cara mengatasinya.

Estimasi penghematan komputasi untuk kesadaran agregat

Jika koneksi database Anda mendukung estimasi biaya dan jika tabel gabungan dapat digunakan untuk kueri, jendela Jelajahi akan menampilkan penghematan komputasi dari penggunaan tabel gabungan, bukan mengkueri database secara langsung. Penghematan awareness gabungan ditampilkan di samping tombol Jalankan di Jelajahi sebelum kueri dijalankan.

Sebelum menjalankan kueri, jika ingin melihat tabel agregat yang akan digunakan untuk kueri, Anda dapat mengklik tab SQL, seperti yang dijelaskan di bagian Menentukan tabel agregat yang digunakan untuk kueri di halaman dokumentasi ini.

Setelah kueri dijalankan, jendela Jelajahi akan menampilkan tabel gabungan yang digunakan untuk menjawab kueri di samping tombol Jalankan.

Penghematan awareness gabungan ditampilkan untuk koneksi database yang diaktifkan untuk perkiraan biaya. Lihat halaman dokumentasi Menjelajahi data di Looker untuk mengetahui informasi selengkapnya.

Looker menggabungkan data baru ke tabel gabungan Anda

Untuk tabel gabungan dengan filter waktu, Looker dapat menggabungkan data baru ke dalam tabel gabungan Anda. Anda mungkin memiliki tabel gabungan yang menyertakan data selama tiga hari terakhir, tetapi tabel gabungan tersebut mungkin dibuat kemarin. Tabel gabungan tidak akan memiliki informasi hari ini, sehingga Anda tidak dapat menggunakannya untuk kueri Jelajahi tentang informasi harian terbaru.

Namun, Looker masih dapat menggunakan data dalam tabel gabungan tersebut untuk kueri karena Looker akan menjalankan kueri pada data terbaru, lalu menggabungkan hasil tersebut ke dalam hasil di tabel gabungan.

Looker dapat menggabungkan data baru dengan data tabel agregat Anda dengan mempertimbangkan situasi berikut:

• Tabel gabungan memiliki filter waktu.
• Tabel gabungan menyertakan dimensi berdasarkan kolom waktu yang sama dengan filter waktu.

Misalnya, tabel gabungan berikut memiliki dimensi berdasarkan kolom orders.created_date, dan memiliki filter waktu ("3 days") berdasarkan kolom yang sama:

aggregate_table: sales_last_3_days {
  query:  {
    dimensions: [orders.created_date]
    measures: [order_items.total_sales]
    filters: [orders.created_date: "3 days"]  # <-- time filter
    timezone: America/Los_Angeles
  }
  ...
}

Jika tabel gabungan ini dibuat kemarin, Looker akan mengambil data terbaru yang belum disertakan dalam tabel gabungan, lalu menggabungkan hasil baru dengan hasil dari tabel gabungan. Artinya, pengguna Anda akan mendapatkan data terbaru sekaligus tetap mengoptimalkan performa menggunakan awareness gabungan.

Jika berada dalam Mode Pengembangan, Anda dapat mengklik tab SQL di Jelajah untuk melihat tabel gabungan yang digunakan Looker untuk kueri, dan pernyataan UNION yang digunakan Looker untuk memasukkan data yang lebih baru yang tidak disertakan dalam tabel gabungan.

Catatan: Jika Looker tidak dapat menggabungkan data baru dengan tabel gabungan Anda, Looker akan menggunakan data yang ada dari tabel gabungan.

Tabel gabungan harus dipertahankan

Agar dapat diakses untuk mengetahui agregat, tabel agregat Anda harus dipertahankan di database. Strategi persistensi ditentukan dalam parameter materialization tabel gabungan. Karena tabel gabungan adalah jenis tabel turunan persisten (PDT), tabel gabungan memiliki persyaratan yang sama dengan PDT. Lihat halaman dokumentasi Tabel turunan di Looker untuk mengetahui detailnya.

Anda dapat membuat PDT inkremental dalam project jika dialek Anda mendukungnya. Looker membuat PDT inkremental dengan menambahkan data baru ke tabel, bukan membuat ulang tabel secara keseluruhan. Karena tabel agregat itu sendiri merupakan jenis PDT, Anda juga dapat membuat tabel agregat inkremental. Lihat halaman dokumentasi PDT Inkremental untuk mengetahui informasi selengkapnya tentang PDT inkremental. Lihat halaman dokumentasi parameter increment_key untuk mengetahui contoh tabel agregat inkremental.

Pengguna dengan izin develop dapat mengganti setelan persistensi dan membuat ulang semua tabel gabungan untuk kueri guna mendapatkan data terbaru. Untuk membuat ulang tabel untuk kueri, pilih opsi Buat Ulang Tabel Turunan & Jalankan dari menu roda gigi Jelajahi tindakan.

Anda harus menunggu kueri Jelajah dimuat sebelum opsi ini tersedia.

Opsi Build Derived Tables & Run mem-build ulang semua tabel turunan yang dirujuk dalam kueri serta tabel turunan apa pun yang bergantung pada tabel dalam kueri. Hal ini mencakup tabel agregat, yang merupakan jenis tabel turunan persisten.

Untuk pengguna yang memulai opsi Rebuild Derived Tables & Run, kueri akan menunggu tabel dibuat ulang sebelum memuat hasil. Kueri pengguna lain akan tetap menggunakan tabel yang ada. Setelah tabel persisten dibuat ulang, semua pengguna akan menggunakan tabel yang dibuat ulang.

Lihat halaman dokumentasi Tabel turunan di Looker untuk mengetahui detail selengkapnya tentang opsi Rebuild Derived Tables & Run.

Pemecahan masalah

Seperti yang dijelaskan di bagian Menentukan tabel agregat yang digunakan untuk kueri, jika Anda berada dalam Mode Pengembangan, Anda dapat menjalankan kueri di Jelajahi dan mengklik tab SQL untuk melihat komentar tentang tabel agregat yang digunakan untuk kueri, jika ada.

Tab SQL juga menyertakan komentar tentang alasan tabel gabungan tidak digunakan untuk kueri, jika memang demikian. Untuk tabel gabungan yang tidak digunakan, komentar akan dimulai dengan:

Did not use [explore name]::[aggregate table name];

Misalnya, berikut adalah komentar tentang alasan tabel gabungan sales_daily yang ditentukan di Jelajahi order_items tidak digunakan untuk kueri:

-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.

Dalam hal ini, filter dalam kueri mencegah penggunaan tabel gabungan.

Tabel berikut menunjukkan beberapa kemungkinan alasan lain mengapa tabel gabungan tidak dapat digunakan, beserta langkah-langkah yang dapat Anda lakukan untuk meningkatkan kegunaan tabel gabungan.

Alasan tidak menggunakan tabel gabungan	Penjelasan dan kemungkinan langkah
Tidak ada kolom tersebut di Eksplorasi.	Ada error jenis validasi LookML. Hal ini kemungkinan besar karena tabel gabungan tidak ditentukan dengan benar, atau ada kesalahan ketik dalam LookML untuk tabel gabungan Anda. Penyebab yang mungkin terjadi adalah nama kolom yang salah, atau sejenisnya. Untuk mengatasinya, pastikan dimensi dan ukuran dalam tabel gabungan cocok dengan nama kolom di Eksplorasi. Lihat halaman dokumentasi parameter aggregate_table untuk mengetahui informasi selengkapnya tentang cara menentukan tabel gabungan.
Tabel gabungan tidak menyertakan kolom berikut dalam kueri.	Agar dapat digunakan untuk kueri Jelajah, tabel gabungan harus memiliki semua dimensi dan ukuran yang diperlukan untuk kueri Jelajah tersebut, termasuk kolom yang digunakan untuk filter dalam kueri Jelajah. Jika kueri Jelajah berisi dimensi atau ukuran yang tidak ada dalam tabel gabungan, Looker tidak dapat menggunakan tabel gabungan dan akan menggunakan tabel dasar. Lihat bagian Faktor kolom di halaman ini untuk mengetahui detailnya. Satu-satunya pengecualian adalah dimensi jangka waktu, karena jangka waktu dengan perincian yang lebih kasar dapat berasal dari jangka waktu dengan perincian yang lebih halus. Untuk mengatasinya, pastikan kolom kueri Eksplorasi disertakan dalam definisi tabel gabungan.
Kueri berisi filter berikut yang tidak disertakan sebagai kolom atau tidak cocok persis dengan filter dalam tabel gabungan.	Filter dalam kueri Jelajahi mencegah Looker menggunakan tabel gabungan. Untuk mengatasinya, Anda dapat melakukan salah satu tindakan berikut: Tambahkan filter yang sama ke tabel gabungan Anda. Tambahkan kolom yang digunakan filter ke tabel agregat Anda. Hapus filter dari kueri Jelajahi. Lihat bagian Faktor filter di halaman ini untuk mengetahui detailnya.
Kueri berisi ukuran berikut yang tidak dapat digabungkan.	Kueri berisi satu atau beberapa jenis pengukuran yang tidak didukung untuk kesadaran gabungan, seperti jumlah berbeda, median, atau persentil. Untuk mengatasinya, periksa jenis setiap ukuran dalam kueri dan pastikan ukuran tersebut merupakan salah satu jenis ukuran yang didukung. Selain itu, jika Jelajah memiliki join, pastikan ukuran Anda tidak dikonversi menjadi ukuran yang berbeda (agregat simetris) melalui join yang diperluas. Lihat bagian Aggregate simetris untuk Jelajah dengan join di halaman ini untuk mengetahui penjelasannya.
Tabel gabungan yang berbeda lebih cocok untuk pengoptimalan.	Ada beberapa tabel gabungan yang valid untuk kueri tersebut dan Looker menemukan tabel gabungan yang lebih optimal untuk digunakan. Dalam kasus ini, Anda tidak perlu melakukan apa pun.
Looker tidak melakukan pengelompokan apa pun (karena parameter primary_key atau cancel_grouping_fields), sehingga kueri tidak dapat digabungkan.	Kueri mereferensikan dimensi yang mencegahnya memiliki klausa GROUP BY, sehingga Looker tidak dapat menggunakan tabel gabungan apa pun untuk kueri tersebut. Untuk mengatasinya, pastikan parameter primary_key tampilan dan parameter cancel_grouping_fields Jelajah disiapkan dengan benar.
Tabel gabungan berisi filter yang tidak ada dalam kueri.	Tabel gabungan memiliki filter non-waktu yang tidak ada dalam kueri. Untuk mengatasinya, Anda dapat menghapus filter dari tabel gabungan. Lihat bagian Faktor filter di halaman ini untuk mengetahui detailnya.
Kolom ditentukan sebagai kolom khusus filter dalam kueri Jelajahi, tetapi tercantum dalam parameter dimensions tabel gabungan.	Parameter dimensions tabel gabungan mencantumkan kolom yang hanya ditentukan sebagai kolom filter dalam kueri Jelajahi. Untuk mengatasinya, hapus kolom dari daftar dimensions tabel gabungan. Jika kolom ini diperlukan untuk tabel gabungan, tambahkan ke daftar filters dalam kueri tabel gabungan.
Pengoptimal tidak dapat menentukan alasan tabel gabungan tidak digunakan.	Komentar ini disediakan untuk kasus ekstrem. Jika melihat pesan ini untuk kueri Jelajah yang sering digunakan, Anda dapat membuat tabel gabungan yang sama persis dengan kueri Jelajah. Anda dapat dengan mudah mendapatkan LookML tabel gabungan dari Jelajahi, seperti yang dijelaskan di halaman parameter aggregate_table.

Hal-hal yang perlu dipertimbangkan

Agregat simetris untuk Jelajah dengan join

Satu hal penting yang perlu diperhatikan adalah dalam Jelajah yang menggabungkan beberapa tabel database, Looker dapat merender ukuran jenis SUM, COUNT, dan AVERAGE sebagai SUM DISTINCT, COUNT DISTINCT, dan AVERAGE DISTINCT. Looker melakukan hal ini untuk menghindari kesalahan penghitungan fanout. Misalnya, pengukuran count dirender sebagai jenis pengukuran count_distinct. Hal ini untuk menghindari kesalahan penghitungan fanout untuk join, dan merupakan bagian dari fungsi agregat simetris Looker. Lihat halaman Praktik Terbaik tentang agregat simetris untuk penjelasan tentang fitur Looker ini.

Fungsi agregat simetris mencegah kesalahan penghitungan, tetapi juga dapat mencegah tabel agregat Anda digunakan dalam kasus tertentu, sehingga penting untuk dipahami.

Untuk jenis pengukuran yang didukung oleh awareness gabungan, hal ini berlaku untuk sum, count, dan average. Looker akan merender jenis ukuran ini sebagai DISTINCT jika:

• Pengukuran berasal dari tampilan "satu" dari join many-to-one atau one-to-many.
• Pengukuran ini berasal dari salah satu tampilan join many-to-many.

Lihat halaman dokumentasi parameter relationship untuk mengetahui penjelasan tentang jenis join ini.

Jika menemukan bahwa tabel gabungan tidak digunakan karena alasan ini, Anda dapat membuat tabel gabungan agar cocok persis dengan kueri Jelajah untuk menggunakan jenis pengukuran ini untuk Jelajah dengan join. Lihat bagian Membuat tabel gabungan yang sama persis dengan kueri Jelajahi di halaman ini untuk mengetahui informasi selengkapnya.

Selain itu, jika memiliki dialek SQL yang mendukung sketsa HyperLogLog, Anda dapat menambahkan parameter allow_approximate_optimization: yes ke pengukuran. Jika ukuran jumlah ditentukan dengan allow_approximate_optimization: yes, Looker dapat menggunakan ukuran tersebut untuk mengetahui jumlah gabungan, meskipun dirender sebagai jumlah yang berbeda.

Lihat halaman dokumentasi parameter allow_approximate_optimization untuk mengetahui detailnya, dan untuk mengetahui daftar dialek SQL yang mendukung sketsa HyperLogLog.

Dukungan dialek untuk kesadaran agregat

Kemampuan untuk menggunakan awareness gabungan bergantung pada dialek database yang digunakan koneksi Looker Anda. Dalam rilis Looker terbaru, dialek berikut mendukung awareness gabungan:

Catatan: BigQuery Legacy SQL mendukung awareness gabungan, tetapi tidak mendukung penggabungan data baru dengan data tabel gabungan Anda.

Dialek	Didukung?
Actian Avalanche	Ya
Amazon Athena	Ya
Amazon Aurora MySQL	Ya
Amazon Redshift	Ya
Apache Druid	Tidak
Apache Druid 0.13+	Tidak
Apache Druid 0.18+	Tidak
Apache Hive 2.3+	Ya
Apache Hive 3.1.2+	Ya
Apache Spark 3+	Ya
ClickHouse	Tidak
Cloudera Impala 3.1+	Ya
Cloudera Impala 3.1+ dengan Driver Native	Ya
Cloudera Impala dengan Driver Native	Ya
DataVirtuality	Tidak
Databricks	Ya
Denodo 7	Tidak
Denodo 8	Tidak
Dremio	Tidak
Dremio 11+	Tidak
Exasol	Ya
Firebolt	Tidak
Legacy SQL Google BigQuery	Ya
SQL Standar Google BigQuery	Ya
Google Cloud PostgreSQL	Ya
Google Cloud SQL	Tidak
Google Spanner	Tidak
Greenplum	Ya
HyperSQL	Tidak
IBM Netezza	Ya
MariaDB	Ya
Microsoft Azure PostgreSQL	Ya
Microsoft Azure SQL Database	Ya
Microsoft Azure Synapse Analytics	Ya
Microsoft SQL Server 2008+	Ya
Microsoft SQL Server 2012+	Ya
Microsoft SQL Server 2016	Ya
Microsoft SQL Server 2017+	Ya
MongoBI	Tidak
MySQL	Ya
MySQL 8.0.12+	Ya
Oracle	Ya
Oracle ADWC	Ya
PostgreSQL 9.5+	Ya
PostgreSQL versi pra-9.5	Ya
PrestoDB	Ya
PrestoSQL	Ya
SAP HANA 2+	Ya
SingleStore	Ya
SingleStore 7+	Ya
Snowflake	Ya
Teradata	Ya
Trino	Ya
Vektor	Ya
Vertica	Ya

Dukungan dialek untuk membuat tabel agregat secara bertahap

Agar Looker mendukung tabel agregat inkremental dalam project Looker, dialek database Anda juga harus mendukungnya. Tabel berikut menunjukkan dialek yang mendukung pembuatan PDT secara bertahap dalam rilis Looker terbaru:

Dialek	Didukung?
Actian Avalanche	Tidak
Amazon Athena	Tidak
Amazon Aurora MySQL	Tidak
Amazon Redshift	Ya
Apache Druid	Tidak
Apache Druid 0.13+	Tidak
Apache Druid 0.18+	Tidak
Apache Hive 2.3+	Tidak
Apache Hive 3.1.2+	Tidak
Apache Spark 3+	Tidak
ClickHouse	Tidak
Cloudera Impala 3.1+	Tidak
Cloudera Impala 3.1+ dengan Driver Native	Tidak
Cloudera Impala dengan Driver Native	Tidak
DataVirtuality	Tidak
Databricks	Ya
Denodo 7	Tidak
Denodo 8	Tidak
Dremio	Tidak
Dremio 11+	Tidak
Exasol	Tidak
Firebolt	Tidak
Legacy SQL Google BigQuery	Tidak
SQL Standar Google BigQuery	Ya
Google Cloud PostgreSQL	Ya
Google Cloud SQL	Tidak
Google Spanner	Tidak
Greenplum	Ya
HyperSQL	Tidak
IBM Netezza	Tidak
MariaDB	Tidak
Microsoft Azure PostgreSQL	Ya
Microsoft Azure SQL Database	Tidak
Microsoft Azure Synapse Analytics	Ya
Microsoft SQL Server 2008+	Tidak
Microsoft SQL Server 2012+	Tidak
Microsoft SQL Server 2016	Tidak
Microsoft SQL Server 2017+	Tidak
MongoBI	Tidak
MySQL	Ya
MySQL 8.0.12+	Ya
Oracle	Tidak
Oracle ADWC	Tidak
PostgreSQL 9.5+	Ya
PostgreSQL versi pra-9.5	Ya
PrestoDB	Tidak
PrestoSQL	Tidak
SAP HANA 2+	Tidak
SingleStore	Tidak
SingleStore 7+	Tidak
Snowflake	Ya
Teradata	Tidak
Trino	Tidak
Vektor	Tidak
Vertica	Ya