Perlu diperhatikan bahwa Anda sedang melihat dokumentasi Looker. Untuk melihat dokumentasi Looker Studio, buka https://support.google.com/looker-studio.

Kesadaran agregat

Untuk panduan tentang cara menerapkan awareness gabungan, lihat juga halaman Praktik Terbaik tutorial awareness gabungan kami.

Ringkasan

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

Untuk tabel yang sangat besar dalam database Anda, developer Looker dapat membuat tabel data gabungan yang lebih kecil, yang dikelompokkan berdasarkan 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, awareness gabungan dapat mempercepat kueri rata-rata berdasarkan urutan magnitudonya.

Misalnya, Anda mungkin memiliki tabel data berskala petabyte dengan satu baris untuk setiap pesanan yang telah terjadi di situs Anda. Dari {i>database<i} ini, Anda dapat membuat sebuah tabel gabungan yang berisikan total penjualan harian Anda. Jika situs web Anda menerima 1.000 pesanan setiap hari, tabel gabungan harian Anda akan mewakili setiap hari dengan 999 baris lebih sedikit dari tabel asli Anda. Anda dapat membuat tabel gabungan lain dengan total penjualan bulanan yang akan lebih efisien. Jadi, 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 hal terbaik berikutnya, yaitu tabel gabungan penjualan bulanan dalam contoh ini.

Looker akan 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 perincian tersebut, sehingga Looker mendapatkan hasil kueri dari tabel database asli (orders_database). (Namun, jika pengguna sering menjalankan jenis kueri ini, Anda dapat dengan mudah membuat tabel gabungan untuk kueri tersebut.)
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 logika awareness gabungan, Looker akan mengkueri tabel gabungan terkecil untuk menjawab pertanyaan pengguna. Tabel asli hanya akan digunakan untuk kueri yang memerlukan perincian yang lebih baik daripada yang dapat diberikan oleh tabel gabungan.

Tabel gabungan tidak perlu digabungkan atau ditambahkan ke Jelajah terpisah. Sebagai gantinya, Looker secara dinamis menyesuaikan klausa FROM dari kueri Explore untuk mengakses tabel gabungan terbaik untuk kueri tersebut. Artinya, drill Anda akan dipertahankan dan Jelajah dapat digabungkan. Dengan awareness gabungan, satu Eksplorasi dapat otomatis memanfaatkan tabel gabungan, tetapi tetap mendalami data terperinci jika diperlukan.

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

Menambahkan tabel agregat ke project Anda

Agar dapat diakses untuk awareness gabungan, tabel gabungan 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 gabungan strategis yang akan meminimalkan jumlah kueri yang diperlukan pada tabel besar dalam database. Tabel gabungan harus dipertahankan ke database Anda agar dapat diakses untuk awareness gabungan. Oleh karena itu, tabel gabungan merupakan 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 Anda bisa mendapatkan tabel gabungan LookML dari Explore atau dari dasbor. Lihat halaman dokumentasi parameter aggregate_table untuk mengetahui spesifikasi parameter aggregate_table dan subparameternya.

Mendesain tabel agregat

Agar kueri Jelajah dapat menggunakan tabel gabungan, tabel gabungan harus dapat memberikan data yang akurat untuk kueri Jelajah tersebut. Looker dapat menggunakan tabel gabungan untuk kueri Jelajah jika semua hal berikut berlaku:

Kolom kueri Jelajah adalah bagian dari kolom tabel gabungan (lihat bagian Faktor kolom di halaman ini). Atau, untuk jangka waktu, jangka waktu kueri Explore dapat diperoleh dari jangka waktu dalam tabel gabungan (lihat bagian Faktor jangka waktu di halaman ini).
Kueri Jelajah berisi jenis pengukuran yang didukung oleh awareness gabungan (lihat bagian Mengukur faktor jenis di halaman ini), atau kueri Jelajah memiliki tabel gabungan yang merupakan pencocokan persis (lihat bagian Membuat tabel gabungan yang sama persis dengan kueri Jelajah di halaman ini).
Zona waktu kueri Jelajah cocok dengan zona waktu yang digunakan oleh tabel gabungan (lihat bagian Faktor zona waktu di halaman ini).
Kolom referensi filter kueri Jelajah yang tersedia sebagai dimensi di tabel gabungan, atau setiap filter kueri Jelajah cocok dengan filter di 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 Eksplorasi tersebut, termasuk kolom yang digunakan untuk filter di kueri Eksplorasi. Jika kueri Jelajah 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 berdasarkan dimensi A dan B, mengagregasi menurut ukuran C, dan memfilter 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 setidaknya kolom kueri Explore agar dapat dioptimalkan. Satu-satunya pengecualian adalah dimensi jangka waktu, karena jangka waktu perincian yang lebih kasar dapat berasal dari jangka waktu dengan perincian yang lebih baik.

Karena pertimbangan kolom ini, tabel gabungan dikhususkan untuk Eksplorasi yang menjadi dasar penentuannya. Tabel gabungan yang ditentukan dalam satu Jelajah tidak akan digunakan untuk kueri pada Jelajah yang berbeda.

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 perincian yang lebih baik (atau sama) dengan kueri Jelajah. Misalnya, tabel gabungan berdasarkan data harian dapat digunakan untuk kueri Jelajah yang membutuhkan jangka waktu lain, seperti kueri untuk data harian, bulanan, dan tahunan, atau bahkan data hari dalam sebulan, hari dalam setahun, dan minggu-tahun. Namun, tabel gabungan tahunan tidak dapat digunakan untuk kueri Jelajah yang membutuhkan data per jam, karena data tabel gabungan tidak memiliki tingkat perincian yang cukup untuk kueri Jelajah tersebut.

Hal yang sama berlaku untuk subkumpulan rentang waktu. Misalnya, jika Anda memiliki tabel gabungan yang difilter selama tiga bulan terakhir dan pengguna membuat kueri data dengan filter untuk 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 perincian yang lebih baik (atau sama) seperti filter jangka waktu yang digunakan dalam kueri Eksplorasi. Misalnya, tabel gabungan yang memiliki dimensi jangka waktu harian dapat digunakan untuk kueri Eksplorasi yang memfilter hari, minggu, atau bulan.

Mengukur faktor jenis

Agar kueri Jelajah dapat menggunakan tabel gabungan, ukuran dalam tabel gabungan harus dapat memberikan data yang akurat untuk kueri Jelajah.

Untuk alasan ini, hanya jenis tindakan tertentu yang didukung, seperti yang dijelaskan di bagian berikut:

Pengukuran dengan jenis pengukuran yang didukung
Tindakan yang ditentukan oleh ekspresi SQL
Tindakan yang tidak ditentukan dengan ${TABLE}
Ukuran yang memperkirakan jumlah unik

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

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

Pengukuran dengan jenis pengukuran yang didukung

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

Jika Jelajah menggabungkan beberapa tabel database, Looker dapat merender ukuran jenis SUM, COUNT, dan AVERAGE masing-masing sebagai SUM DISTINCT, COUNT DISTINCT, dan AVERAGE DISTINCT. Looker melakukan hal ini untuk menghindari kesalahan penghitungan fanout, seperti yang dijelaskan di bagian Agregat simetris untuk Jelajah dengan gabungan di halaman ini.

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

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

Ukuran yang ditentukan dengan ekspresi SQL

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

Awareness gabungan didukung untuk tindakan yang ditentukan sebagai kombinasi tindakan lainnya, seperti contoh ini:

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

Awareness gabungan juga didukung untuk ukuran yang penghitungannya ditentukan dalam parameter sql, seperti ukuran ini:

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

Dan awareness gabungan didukung untuk tindakan dengan operasi MIN, MAX, dan COUNT ditentukan dalam parameter sql, seperti ukuran ini:

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

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

Ukuran yang merujuk pada kolom LookML

Saat ekspresi sql digunakan dalam ukuran, awareness agregat mendukung jenis referensi kolom berikut:

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

Awareness agregat 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 ringkasan penggunaan referensi dalam 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 dalam tabel gabungan.

Ukuran 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 sebuah situs, mungkin ada pengguna yang mengunjungi situs tersebut dua kali, dengan rentang waktu tiga minggu. Jika Anda mencoba menerapkan tabel gabungan mingguan untuk mendapatkan jumlah bulanan pengguna yang berbeda di situs Anda, pengguna tersebut akan dihitung dua kali dalam kueri jumlah unik bulanan, dan datanya akan salah.

Salah satu solusinya adalah membuat tabel gabungan yang sama persis dengan kueri Jelajah, seperti yang dijelaskan di bagian Membuat tabel gabungan yang sama persis dengan kueri Jelajah di halaman ini. Jika kueri Jelajah 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. Untuk dialek yang mendukung sketsa HyperLogLog, Looker dapat memanfaatkan algoritma HyperLogLog untuk memperkirakan jumlah yang berbeda untuk tabel gabungan.

Algoritma HyperLogLog diketahui memiliki sekitar 2% kesalahan. Parameter allow_approximate_optimization: yes mengharuskan developer Looker Anda mengonfirmasi bahwa Anda dapat menggunakan data perkiraan untuk pengukuran tersebut sehingga pengukurannya dapat dihitung dari tabel gabungan.

Lihat halaman dokumentasi parameter allow_approximate_optimization untuk informasi selengkapnya dan untuk daftar dialek yang mendukung jumlah berbeda menggunakan HyperLogLog.

Faktor zona waktu

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

Zona waktu kueri, setelan yang berlaku untuk semua kueri di 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 ke dalam 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 ke zona waktu masing-masing pengguna.

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

Konsep ini penting untuk memahami awareness 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 hal berikut berlaku:

Database Anda tidak mendukung zona waktu.
Zona waktu kueri koneksi database Anda disetel ke zona waktu yang sama dengan zona waktu database.
Koneksi database Anda tidak memiliki zona waktu kueri tertentu maupun zona waktu khusus pengguna. Jika demikian, koneksi database Anda akan menggunakan zona waktu database.

Jika salah satu dari hal tersebut benar, Anda dapat menghilangkan parameter timezone untuk tabel gabungan.

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

Jika koneksi database Anda menggunakan satu zona waktu kueri, Anda harus mencocokkan nilai timezone tabel gabungan Anda 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 dengan kemungkinan zona waktu pengguna Anda.

Looker tidak dapat menggunakan tabel gabungan untuk kueri Jelajah jika zona waktu pada tabel gabungan tidak cocok dengan zona waktu dalam kueri Jelajah. Jika koneksi database Anda memiliki zona waktu khusus pengguna, itu berarti Anda memerlukan tabel gabungan terpisah untuk setiap zona waktu pengguna Anda.

Filter faktor

Berhati-hatilah saat menyertakan filter dalam tabel gabungan. Filter pada tabel gabungan dapat mempersempit hasil ke titik di mana tabel gabungan tidak dapat digunakan. Misalnya, Anda membuat tabel gabungan untuk jumlah pesanan harian dan tabel gabungan memfilter hanya pesanan kacamata hitam yang berasal dari Australia. Jika pengguna menjalankan kueri Jelajah untuk jumlah pesanan harian kacamata hitam 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 Jelajah.

Selain itu, perhatikan filter yang mungkin disertakan oleh developer Looker di Jelajah Anda, seperti:

access_filters: Menerapkan batasan data spesifik per pengguna.
always_filter: Mewajibkan pengguna menyertakan serangkaian filter tertentu untuk kueri Jelajah. Pengguna dapat mengubah nilai filter default untuk kuerinya, tetapi mereka tidak dapat menghapus filter sepenuhnya.
conditionally_filter: Menentukan kumpulan filter default yang dapat diganti oleh pengguna jika mereka menerapkan setidaknya satu filter dari daftar kedua yang juga ditetapkan di Eksplorasi.

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

Agar dapat membuat tabel gabungan yang akan digunakan untuk Eksplorasi 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 secara dinamis memfilter data dalam tabel gabungan agar cocok dengan filter dari kueri Jelajah. Oleh karena itu, Looker tetap 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 Jelajah ke subkueri tabel turunan native. Dalam kasus awareness gabungan, jika kueri Jelajah memerlukan tabel turunan native yang menggunakan bind_filters, kueri Jelajah dapat menggunakan tabel gabungan hanya jika semua kolom yang digunakan dalam parameter bind_filters tabel turunan native memiliki nilai filter yang sama persis di kueri Jelajah seperti dalam tabel gabungan.

Membuat tabel gabungan yang sama persis dengan kueri Jelajah

Salah satu cara untuk memastikan bahwa tabel gabungan dapat digunakan untuk kueri Jelajah adalah dengan membuat tabel gabungan yang sama persis dengan kueri Jelajah. Jika kueri Jelajah dan tabel gabungan menggunakan ukuran, dimensi, filter, zona waktu, dan parameter lain yang sama, menurut definisi hasil tabel gabungan akan diterapkan untuk kueri Jelajah. Jika tabel gabungan sama persis dengan kueri Jelajah, Looker dapat menggunakan tabel gabungan yang mencakup jenis ukuran apa pun.

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

Menentukan tabel gabungan mana yang digunakan untuk sebuah 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 mengirimkan tabel baru ke produksi.

Misalnya, berdasarkan contoh tabel gabungan bulanan yang ditampilkan sebelumnya, Anda dapat membuka bagian Eksplorasi 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 gabungan yang digunakan untuk kueri.

Dari komentar 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 melihat kemungkinan komentar yang mungkin Anda lihat di tab SQL dan saran tentang cara mengatasinya.

Estimasi penghematan komputasi untuk awareness gabungan

Jika koneksi database Anda mendukung estimasi biaya dan jika tabel gabungan dapat digunakan untuk kueri, jendela Explore akan menampilkan penghematan komputasi dari penggunaan tabel gabungan, bukan membuat kueri database secara langsung. Penghematan awareness gabungan ditampilkan di sebelah kiri tombol Run dalam Explore sebelum kueri dijalankan:

Tombol Run dari Explore. Di sebelah kiri tombol, sebuah pesan akan ditampilkan: Akan memproses 3.989 baris. Awareness agregat menyimpan 1,2 juta baris.'

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 gabungan mana yang digunakan untuk kueri di halaman dokumentasi ini.

Setelah kueri dijalankan, di samping tombol Run, jendela Explore akan menampilkan tabel gabungan mana yang digunakan untuk menjawab kueri tersebut.

Penghematan awareness gabungan ditampilkan untuk koneksi database yang diaktifkan untuk estimasi biaya. Lihat halaman dokumentasi Menjelajahi data di Looker untuk 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 mungkin memiliki tabel gabungan yang menyertakan data selama tiga hari terakhir, tetapi tabel gabungan tersebut mungkin telah dibuat kemarin. Tabel gabungan akan kehilangan informasi hari ini, sehingga Anda tidak akan menggunakannya untuk kueri Explore untuk informasi harian terbaru.

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

Looker dapat menggabungkan data baru dengan data tabel gabungan jika kondisi 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 Explore untuk melihat tabel gabungan yang digunakan Looker untuk kueri, dan pernyataan UNION yang digunakan Looker untuk menghasilkan data baru yang tidak disertakan dalam tabel gabungan.

Saat ini, jika Looker tidak dapat menggabungkan data baru dengan tabel gabungan, Looker akan menggunakan data yang ada dari tabel gabungan.

Tabel gabungan harus dipertahankan

Agar dapat diakses untuk awareness gabungan, tabel gabungan harus disimpan di database. Strategi persistensi ditetapkan 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 membangun ulang tabel tersebut secara keseluruhan. Karena tabel gabungan juga merupakan jenis PDT, Anda juga dapat membuat tabel gabungan inkremental. Lihat halaman dokumentasi PDT inkremental untuk informasi selengkapnya tentang PDT inkremental. Lihat halaman dokumentasi parameter increment_key untuk mengetahui contoh tabel gabungan 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 tombol Explore actions berbentuk roda gigi, lalu pilih Rebuild Derived Tables & Run dari menu Explore actions.

Anda harus menunggu kueri Explore untuk dimuat sebelum opsi ini tersedia.

Opsi Rebuild Derived Tables & Run membangun ulang semua tabel turunan yang dirujuk dalam kueri serta tabel turunan yang bergantung pada tabel dalam kueri. Ini termasuk tabel gabungan, yang merupakan jenis tabel turunan persisten.

Bagi 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 detail selengkapnya tentang opsi Membuat Ulang Tabel Turunan & Run.

Pemecahan masalah

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

Jika demikian, tab SQL juga menyertakan komentar tentang alasan tabel gabungan tidak digunakan untuk kueri. Untuk tabel gabungan yang tidak digunakan, komentarnya akan dimulai dengan:

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

Misalnya, berikut ini komentar tentang alasan tabel gabungan sales_daily yang ditentukan dalam Jelajah 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 tabel gabungan digunakan.

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

Alasan tidak menggunakan tabel gabungan	Penjelasan dan langkah yang dapat dilakukan
Kolom tersebut tidak ada di Jelajahi.	Ada kesalahan jenis validasi LookML. Kemungkinan besar hal ini terjadi karena tabel gabungan tidak didefinisikan dengan benar, atau ada kesalahan ketik di LookML untuk tabel gabungan Anda. Kemungkinan penyebabnya adalah nama kolom yang salah, atau sejenisnya. Untuk mengatasi masalah ini, pastikan dimensi dan ukuran di tabel gabungan cocok dengan nama kolom di Eksplorasi. Lihat halaman dokumentasi parameter `aggregate_table` untuk 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 Eksplorasi tersebut, termasuk kolom yang digunakan untuk filter di kueri Eksplorasi. 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 perincian yang lebih kasar dapat berasal dari jangka waktu dengan perincian yang lebih baik. Untuk mengatasi hal ini, pastikan kolom kueri Explore disertakan dalam definisi tabel gabungan.
Kueri berisi filter berikut yang tidak disertakan sebagai kolom atau cocok persis dengan filter di tabel gabungan.	Filter dalam kueri Jelajah mencegah Looker menggunakan tabel gabungan. Untuk mengatasi hal ini, Anda dapat melakukan salah satu tindakan berikut: Tambahkan filter yang sama ke tabel gabungan. Tambahkan kolom yang digunakan filter ke tabel gabungan Anda. Hapus filter dari kueri Eksplorasi. Lihat bagian Faktor filter di halaman ini untuk mengetahui detailnya.
Kueri berisi tindakan berikut yang tidak dapat digabungkan.	Kueri berisi satu atau beberapa jenis pengukuran yang tidak didukung untuk awareness gabungan, seperti jumlah yang berbeda, median, atau persentil. Untuk mengatasi hal ini, periksa jenis setiap pengukuran dalam kueri dan pastikan jenis tersebut merupakan salah satu jenis pengukuran yang didukung. Selain itu, jika Explore Anda memiliki gabungan, pastikan ukuran Anda tidak dikonversi menjadi ukuran yang berbeda (agregat simetris) melalui gabungan yang di-fanout. Lihat bagian Agregat simetris untuk Jelajah dengan gabungan di halaman ini untuk mengetahui penjelasannya.
Tabel gabungan yang berbeda lebih cocok untuk pengoptimalan.	Ada beberapa tabel gabungan yang valid untuk kueri dan Looker menemukan tabel gabungan yang lebih optimal untuk digunakan. Anda tidak perlu melakukan apa pun dalam kasus ini.
Looker tidak melakukan pengelompokan apa pun (karena parameter `primary_key` atau `cancel_grouping_fields`), sehingga kueri tidak dapat digabungkan.	Kueri merujuk ke dimensi yang mencegahnya memiliki klausa `GROUP BY`, sehingga Looker tidak dapat menggunakan tabel gabungan apa pun untuk kueri. Untuk mengatasi hal ini, 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 mengatasi hal ini, Anda dapat menghapus filter dari tabel gabungan. Lihat bagian Faktor filter di halaman ini untuk mengetahui detailnya.
Kolom ditetapkan sebagai kolom khusus filter di kueri Eksplorasi, tetapi tercantum dalam parameter `dimensions` tabel gabungan.	Parameter `dimensions` tabel gabungan mencantumkan kolom yang hanya ditentukan sebagai kolom `filter` dalam kueri Eksplorasi. Untuk mengatasi hal ini, hapus kolom dari daftar `dimensions` tabel gabungan. Jika kolom ini diperlukan untuk tabel gabungan, tambahkan kolom tersebut ke daftar `filters` di kueri tabel gabungan.
Pengoptimal tidak dapat menentukan alasan tabel gabungan tidak digunakan.	Komentar ini dicadangkan untuk corner case. Jika melihat ini untuk kueri Explore yang sering digunakan, Anda dapat membuat tabel gabungan yang sama persis dengan kueri Explore. Anda dapat dengan mudah mendapatkan tabel gabungan LookML dari Jelajah, seperti yang dijelaskan di halaman parameter `aggregate_table`.

Hal-hal yang perlu dipertimbangkan

Agregat simetris untuk Jelajah dengan gabungan

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

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

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

Ukuran ini dari tampilan "one" gabungan many-to-one atau one-to-many.
Ukuran ini berasal dari tampilan gabungan many-to-many.

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

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

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

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

Dukungan dialek untuk awareness gabungan

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

Google BigQuery Legacy SQL mendukung kemampuan gabungan, tetapi tidak mendukung penyatuan data baru dengan data tabel gabungan.

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 dan yang lebih baru	Ya
Apache Hive 3.1.2+	Ya
Apache Spark 3+	Ya
ClickHouse	Tidak
Cloudera Impala 3.1+	Ya
Cloudera Impala 3.1+ dengan Native Driver	Ya
Cloudera Impala dengan Native Driver	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
PostgreSQL Google Cloud	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 9.5	Ya
PrestoDB	Ya
PrestoSQL	Ya
SAP HANA	Ya
SAP HANA 2+	Ya
SingleStore	Ya
SingleStore 7+	Ya
Snowflake	Ya
Teradata	Ya
Trino	Ya
Vector	Ya
Vertica	Ya

Dukungan dialek untuk membangun tabel agregat secara bertahap

Agar Looker dapat mendukung tabel gabungan inkremental dalam project Looker, dialek database Anda juga harus mendukung tabel tersebut. Tabel berikut menunjukkan dialek mana yang mendukung pembangunan 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 dan yang lebih baru	Tidak
Apache Hive 3.1.2+	Tidak
Apache Spark 3+	Tidak
ClickHouse	Tidak
Cloudera Impala 3.1+	Tidak
Cloudera Impala 3.1+ dengan Native Driver	Tidak
Cloudera Impala dengan Native Driver	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
PostgreSQL Google Cloud	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 9.5	Ya
PrestoDB	Tidak
PrestoSQL	Tidak
SAP HANA	Tidak
SAP HANA 2+	Tidak
SingleStore	Tidak
SingleStore 7+	Tidak
Snowflake	Ya
Teradata	Tidak
Trino	Tidak
Vector	Tidak
Vertica	Ya