Tutorial kesadaran agregat

Untuk detail tambahan, lihat halaman dokumentasi Kesadaran gabungan.

Pengantar

Halaman ini adalah panduan untuk menerapkan kesadaran gabungan dalam skenario praktis, termasuk mengidentifikasi peluang penerapan, pendorong kesadaran gabungan nilai, dan alur kerja sederhana untuk menerapkannya dalam model yang sebenarnya. Halaman ini bukan merupakan penjelasan mendalam tentang semua fitur kesadaran gabungan atau kasus ekstrem, dan bukan merupakan katalog lengkap dari semua fiturnya.

Apa yang dimaksud dengan kesadaran agregat?

Di Looker, Anda sebagian besar membuat kueri terhadap tabel atau tampilan mentah di database. Terkadang, ini adalah tabel turunan persisten (PDT) Looker.

Anda mungkin sering menemukan set data atau tabel yang sangat besar yang, agar berperforma baik, memerlukan tabel agregasi atau gabungan.

Biasanya, Anda dapat membuat tabel agregasi seperti tabel orders_daily yang berisi dimensi terbatas. Hal ini perlu diperlakukan secara terpisah dan dimodelkan secara terpisah di Jelajahi, dan tidak berada di model dengan rapi. Batasan ini menyebabkan pengalaman pengguna yang buruk saat pengguna harus memilih antara beberapa Jelajah untuk data yang sama.

Sekarang, dengan kesadaran agregat Looker, Anda dapat membuat tabel agregat secara otomatis ke berbagai tingkat perincian, dimensi, dan agregasi; dan Anda dapat memberi tahu Looker cara menggunakannya dalam Jelajah yang ada. Kueri kemudian akan memanfaatkan tabel gabungan ini jika Looker menganggapnya 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). Artinya, tabel gabungan memiliki persyaratan database dan koneksi yang sama dengan PDT.

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

Untuk mengetahui apakah dialek database Anda mendukung awareness gabungan, lihat halaman dokumentasi Awareness gabungan.

Nilai kesadaran agregat

Ada sejumlah proposisi nilai signifikan yang ditawarkan oleh agregat kesadaran untuk mendorong nilai tambahan dari model Looker yang ada:

• Peningkatan performa: Mengimplementasikan kesadaran 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 mengenakan biaya berdasarkan ukuran kueri pada model penggunaan. Dengan membuat Looker membuat kueri tabel yang lebih kecil, Anda akan mengurangi biaya per kueri pengguna.
• Peningkatan pengalaman pengguna: Bersama dengan pengalaman yang ditingkatkan yang mengambil jawaban lebih cepat, penggabungan akan menghilangkan pembuatan Jelajah yang berlebihan.
• Mengurangi jejak LookML: Mengganti strategi awareness gabungan berbasis Liquid yang ada dengan implementasi native yang fleksibel akan meningkatkan ketahanan dan mengurangi error.
• Kemampuan untuk memanfaatkan LookML yang ada: Tabel gabungan menggunakan objek query, yang menggunakan kembali logika sesuai model yang ada, bukan menduplikasi logika dengan SQL kustom eksplisit.

Contoh dasar

Berikut adalah implementasi yang sangat sederhana dalam model Looker untuk menunjukkan betapa ringannya kesadaran gabungan. Dengan tabel flights hipotetis dalam database yang berisi baris untuk setiap penerbangan yang dicatat melalui FAA, kita dapat membuat model tabel ini di Looker dengan tampilan dan Jelajahi-nya sendiri. Berikut adalah LookML untuk tabel gabungan yang dapat kita tentukan untuk Eksplorasi:

  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 mengkueri flights Jelajahi dan Looker akan otomatis memanfaatkan tabel gabungan yang ditentukan dalam LookML dan menggunakan tabel gabungan untuk menjawab kueri. Pengguna tidak perlu memberi tahu Looker tentang kondisi khusus apa pun: Jika tabel cocok untuk kolom yang dipilih pengguna, Looker akan menggunakan tabel tersebut.

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

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

Mengidentifikasi peluang

Untuk memaksimalkan manfaat awareness gabungan, Anda harus mengidentifikasi tempat awareness gabungan dapat berperan dalam pengoptimalan atau dalam mendorong nilai awareness gabungan.

Mengidentifikasi dasbor dengan runtime tinggi

Salah satu peluang besar untuk mengetahui agregat adalah membuat tabel agregat 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 Jelajah Histori Aktivitas Sistem ini di browser, lalu mengganti "hostname" 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 penggunaan tinggi yang berperforma lebih buruk daripada rata-rata, seperti dasbor Contoh Visualisasi. Dasbor Contoh Visualisasi menggunakan dua Jelajah, jadi strategi yang baik adalah membuat tabel gabungan untuk kedua Jelajah ini.

Mengidentifikasi Jelajah yang lambat dan banyak dikueri oleh pengguna

Peluang lain untuk meningkatkan awareness gabungan adalah dengan Jelajah yang banyak 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 pengoptimalan Jelajah. Sebagai pintasan, Anda dapat membuka link Jelajah Histori Aktivitas Sistem di browser, lalu mengganti "hostname" di URL dengan nama instance Looker Anda. Anda akan melihat visualisasi Jelajah dengan data tentang Jelajah instance, termasuk Jelajah, Model, Jumlah Penghitungan Kueri, Jumlah Pengguna, dan Rata-rata Runtime dalam Detik:

Di Jelajah Histori, Anda dapat mengidentifikasi jenis Jelajah berikut di instance Anda:

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

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

Mengidentifikasi kolom yang banyak digunakan dalam kueri

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

Gunakan Jelajah Penggunaan Kolom Aktivitas Sistem untuk memahami kolom yang umum dipilih dalam Jelajah yang Anda identifikasi sebagai lambat dan banyak digunakan. Sebagai pintasan, Anda dapat membuka link Jelajah Penggunaan Kolom Aktivitas Sistem ini di browser, lalu mengganti "hostname" di URL dengan nama instance Looker Anda. Ganti filter yang sesuai. Anda akan melihat Eksplorasi dengan visualisasi diagram batang yang menunjukkan frekuensi penggunaan kolom dalam kueri:

Pada contoh Jelajahi Aktivitas Sistem yang ditampilkan dalam gambar, Anda dapat melihat bahwa flights.count dan flights.depart_week adalah dua kolom yang paling sering dipilih untuk Jelajahi. Oleh karena itu, kolom tersebut adalah kandidat yang baik 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 mengasumsikan bahwa pengguna biasanya melihat jumlah penerbangan terjadwal dan jumlah penerbangan yang dibatalkan, serta mereka ingin mengelompokkan data tersebut menurut minggu dan maskapai. Ini adalah contoh kombinasi kolom dan metrik yang jelas, logis, dan nyata.

Ringkasan

Langkah-langkah di halaman dokumentasi ini akan berfungsi sebagai panduan untuk menemukan dasbor, Jelajah, dan kolom yang perlu dipertimbangkan untuk pengoptimalan. Sebaiknya pahami juga bahwa ketiganya mungkin saling eksklusif: dasbor yang bermasalah mungkin tidak didukung oleh Jelajah yang bermasalah, dan membuat tabel gabungan dengan kolom yang biasa digunakan mungkin tidak membantu dasbor tersebut sama sekali. Mungkin ini adalah tiga implementasi kesadaran agregat terpisah.

Mendesain tabel gabungan

Setelah mengidentifikasi peluang untuk kesadaran gabungan, Anda dapat mendesain tabel gabungan yang paling sesuai untuk mengatasi peluang ini. Lihat halaman dokumentasi Kesadaran gabungan untuk mengetahui informasi tentang kolom, ukuran, dan jangka waktu yang didukung dalam tabel gabungan, serta panduan lainnya untuk mendesain tabel gabungan.

CATATAN: Tabel gabungan tidak harus sama persis agar kueri Anda dapat digunakan. Jika kueri Anda memiliki tingkat perincian mingguan 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 dan kueri pengguna hanya di tingkat brand, tabel tersebut masih menjadi kandidat untuk digunakan oleh Looker untuk mengetahui agregat.

Kesadaran agregat didukung untuk tindakan berikut:

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

Kesadaran gabungan tidak didukung untuk tindakan berikut:

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

CATATAN: Jika Anda mengetahui potensi kueri pengguna dengan jenis pengukuran yang tidak didukung oleh kesadaran gabungan, Anda dapat 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 kesadaran 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 yang dipilih maupun yang difilter) harus ada dalam tabel gabungan agar tabel dapat digunakan untuk kueri. Namun, seperti yang telah disebutkan sebelumnya, tabel agregat tidak harus sama persis dengan kueri yang akan digunakan untuk kueri. Anda dapat menangani banyak kueri pengguna potensial dalam satu tabel gabungan dan masih melihat peningkatan performa yang besar.

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

Berikut adalah contoh tabel gabungan yang dapat 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 menunjukkan kueri Jelajah untuk kolom Flights Depart Week, Flights Details Carrier, Flights Count, dan Flights Detailed Cancelled Count 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 akan menjadi operasi pengguna normal, memerlukan waktu 29,5 detik.

Setelah menerapkan tabel agregat 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 memperkirakan dengan sangat sederhana bahwa 25% kueri ini menggunakan keempat kolom dengan cara paling sederhana (pilihan sederhana, tanpa pivot), 3379 x 8,6 detik = 8 jam, 4 menit waktu tunggu pengguna gabungan yang dihilangkan.

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

Setelah menerapkan alur yang sama persis ke model e-commerce order_items — Jelajahi yang paling sering digunakan pada instance ‐ hasilnya adalah sebagai berikut:

Sumber	Waktu Kueri	Baris yang Dipindai
Tabel 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 tersebut telah digunakan sebanyak 11.000 kali. Dengan estimasi penggunaan gabungan yang sama sebesar ~25%, penghematan gabungan untuk pengguna adalah 6 jam, 6 menit (8 detik * 2750 = 22.000 detik). Tabel gabungan memerlukan waktu 17,9 detik untuk dibuat.

Melihat hasil ini, sebaiknya luangkan waktu untuk meninjau dan menilai hasil yang berpotensi diperoleh dari:

• Mengoptimalkan model/Jelajahi yang lebih besar dan lebih kompleks yang memiliki performa "dapat diterima" dan mungkin melihat peningkatan performa dari praktik pemodelan yang lebih baik

versus

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

Anda akan melihat hasil yang menurun untuk upaya Anda saat mencoba mendapatkan performa terakhir dari Looker dan database Anda. Anda harus selalu mengetahui ekspektasi performa dasar, terutama dari pengguna bisnis, dan batasan yang diberlakukan oleh database Anda (seperti konkurensi, nilai minimum kueri, biaya, dan sebagainya). Anda tidak boleh mengharapkan kesadaran gabungan untuk mengatasi batasan ini.

Selain itu, saat mendesain tabel agregat, ingatlah bahwa memiliki lebih banyak kolom akan menghasilkan tabel agregat yang lebih besar dan lebih lambat. Tabel yang lebih besar dapat mengoptimalkan lebih banyak kueri sehingga dapat digunakan dalam 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 kombinasi dimensi apa pun 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 sederhana dari carrier dan count, Anda memerlukan pemindaian tabel 885.000 baris. Sebaliknya, kueri yang sama hanya akan memerlukan pemindaian 4.592 baris jika tabel didasarkan pada dua dimensi. Tabel dengan 885 ribu baris masih mengalami pengurangan ukuran tabel sebesar 97% (dari 38 juta baris sebelumnya); tetapi menambahkan satu dimensi lagi akan meningkatkan ukuran tabel menjadi 20 juta baris. Dengan demikian, ada pengurangan hasil saat Anda menyertakan lebih banyak kolom dalam tabel gabungan untuk meningkatkan penerapannya ke lebih banyak kueri.

Membuat tabel gabungan

Dengan contoh Jelajah Penerbangan yang kami identifikasi sebagai peluang untuk dioptimalkan, strategi terbaiknya adalah membuat tiga tabel gabungan yang berbeda untuknya:

• flights_by_week_and_carrier
• flights_by_month_and_distance
• flights_by_year

Cara termudah untuk membuat tabel gabungan ini adalah dengan mendapatkan LookML tabel gabungan 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.

Persistensi

Agar dapat diakses untuk mengetahui agregat, tabel agregat harus dipertahankan di database Anda. Praktik terbaiknya adalah menyelaraskan pembuatan ulang otomatis tabel gabungan ini dengan kebijakan penyimpanan dalam cache Anda dengan memanfaatkan datagroup. Anda harus menggunakan grup data yang sama untuk tabel gabungan yang digunakan untuk Jelajah terkait. Jika Anda tidak dapat menggunakan grup data, opsi alternatifnya adalah menggunakan parameter sql_trigger_value. Berikut ini nilai umum berbasis tanggal untuk sql_trigger_value:

sql_trigger_value: SELECT CURRENT_DATE() ;;

Tindakan ini akan membuat tabel gabungan secara otomatis pada tengah malam setiap hari.

Logika jangka waktu

Saat membuat tabel gabungan, Looker akan menyertakan data hingga titik waktu tabel gabungan dibuat. Setiap data yang kemudian ditambahkan ke tabel dasar dalam database biasanya akan dikecualikan dari hasil kueri yang menggunakan tabel gabungan tersebut.

Diagram ini menunjukkan linimasa saat pesanan diterima dan dicatat dalam database dibandingkan dengan titik waktu pembuatan tabel gabungan Pesanan. Ada dua pesanan yang diterima hari ini yang tidak akan ada dalam 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:

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

Ringkasan

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

1. Identifikasi peluang pengoptimalan menggunakan tabel gabungan yang sesuai dan berdampak.
2. Desain tabel gabungan yang akan memberikan cakupan terbanyak untuk kueri pengguna umum, tetapi tetap cukup kecil untuk mengurangi ukuran kueri tersebut secara memadai.
3. Buat tabel gabungan dalam model Looker, dengan menyambungkan persistensi tabel dengan persistensi cache Jelajahi.