Tutorial awareness agregat

Untuk detail selengkapnya, lihat halaman dokumentasi Awareness gabungan.

Pengantar

Halaman ini berisi panduan untuk menerapkan awareness gabungan dalam skenario praktis, termasuk mengidentifikasi peluang untuk penerapan, drive awareness gabungan nilai, dan alur kerja sederhana untuk menerapkannya dalam model nyata. Halaman ini bukanlah penjelasan mendalam tentang semua fitur awareness gabungan atau kasus ekstrem, dan juga bukan katalog lengkap dari semua fiturnya.

Apa itu awareness gabungan?

Di Looker, Anda sering melakukan kueri berdasarkan tabel mentah atau tampilan di database. Terkadang hal tersebut disebut Tabel turunan persisten (PDT) Looker.

Anda mungkin sering menemukan set data atau tabel yang sangat besar yang, agar berperforma tinggi, memerlukan tabel agregasi atau roll-up.

Umumnya, Anda dapat membuat tabel agregasi seperti tabel orders_daily yang berisi dimensi terbatas. Hal ini perlu diperlakukan secara terpisah dan dimodelkan secara terpisah di Explore, dan tidak diletakkan dalam model dengan rapi. Batasan ini menyebabkan pengalaman pengguna yang buruk ketika pengguna harus memilih di antara beberapa Jelajah untuk mendapatkan data yang sama.

Sekarang, dengan awareness gabungan Looker, Anda dapat membuat tabel gabungan terlebih dahulu ke berbagai tingkat perincian, dimensi, dan agregasi; serta memberi tahu Looker tentang cara menggunakannya dalam Jelajah yang ada. Kueri kemudian akan memanfaatkan tabel gabungan ini jika Looker dianggap sesuai, tanpa input pengguna. Hal ini akan mengurangi ukuran kueri, mengurangi waktu tunggu, dan meningkatkan pengalaman pengguna.

CATATAN: Tabel gabungan Looker adalah jenis tabel turunan persisten (PDT). Ini berarti tabel gabungan memiliki persyaratan database dan koneksi yang sama dengan PDT.

Untuk mengetahui apakah dialek database dan koneksi Looker Anda dapat mendukung PDT, lihat persyaratan yang tercantum di halaman dokumentasi Tabel turunan di Looker.

Untuk melihat apakah dialek database Anda mendukung awareness gabungan, lihat halaman dokumentasi Kesadaran gabungan.

Nilai awareness gabungan

Ada sejumlah penawaran awareness gabungan proposisi nilai yang signifikan untuk mendorong nilai tambahan dari model Looker yang ada:

• Peningkatan performa: Menerapkan awareness gabungan akan membuat kueri pengguna lebih cepat. Looker akan menggunakan tabel yang lebih kecil jika berisi data yang diperlukan untuk menyelesaikan kueri pengguna.
• Penghematan biaya: Dialek tertentu dikenai biaya berdasarkan ukuran kueri pada model pemakaian. Dengan meminta Looker dibuat kueri pada tabel yang lebih kecil, Anda akan mengurangi biaya per kueri pengguna.
• Peningkatan kualitas pengalaman pengguna: Bersama dengan peningkatan pengalaman yang dapat mengambil jawaban lebih cepat, konsolidasi mencegah pembuatan Jelajahi yang berlebihan.
• Mengurangi jejak LookML: Mengganti strategi awareness gabungan berbasis Liquid yang sudah ada dengan implementasi native yang fleksibel akan menghasilkan peningkatan ketahanan dan error yang lebih sedikit.
• Kemampuan untuk memanfaatkan LookML yang ada: Tabel gabungan menggunakan objek query, yang menggunakan kembali logika sesuai model yang sudah ada, bukan logika duplikat dengan SQL kustom eksplisit.

Contoh dasar

Berikut adalah implementasi yang sangat sederhana dalam model Looker untuk menunjukkan betapa ringannya awareness gabungan. Dengan mempertimbangkan tabel flights hipotesis dalam database dengan baris untuk setiap penerbangan yang dicatat melalui FAA, kita dapat membuat model tabel ini di Looker dengan tampilan dan Jelajahnya sendiri. Berikut adalah LookML untuk tabel gabungan yang dapat kita tentukan untuk Explore:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Dengan tabel gabungan ini, pengguna dapat membuat kueri untuk Jelajah flights dan Looker akan otomatis memanfaatkan tabel gabungan yang ditentukan di atas dan menggunakan tabel gabungan untuk menjawab kueri. Pengguna tidak perlu memberi tahu Looker tentang kondisi khusus, Looker hanya akan menggunakan tabel tersebut jika cocok dengan kolom yang dipilih pengguna.

Pengguna dengan izin see_sql dapat menggunakan komentar di tab SQL pada Explore untuk melihat tabel gabungan yang akan digunakan untuk kueri. Berikut adalah contoh tab SQL Looker untuk kueri yang menggunakan tabel gabungan flights:flights_by_week_and_carrier in teach_scratch:

Lihat halaman dokumentasi Kesadaran gabungan untuk detail tentang cara menentukan apakah tabel gabungan digunakan untuk kueri.

Mengidentifikasi peluang

Untuk memaksimalkan manfaat awareness gabungan, Anda harus mengidentifikasi peran awareness gabungan dalam pengoptimalan atau mendorong nilai yang disebutkan di atas.

Identifikasi dasbor dengan runtime tinggi

Salah satu peluang besar untuk awareness agregat adalah membuat tabel gabungan untuk dasbor yang banyak digunakan dengan runtime yang sangat tinggi. Anda mungkin mendengar dari pengguna tentang dasbor yang lambat, tetapi jika memiliki see_system_activity, Anda juga dapat menggunakan Jelajah Histori Aktivitas Sistem Looker untuk menemukan dasbor dengan runtime yang lebih lambat dari rata-rata. Sebagai pintasan, Anda dapat membuka link Jelajahi Histori Aktivitas Sistem ini di browser, lalu ganti "nama host" di URL dengan nama instance Looker Anda. Anda akan melihat visualisasi Jelajah dengan data tentang dasbor instance, termasuk Judul, Histori, Jumlah Jelajah, Rasio dari Cache vs. Database, dan Berperforma Lebih buruk dari Rata-rata:

Dalam contoh ini, ada sejumlah dasbor dengan pemanfaatan tinggi yang berperforma lebih buruk daripada rata-rata, seperti dasbor Contoh Visualisasi. Dasbor Sample Visualizations menggunakan dua Jelajah, jadi strategi yang tepat adalah membuat tabel gabungan untuk kedua Jelajah ini.

Mengidentifikasi Jelajah yang lambat dan sangat dikueri oleh pengguna

Peluang lain untuk awareness gabungan adalah dengan Jelajah yang sering dikueri oleh pengguna dan memiliki respons kueri yang lebih rendah dari rata-rata.

Anda dapat menggunakan Jelajah Histori Aktivitas Sistem sebagai titik awal untuk mengidentifikasi peluang mengoptimalkan Jelajah. Sebagai pintasan, Anda dapat membuka link Jelajah Histori Aktivitas Sistem di browser, lalu ganti "nama host" di URL dengan nama instance Looker Anda. Anda akan melihat visualisasi Jelajah dengan data tentang Jelajah instance, termasuk Jelajah, Model, Jumlah Jalankan Kueri, Jumlah Pengguna, dan Rata-Rata Runtime dalam Detik:

Di Eksplorasi Histori, Anda dapat mengidentifikasi jenis Jelajah berikut pada instance Anda:

• Jelajah yang dikueri oleh pengguna (bukan kueri dari API atau kueri dari pengiriman terjadwal)
• Jelajah yang sering dikueri
• Jelajah yang berperforma buruk (relatif terhadap Jelajah lainnya)

Pada contoh Eksplorasi Histori Aktivitas Sistem sebelumnya, Jelajah flights dan order_items kemungkinan merupakan kandidat untuk penerapan awareness gabungan.

Mengidentifikasi kolom yang banyak digunakan dalam kueri

Terakhir, Anda dapat mengidentifikasi peluang lain pada tingkat data dengan memahami kolom yang biasanya disertakan pengguna dalam kueri dan filter.

Gunakan Eksplorasi Penggunaan Kolom Aktivitas Sistem untuk memahami kolom yang umum dipilih dalam Jelajah yang Anda identifikasi di atas. Sebagai pintasan, Anda dapat membuka link Eksplorasi Penggunaan Kolom Aktivitas Sistem ini di browser, lalu ganti "nama host" di URL dengan nama instance Looker Anda. Ganti filter yang sesuai. Anda akan melihat Eksplorasi dengan visualisasi grafik batang yang menunjukkan frekuensi penggunaan kolom dalam kueri:

Pada Eksplorasi Aktivitas Sistem yang digambarkan di atas, Anda dapat melihat bahwa flights.count dan flights.depart_week adalah dua kolom yang paling umum dipilih untuk Jelajah. Jadi itu adalah kandidat yang baik untuk {i>field<i} untuk disertakan dalam tabel gabungan.

Data konkret seperti ini sangat membantu, tetapi ada elemen subjektif yang akan memandu kriteria pemilihan Anda. Misalnya, dengan melihat empat kolom sebelumnya, Anda dapat dengan aman mengasumsikan bahwa pengguna biasanya melihat jumlah penerbangan terjadwal dan jumlah penerbangan yang dibatalkan, serta bahwa mereka ingin membagi data tersebut menurut minggu dan menurut jasa kurir. Ini adalah contoh kombinasi bidang dan metrik yang jelas, logis, dan nyata.

Ringkasan

Langkah-langkah di atas akan berfungsi sebagai panduan untuk menemukan dasbor, Jelajah, dan kolom yang perlu dipertimbangkan untuk pengoptimalan. Perlu dipahami juga bahwa ketiganya mungkin bersifat eksklusif satu sama lain: dasbor yang bermasalah mungkin tidak didukung oleh Explore yang bermasalah, dan membuat tabel gabungan dengan kolom yang umum digunakan mungkin tidak membantu dasbor tersebut sama sekali. Mungkin saja ini adalah tiga penerapan awareness gabungan yang berbeda.

Mendesain tabel gabungan

Setelah mengidentifikasi peluang untuk awareness gabungan, Anda dapat mendesain tabel gabungan yang paling sesuai dengan peluang ini. Lihat halaman dokumentasi Kesadaran gabungan untuk informasi tentang kolom, ukuran, dan jangka waktu yang didukung dalam tabel gabungan, serta pedoman lain untuk mendesain tabel gabungan.

CATATAN: Tabel gabungan tidak harus sama persis agar kueri Anda dapat digunakan. Jika kueri Anda berada pada tingkat perincian minggu dan Anda memiliki tabel gabungan harian, Looker akan menggunakan tabel gabungan, bukan tabel mentah tingkat stempel waktu. Demikian pula, jika Anda memiliki tabel gabungan yang digabungkan ke tingkat brand dan date serta kueri pengguna di tingkat brand saja, tabel tersebut masih merupakan kandidat untuk digunakan oleh Looker untuk awareness gabungan.

Awareness gabungan didukung untuk tindakan berikut:

• Ukuran standar: Ukuran jenis SUM, COUNT, AVERAGE, MIN, dan MAX
• Ukuran gabungan: Ukuran jenis NUMBER, STRING, YESNO, dan DATE
• Perkiraan ukuran yang berbeda: Dialek yang dapat menggunakan fungsi HyperLogLog

Awareness gabungan tidak didukung untuk tindakan berikut:

• Tindakan berbeda: Karena perbedaan hanya dapat dihitung pada data atomik dan non-gabungan, ukuran *_DISTINCT tidak didukung di luar perkiraan ini yang menggunakan HyperLogLog.
• Tindakan berbasis kardinalitas: Seperti halnya ukuran yang berbeda, median dan persentil tidak dapat digabungkan sebelumnya dan tidak didukung. 

CATATAN: Jika Anda mengetahui adanya kueri pengguna potensial dengan jenis pengukuran yang tidak didukung oleh awareness agregat, Anda mungkin perlu membuat tabel gabungan yang sama persis dengan kueri. Tabel gabungan yang merupakan pencocokan persis dari kueri dapat digunakan untuk menjawab kueri dengan jenis pengukuran yang tidak didukung untuk awareness gabungan.

Perincian tabel gabungan

Sebelum membuat tabel untuk kombinasi dimensi dan ukuran, Anda harus menentukan pola penggunaan dan pemilihan kolom yang umum untuk membuat tabel gabungan yang akan digunakan sesering mungkin dengan dampak terbesar. Perhatikan bahwa semua kolom yang digunakan dalam kueri (baik dipilih atau difilter) harus berada di tabel gabungan agar tabel dapat digunakan untuk kueri. Tapi, seperti disebutkan sebelumnya, tabel gabungan tidak harus sama persis dengan kueri yang digunakan untuk kueri. Anda dapat menangani banyak kueri pengguna potensial dalam satu tabel gabungan dan tetap melihat peningkatan performa yang besar.

Dari contoh mengidentifikasi kolom yang banyak digunakan dalam kueri di atas, ada dua dimensi yang sangat sering dipilih (flights.depart_week dan flights.carrier), serta dua ukuran (flights.count dan flights.cancelled_count). Oleh karena itu, sebaiknya buat tabel gabungan yang menggunakan keempat kolom ini. Selain itu, membuat satu tabel gabungan untuk flights_by_week_and_carrier akan menghasilkan penggunaan tabel gabungan yang lebih sering daripada dua tabel gabungan yang berbeda untuk tabel flights_by_week dan flights_by_carrier.

Berikut adalah contoh tabel gabungan yang mungkin kita buat untuk kueri di kolom umum:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Pengguna bisnis dan bukti anekdotal serta data dari Aktivitas Sistem Looker dapat membantu memandu proses pengambilan keputusan Anda.

Menyeimbangkan penerapan dan performa

Contoh berikut menampilkan kueri Jelajah untuk kolom Penerbangan Keberangkatan Minggu, Detail Penerbangan Carrier, Jumlah Penerbangan, dan Detail Penerbangan yang Dibatalkan Jumlah dari tabel gabungan flights_by_week_and_carrier:

Menjalankan kueri ini dari tabel database asli memerlukan waktu 15,8 detik dan memindai 38 juta baris tanpa join menggunakan Amazon Redshift. Memutar kueri, yang merupakan operasi normal bagi pengguna, memerlukan waktu 29,5 detik.

Setelah menerapkan tabel gabungan flights_by_week_and_carrier, kueri berikutnya memerlukan waktu 7,2 detik dan memindai 4.592 baris . Ini adalah pengurangan ukuran tabel sebesar 99,98%. Memutar kueri memerlukan waktu 9,8 detik.

Dari Eksplorasi Penggunaan Kolom Aktivitas Sistem, kita dapat melihat seberapa sering pengguna menyertakan kolom ini dalam kueri. Dalam contoh ini, flights.count digunakan 47.848 kali, flights.depart_week digunakan 18.169 kali, flights.cancelled_count digunakan 16.570 kali, dan flights.carrier digunakan 13.517 kali.

Meskipun kami sangat sederhana memperkirakan bahwa 25% dari kueri ini menggunakan keempat kolom dengan cara yang paling sederhana (pilihan sederhana, tanpa pivot), 3379 x 8,6 detik = 8 jam, 4 menit total waktu tunggu pengguna dihapus.

CATATAN: Contoh model yang digunakan di sini sangat mendasar. Hasil ini tidak boleh digunakan sebagai tolok ukur atau kerangka referensi untuk model Anda.

Setelah menerapkan alur yang sama persis ke model e-commerce kami order_items — Jelajah yang paling sering digunakan pada instance &dash; hasilnya adalah sebagai berikut:

Asal	Waktu Kueri	Baris yang Dipindai
Meja Dasar	13,1 detik	285.000
Tabel Gabungan	5,1 detik	138.000
Delta	8 detik	147.000

Kolom yang digunakan dalam kueri dan tabel gabungan berikutnya adalah brand, created_date, orders_count, dan total_revenue, menggunakan dua join. Kolom telah digunakan sebanyak 11.000 kali. Dengan memperkirakan penggunaan gabungan yang sama sebesar ~25%, penghematan gabungan untuk pengguna adalah 6 jam, 6 menit (8 dtk * 2750 = 22.000). Pembuatan tabel gabungan membutuhkan waktu 17,9 detik.

Melihat hasil ini, ada baiknya meluangkan waktu sejenak untuk mundur dan menilai hasil yang berpotensi diperoleh dari:

• Mengoptimalkan model/Penjelajahan yang lebih besar dan lebih kompleks yang memiliki performa "dapat diterima" dan dapat memperoleh peningkatan performa dari praktik pemodelan yang lebih baik

versus

• Menggunakan awareness gabungan untuk mengoptimalkan model yang lebih sederhana yang lebih sering digunakan dan berperforma buruk

Hasil dari usaha Anda akan menurun saat mencoba mendapatkan performa bagian terakhir dari Looker dan database Anda. Anda harus selalu mengetahui ekspektasi performa dasar pengukuran, terutama dari pengguna bisnis, dan batasan yang diberlakukan oleh database (seperti konkurensi, nilai minimum kueri, biaya, dan sebagainya). Anda tidak boleh mengharapkan awareness gabungan dapat mengatasi batasan ini.

Selain itu, ketika mendesain tabel agregat, ingatlah bahwa memiliki lebih banyak {i>field<i} akan menghasilkan tabel agregat yang lebih besar dan lebih lambat. Tabel yang lebih besar dapat mengoptimalkan lebih banyak kueri dan oleh karena itu digunakan di lebih banyak situasi, tetapi tabel besar tidak akan secepat tabel yang lebih kecil dan lebih sederhana.

Contoh:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week,flights.distance, flights.arrival_week,flights.cancelled]
        measures: [cancelled_count, count, flights.average_distance, flights.total_distance]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Hal ini akan menyebabkan tabel gabungan digunakan untuk setiap kombinasi dimensi yang ditampilkan dan untuk setiap ukuran yang disertakan, sehingga tabel ini dapat digunakan untuk menjawab berbagai kueri pengguna. Namun, untuk menggunakan tabel ini untuk kueri SELECT carrier dan count sederhana, diperlukan pemindaian tabel 885.000 baris. Sebaliknya, kueri yang sama hanya akan memerlukan pemindaian 4.592 baris jika tabel didasarkan pada dua dimensi. Tabel 885K-baris masih merupakan pengurangan 97% dalam ukuran tabel (dari 38 juta baris sebelumnya); tetapi menambahkan satu dimensi lagi akan meningkatkan ukuran tabel menjadi 20 juta baris. Dengan demikian, ada hasil yang menurun saat Anda menyertakan lebih banyak kolom dalam tabel gabungan untuk meningkatkan penerapannya ke lebih banyak kueri.

Membuat tabel gabungan

Dengan mengambil contoh Eksplorasi Flights yang kami identifikasi sebagai peluang untuk pengoptimalan, strategi terbaiknya adalah dengan membuat tiga tabel gabungan yang berbeda:

• flights_by_week_and_carrier
• flights_by_month_and_distance
• flights_by_year

Cara termudah untuk membuat tabel gabungan ini adalah dengan mendapatkan tabel gabungan LookML dari kueri Jelajah atau dari dasbor dan menambahkan LookML ke file project Looker Anda.

Setelah Anda menambahkan tabel gabungan ke project LookML dan men-deploy update ke produksi, Jelajah akan memanfaatkan tabel gabungan untuk kueri pengguna Anda.

Persistensi

Agar dapat diakses untuk awareness gabungan, tabel gabungan harus disimpan di database Anda. Praktik terbaiknya adalah menyelaraskan pembuatan ulang tabel gabungan ini dengan kebijakan penyimpanan dalam cache dengan memanfaatkan datagroups. Sebaiknya gunakan grup data yang sama untuk tabel gabungan yang digunakan untuk Jelajah terkait. Jika Anda tidak dapat menggunakan datagroups, opsi alternatifnya adalah menggunakan parameter sql_trigger_value. Nilai berbasis tanggal umum untuk sql_trigger_value ditampilkan di bawah ini:

sql_trigger_value: SELECT CURRENT_DATE() ;;

Ini akan membuat tabel gabungan Anda secara otomatis pada tengah malam setiap hari.

Logika kerangka waktu

Saat Looker membuat tabel gabungan, tabel gabungan akan menyertakan data hingga waktu tabel gabungan dibuat. Setiap data yang selanjutnya ditambahkan ke tabel dasar dalam {i>database<i} biasanya akan dikeluarkan dari hasil kueri yang menggunakan tabel gabungan tersebut.

Diagram ini menampilkan linimasa kapan pesanan diterima dan dicatat ke dalam database, dibandingkan dengan titik waktu pembuatan tabel gabungan Pesanan. Ada dua pesanan yang diterima hari ini yang tidak akan ada di tabel gabungan Pesanan, karena pesanan diterima setelah tabel gabungan dibuat:

Namun, Looker dapat menggabungkan data baru ke tabel gabungan saat pengguna membuat kueri untuk jangka waktu yang tumpang-tindih dengan tabel gabungan, seperti yang digambarkan dalam diagram linimasa yang sama:

timeline<i} yang terjadi setelah tabel gabungan dibuat." class="l10n-absolute-url-src" l10n-attrs-original-order="src,alt,class" src="https://cloud.google.com/static/looker/docs/images/hc-aggaware-orig-timeframe-logic-2-2212.png" />

Karena Looker dapat MENGGABUNGKAN data baru ke tabel gabungan, jika pengguna memfilter jangka waktu yang tumpang-tindih dengan bagian akhir tabel gabungan dan dasar, pesanan yang diterima setelah tabel gabungan dibuat akan disertakan dalam hasil pengguna. Lihat halaman dokumentasi Brand awareness gabungan untuk mengetahui detail dan kondisi yang harus dipenuhi untuk menggabungkan data baru guna menggabungkan kueri tabel.

Ringkasan

Sebagai rangkuman, untuk membuat penerapan awareness gabungan, ada tiga langkah mendasar:

1. Identifikasi peluang di mana pengoptimalan menggunakan tabel gabungan memang tepat dan berdampak.
2. Desain tabel gabungan yang akan menyediakan cakupan paling banyak untuk kueri pengguna umum sambil tetap berukuran cukup kecil untuk mengurangi ukuran kueri tersebut secukupnya.
3. Buat tabel gabungan dalam model Looker, dengan memasangkan persistensi tabel dengan persistensi cache Jelajah.