Mengoptimalkan Performa Kueri LookML

Lab 20 menit universal_currency_alt Tanpa biaya show_chart Menengah
info Lab ini mungkin menggabungkan alat AI untuk mendukung pembelajaran Anda.
Konten ini belum dioptimalkan untuk perangkat seluler.
Untuk pengalaman terbaik, kunjungi kami dengan komputer desktop menggunakan link yang dikirim melalui email.

GSP985

Logo lab mandiri Google Cloud

Ringkasan

Looker adalah platform data modern di Google Cloud yang dapat Anda gunakan untuk menganalisis dan memvisualisasikan data Anda secara interaktif. Anda dapat menggunakan Looker untuk melakukan analisis data mendalam, mengintegrasikan insight dari berbagai sumber data, membuat alur kerja berbasis data yang dapat ditindaklanjuti, dan membuat aplikasi data khusus.

Kueri yang kompleks bisa mahal, dan menjalankannya berulang kali akan membebani database Anda, sehingga mengurangi performa. Idealnya, Anda ingin menghindari menjalankan ulang kueri besar jika tidak ada yang berubah, dan sebagai gantinya, menambahkan data baru ke hasil yang ada untuk mengurangi permintaan berulang. Meskipun ada banyak cara untuk mengoptimalkan performa kueri LookML, lab ini berfokus pada metode yang paling umum digunakan untuk mengoptimalkan performa kueri di Looker: tabel turunan persisten, aggregate awareness, dan penggabungan tabel secara efisien.

Yang akan Anda lakukan

  • Memahami kapan dan bagaimana cara menambahkan persistensi dan update inkremental ke tabel turunan.
  • Gunakan aggregate awareness untuk mengoptimalkan kueri pada data yang digabungkan atau diringkas.
  • Buat penyempurnaan dari Eksplorasi yang ada.
  • Menggabungkan tabel virtual dengan cara yang berperforma untuk mengoptimalkan kueri Eksplorasi.
  • Memantau build tabel turunan persisten di instance Looker.

Penyiapan dan persyaratan

Sebelum mengklik tombol Start Lab

Baca petunjuk ini. Lab memiliki timer dan Anda tidak dapat menjedanya. Timer yang dimulai saat Anda mengklik Start Lab akan menampilkan durasi ketersediaan resource Google Cloud untuk Anda.

Lab praktik ini dapat Anda gunakan untuk melakukan sendiri aktivitas lab di lingkungan cloud sungguhan, bukan di lingkungan demo atau simulasi. Untuk mengakses lab ini, Anda akan diberi kredensial baru yang bersifat sementara dan dapat digunakan untuk login serta mengakses Google Cloud selama durasi lab.

Untuk menyelesaikan lab ini, Anda memerlukan:

  • Akses ke browser internet standar (disarankan browser Chrome).
Catatan: Gunakan jendela Samaran atau browser pribadi untuk menjalankan lab ini. Hal ini akan mencegah konflik antara akun pribadi Anda dan akun Siswa yang dapat menyebabkan tagihan ekstra pada akun pribadi Anda.
  • Waktu untuk menyelesaikan lab. Ingat, setelah dimulai, lab tidak dapat dijeda.
Catatan: Jika Anda sudah memiliki project atau akun pribadi Google Cloud, jangan menggunakannya untuk lab ini agar terhindar dari tagihan ekstra pada akun Anda.

Cara memulai lab dan login ke Looker

  1. Jika sudah siap, klik Start lab.

    Panel Lab Details akan muncul dengan kredensial sementara yang harus Anda gunakan untuk lab ini.

    Jika Anda perlu membayar lab, jendela pop-up akan terbuka untuk memilih metode pembayaran.

    Perhatikan kredensial lab Anda di panel Lab Details. Anda akan menggunakannya untuk login ke instance Looker untuk lab ini.

    Catatan: Jika Anda menggunakan kredensial lain, Anda akan menerima pesan error atau dikenai biaya.
  2. Klik Open Looker.

  3. Di kolom Email dan Password, masukkan Nama Pengguna dan Sandi yang disediakan.

    Nama pengguna:

    {{{looker.developer_username | Username}}}

    Sandi:

    {{{looker.developer_password | Password}}} Penting: Anda harus menggunakan kredensial dari panel Lab Details di halaman ini. Jangan menggunakan kredensial Google Cloud Skills Boost. Jika Anda memiliki akun Looker pribadi, jangan gunakan akun tersebut untuk lab ini.
  4. Klik Log In.

    Setelah login berhasil, Anda akan melihat instance Looker untuk lab ini.

Rekomendasi utama untuk mengoptimalkan performa kueri

Di bagian ini, Anda akan mempelajari metode yang umum digunakan untuk pengoptimalan performa kueri di Looker. Di lab ini, Anda akan mendapatkan pengalaman langsung dengan tiga metode pertama.

Tabel turunan persisten (PDT)

Solusi pertama adalah tabel turunan persisten, atau PDT. Looker memungkinkan Anda menulis kueri SQL dan LookML ke database Anda sebagai tabel sementara. Saat di-cache atau dipertahankan, tabel ini disebut PDT. Hal ini memungkinkan Anda menjalankan kueri kompleks atau yang sering digunakan secara berulang dan menyimpan hasil dalam cache untuk akses cepat.

Dengan menyimpan kueri ini sebagai tabel, Anda memiliki kontrol atas waktu atau cara kueri tersebut dibuat. Tabel dapat dibangun ulang setiap pagi, sebulan sekali, atau hanya saat data baru ditambahkan. Idealnya, Anda mengonfigurasi tabel turunan agar mencerminkan sifat data Anda.

Tabel turunan berguna untuk membuat struktur atau agregasi baru yang belum tersedia di tabel database dasar Anda, tetapi tidak semua tabel turunan perlu dipertahankan agar berguna. Persistensi biasanya diterapkan pada kueri kompleks yang mahal untuk dijalankan atau untuk kueri yang sering digunakan oleh banyak pengguna atau aplikasi.

Anda juga dapat membuat PDT inkremental untuk menambahkan data baru tanpa membangun ulang seluruh tabel. Penerapan perubahan inkremental cocok untuk tabel besar yang data lama (yang sudah ada) tidak sering diperbarui karena pembaruan utama pada tabel adalah kumpulan data baru.

Aggregate awareness

Untuk tabel yang sangat besar di database Anda, aggregate awareness Looker dapat membuat tabel data gabungan yang lebih kecil yang dikelompokkan berdasarkan berbagai kombinasi atribut. Tabel gabungan bertindak sebagai "rollup" atau tabel ringkasan yang dapat digunakan Looker sebagai pengganti tabel besar asli untuk kueri jika memungkinkan. Aggregate awareness memungkinkan Looker menemukan tabel terkecil dan paling efisien yang tersedia di database Anda untuk menjalankan kueri sekaligus mempertahankan akurasi. Jika diimplementasikan secara strategis, aggregate awareness dapat mempercepat kueri rata-rata secara signifikan. Pertimbangkan tabel pesanan online untuk toko e-commerce yang sibuk, yang memiliki baris baru yang ditambahkan setiap beberapa detik.

Diagram ringkasan aggregate awareness

Jika Anda ingin melacak pesanan real-time, diperlukan detail yang lebih banyak, tetapi jika Anda ingin melihat tren bulanan seperti “Total penjualan per bulan”, melihat ringkasan data bulanan jauh lebih cepat dan hemat biaya. Dalam hal ini, Looker membuat dan mengkueri sales_monthly_aggregate_table.

Untuk pertanyaan seperti “Berapa total nilai setiap penjualan hari ini”, Anda memerlukan data pesanan tingkat baris yang terperinci. Dalam kasus ini, Looker akan mengkueri tabel orders_database asli tanpa agregasi apa pun. Jika Anda ingin melihat total penjualan mingguan selama tiga minggu terakhir, Looker akan membuat dan memilih tabel gabungan harian penjualan. Tabel ini lebih terperinci daripada tabel penjualan bulanan, tetapi merupakan ringkasan dari orders_database mentah.

Aggregate awareness di Looker biasanya digunakan untuk meringkas atau merangkum data di berbagai periode waktu. Selain itu, tabel gabungan harus dipertahankan dalam instance Looker agar dapat dimanfaatkan untuk aggregate awareness.

Menggabungkan tabel virtual dengan performa tinggi

Cara lain untuk mengoptimalkan performa adalah dengan menggabungkan hanya tabel yang Anda perlukan saat menentukan Eksplorasi baru. Untuk meminimalkan penggabungan, Anda dapat menentukan beberapa Eksplorasi untuk berbagai tujuan (misalnya, mengkueri data menurut pengguna, mengkueri data penjualan agregat). Selain itu, Anda harus menggunakan kolom dasar, bukan kolom gabungan sebagai kunci utama. Jika memungkinkan, gunakan gabungan many_to_one: menggabungkan tabel dari tingkat paling terperinci ke tingkat detail tertinggi (many_to_one) biasanya memberikan performa kueri terbaik di Looker.

Menyertakan filter pada definisi Eksplorasi

Menyertakan filter dalam definisi Jelajah dapat mengoptimalkan performa dengan menghindari pengembalian data dalam jumlah besar secara default. Ada banyak opsi filter, termasuk filter yang terlihat dan dapat dimodifikasi oleh pengguna, seperti always_filter dan conditionally_filter. Anda juga dapat memodifikasi saran filter untuk kolom di Eksplorasi. Untuk informasi selengkapnya dan praktik dengan filter Eksplorasi, coba lab Memfilter Eksplorasi dengan LookML.

Menerapkan kebijakan penyimpanan dalam cache

Untuk mengurangi traffic kueri database, Anda harus memaksimalkan caching untuk disinkronkan dengan kebijakan ekstraksi, pemuatan, dan transformasi (ETL) Anda jika memungkinkan. Secara default, Looker menyimpan kueri dalam cache selama satu jam. Anda dapat mengontrol kebijakan penyimpanan cache dan menyinkronkan refresh data Looker dengan proses ETL Anda menggunakan parameter persist_with untuk menerapkan grup data dalam Eksplorasi. Hal ini memungkinkan Looker berintegrasi lebih erat dengan pipeline data backend sehingga penggunaan cache dapat dimaksimalkan tanpa risiko menganalisis data yang usang.

Misalnya, beberapa tabel data mungkin hanya diperbarui sekali sehari, sehingga merefresh cache setiap jam untuk tabel tersebut tidak akan menambah nilai. Anda menggunakan berbagai opsi untuk menyesuaikan penyimpanan cache di Looker, termasuk grup data, atau kebijakan penyimpanan cache, di lab ini untuk mempertahankan tabel turunan. Untuk informasi selengkapnya dan praktik dengan kebijakan caching, coba lab Caching dan Grup Data dengan LookML.

Pengoptimalan kueri tambahan

Bergantung pada dialek database spesifik Anda, Anda dapat menjelajahi fitur pengoptimalan kueri tambahan, seperti cluster_keys dan indexes.

Tugas 1. Membuat tabel turunan dengan penambahan tetap yang akan diperbarui secara otomatis tanpa membangun ulang seluruh tabel

Seperti yang dijelaskan sebelumnya, tabel turunan persisten (PDT) adalah tabel turunan yang ditulis ke skema sementara di database Anda dan diregenerasi sesuai jadwal yang Anda tentukan dengan strategi persistensi. PDT sangat berguna karena, saat pengguna meminta data dari tabel, tabel tersebut sering kali sudah ada, sehingga mengurangi waktu kueri dan beban database.

Dalam PDT standar, seluruh tabel dibangun ulang sesuai dengan jadwal yang ditetapkan dalam kebijakan penyimpanan cache-nya. Sebaliknya, PDT yang dibuat secara bertahap akan menambahkan data baru ke tabel yang sudah ada. Hal ini dapat mengurangi ukuran kueri yang Anda kirim ke database secara signifikan.

Dalam tugas ini, Anda akan membuat tabel turunan native (NDT) untuk menggabungkan data pesanan berdasarkan jangka waktu atau negara bagian. Anda juga mengaktifkan persistensi dengan refresh harian dan update inkremental yang mundur 3 hari untuk mengambil data yang terlambat.

Menggunakan Eksplorasi untuk membuat tabel turunan native

  1. Klik tombol untuk masuk ke Development mode.

  2. Buka Explore > Order Items.

  3. Di bagian Order Items > Dimensions, pilih yang berikut:

    • Order ID
    • Sale Price
    • Created Date > Date
    • Created Date > Week
    • Created Date > Month
  4. Di bagian Users > Dimensions, pilih State.

  5. Klik Run.

  6. Klik Settings (Ikon setelan/roda gigi).

  7. Pilih Get LookML.

  8. Di tab Derived Table, salin kode LookML ke editor teks.
    Anda akan menggunakan kode ini untuk membuat tampilan baru untuk tabel turunan native.

Membuat file tabel virtual untuk tabel turunan

  1. Buka jendela Looker baru di tab browser baru.

  2. Di menu Develop, klik qwiklabs_ecommerce.

  3. Klik ikon plus (+) di samping File Browser, lalu pilih Create View.

  4. Beri nama file baru incremental_pdt, lalu klik Create.

  5. Di File Browser, klik incremental_pdt.view dan tarik ke folder views.

  6. Ganti kode LookML default di incremental_pdt.view dengan kode yang sebelumnya Anda salin untuk tabel turunan native.

  7. Perbarui baris 4 dengan nama tabel virtual yang benar (incremental_pdt).

  8. Perbarui dimensi order_id untuk mendefinisikannya sebagai primary_key untuk tabel virtual:

dimension: order_id { primary_key: yes type: number }

Hal ini karena setiap kumpulan data merepresentasikan pesanan dengan order_id yang unik.

  1. Temukan dimensi terakhir, lalu tambahkan dua ukuran baru sebelum tanda kurung kurawal penutup terakhir (}) dalam file:
measure: average_sale_price { type: average sql: ${sale_price} ;; value_format_name: usd_0 } measure: total_revenue { type: sum sql: ${sale_price} ;; value_format_name: usd }
  1. Klik Save Changes. File Anda akan terlihat seperti berikut:

File incremental_pdt.view yang menampilkan baris satu hingga 43

Menambahkan persistensi dan update inkremental ke tabel turunan

  1. Buka training_ecommerce.model.

  2. Temukan grup data default bernama training_ecommerce_default_datagroup, dan tambahkan baris baru (baris 13).

  3. Tentukan grup data baru untuk mempertahankan objek dengan refresh harian (waktu maksimal 24 jam):

datagroup: daily_datagroup { sql_trigger: SELECT FORMAT_TIMESTAMP('%F', CURRENT_TIMESTAMP(), 'America/Los_Angeles') ;; max_cache_age: "24 hours" }

sql_trigger memeriksa tanggal saat ini dan memicu refresh saat tanggal berubah, dan max_cache_age memastikan bahwa tabel akan dibangun ulang setelah 24 jam, meskipun sql_trigger gagal dijalankan dengan sukses.

  1. Di akhir training_ecommerce.model (sekitar baris 67), tentukan Eksplorasi baru yang hanya berisi tabel virtual incremental_pdt agar Anda dapat mengujinya pada langkah-langkah berikutnya:
explore: incremental_pdt {}
  1. Klik Save Changes.

File training_ecommerce.model yang terbuka menampilkan baris satu hingga 21

  1. Buka incremental_pdt.view, dan tambahkan persistensi dengan menyertakan datagroup harian dalam definisi tabel turunan di baris 6:
datagroup_trigger: daily_datagroup
  1. Tambahkan update inkremental dengan menyertakan parameter berikut dalam definisi tabel turunan di baris 7 dan 8:
increment_key: "created_date" increment_offset: 3
  1. Klik Save Changes. File Anda akan terlihat seperti berikut:

File incremental_pdt.view yang telah diupdate menampilkan baris satu hingga 21

Tabel turunan persisten kini akan dipertahankan dan akan dibangun ulang sekali sehari, dan mundur 3 hari untuk menangkap pesanan yang mungkin terlambat tiba.

  1. Tutup tab browser untuk kueri Eksplorasi asli, tetapi biarkan tab untuk Looker IDE tetap terbuka.

Menguji kueri Eksplorasi pada tabel turunan dengan penambahan tetap yang persisten

  1. Buka jendela Looker baru di tab browser.

  2. Buka Explore > Incremental Pdt.

  3. Di panel Data, buka tab SQL.

  4. Di bagian Incremental Pdt > Dimensions, pilih Created Date.

  5. Di bagian Incremental Pdt > Measures, pilih Average Sale Price dan Total Revenue.

Sebelum menjalankan kueri, perhatikan bahwa ada dua kueri di jendela SQL (yang mungkin memerlukan waktu beberapa detik untuk dimuat). Kueri pertama menghasilkan PDT bernama incremental_pdt, dan kueri kedua mengambil hasil dari PDT yang baru dibuat.

  1. Klik Run.

  2. Buka tab Results untuk melihat hasilnya.

Hasil PDT inkremental

  1. Di bagian Incremental Pdt > Dimensions:

    • Hapus Tanggal Dibuat.
    • Pilih Created Month.
  2. Di panel Data, buka tab SQL.

Perhatikan bahwa kueri akan menggunakan PDT yang sama untuk mengambil hasil, yang masuk akal karena Anda meminta jangka waktu yang sudah ditentukan (dan di-cache) di PDT. Namun, perhatikan bahwa Anda tidak dapat memilih dan menjalankan kueri pada kerangka waktu lain yang belum disertakan dalam PDT, seperti Quarter atau Year.

  1. Klik Run.

  2. Buka tab Results untuk melihat hasilnya.

Hasil PDT inkremental yang diperbarui

Tantangan

  1. Jalankan kueri baru hanya menggunakan dimensi State dan ukuran Average Sale Price serta Total Revenue. Jawab pertanyaan berikut.

  1. Tutup tab browser untuk kueri Explore, dan kembali ke tab browser dengan Looker IDE.

  2. Klik Validate LookML.
    Tidak boleh ada error LookML.

Melakukan perubahan dan men-deploy ke produksi

  1. Klik Validate LookML, lalu klik Commit Changes & Push.

  2. Tambahkan pesan commit, lalu klik Commit.

  3. Terakhir, klik Deploy to Production.

Tetap berada di tab browser untuk Looker IDE saat Anda memulai tugas berikutnya.

Klik Periksa progres saya untuk memverifikasi tujuan. Membuat tabel turunan dengan penambahan tetap

Tugas 2. Membuat tabel gabungan inkremental untuk meringkas data pesanan di berbagai periode waktu

Di Looker, Anda 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 aggregate awareness. Oleh karena itu, tabel gabungan adalah jenis tabel turunan persisten (PDT).

Tabel gabungan ditentukan menggunakan parameter aggregate_table di bawah parameter Eksplorasi dalam project LookML Anda. Setelah membuat tabel gabungan, Anda dapat menjalankan kueri di Eksplorasi untuk melihat tabel gabungan mana yang digunakan Looker. Looker menggunakan logika kesadaran agregat untuk menemukan tabel gabungan terkecil dan paling efisien yang tersedia di database Anda untuk menjalankan kueri sekaligus mempertahankan kebenaran.

Dalam tugas ini, Anda akan membuat ulang PDT inkremental dari tugas sebelumnya sebagai tabel gabungan inkremental baru. Anda juga membuat tabel gabungan baru tersedia bagi pengguna dengan menggunakan penyempurnaan pada Eksplorasi Item Pesanan yang ada.

Membuat tabel gabungan dalam penyempurnaan Eksplorasi yang ada

  1. Dari halaman Looker IDE, buka training_ecommerce.model.

  2. Di akhir file (sekitar baris 69), tambahkan kode berikut untuk membuat penyempurnaan pada Eksplorasi order_items:

explore: +order_items { label: "Order Items - Aggregate Sales" }

Penyempurnaan ini dibuat berdasarkan Eksplorasi order_items yang ada yang ditentukan dalam file model dan menambahkan modifikasi apa pun yang ditentukan dalam kode LookML baru, seperti label atau tabel gabungan yang akan Anda tambahkan di langkah berikutnya.

  1. Perluas kode LookML untuk penyempurnaan guna menyertakan tabel gabungan yang meringkas data pesanan berdasarkan jangka waktu atau negara bagian:
explore: +order_items { label: "Order Items - Aggregate Sales" aggregate_table: aggregate_sales { query: { dimensions: [order_items.created_date, users.state] measures: [order_items.average_sale_price, order_items.total_revenue] } materialization: { datagroup_trigger: daily_datagroup increment_key: "created_date" increment_offset: 3 } } }

Perhatikan bahwa, tidak seperti tabel turunan native yang Anda buat di tugas sebelumnya, satu-satunya dimensi waktu yang ditentukan dalam tabel gabungan adalah created_date. Dengan aggregate awareness, Looker dapat memanfaatkan satu tabel ini untuk kueri Eksplorasi yang meminta Harga Penjualan Rata-Rata atau Total Pendapatan yang digabungkan berdasarkan waktu, terlepas dari jangka waktu yang diminta (hari, bulan, tahun).

  1. Klik Save Changes.

File training_ecommerce.model yang terbuka menampilkan kode LookML penyempurnaan jelajah item pesanan

Biarkan tab ini tetap terbuka untuk Looker IDE.

Menguji kueri Eksplorasi pada tabel gabungan inkremental persisten

  1. Buka jendela Looker baru di tab browser.

  2. Buka Explore > Order Items - Aggregate Sales.

  3. Di panel Data, buka tab SQL.

  4. Di bagian Order Items > Dimensions, pilih Created Date > Date.

  5. Di bagian Order Items > Measures, pilih Average Sale Price dan Total Revenue.

Sebelum menjalankan kueri, perhatikan bahwa ada dua kueri, mirip dengan jendela SQL di Tugas 1. Kueri pertama menghasilkan PDT bernama aggregate_sales, dan kueri kedua mengambil hasil dari PDT baru ini.

  1. Klik Run.

  2. Buka tab Results untuk melihat hasilnya.

Hasil item pesanan gabungan

  1. Di bagian Order Items > Dimensions > Created Date:

    • Clear Date.
    • Select Quarter.
  2. Di panel Data, buka tab SQL.

Perhatikan bahwa kueri akan menggunakan PDT yang sama (aggregate_sales) untuk mengambil hasil per kuartal. Looker menerapkan aggregate awareness untuk menggabungkan Harga Penjualan Rata-Rata dan Total Pendapatan ke dalam jangka waktu yang diminta yang tersedia di bawah Tanggal Dibuat.

  1. Klik Run.

  2. Buka tab Results untuk melihat hasilnya.

Hasil item pesanan gabungan per kuartal

Tantangan

  1. Jalankan kueri baru hanya menggunakan dimensi State (di bagian Users) serta ukuran Average Sale Price dan Total Revenue. Jawab pertanyaan berikut.

  1. Jalankan kueri baru hanya menggunakan dimensi Country (di bagian Users) dan ukuran Average Sale Price serta Total Revenue. Jawab pertanyaan berikut.

  1. Tutup tab browser untuk kueri Explore, dan kembali ke tab browser dengan Looker IDE.

  2. Klik Validate LookML. Tidak boleh ada error LookML.

Melakukan perubahan dan men-deploy ke produksi

  1. Klik Validate LookML, lalu klik Commit Changes & Push.

  2. Tambahkan pesan commit, lalu klik Commit.

  3. Terakhir, klik Deploy to Production.

Tetap berada di tab browser untuk Looker IDE saat Anda memulai tugas berikutnya.

Klik Periksa progres saya untuk memverifikasi tujuan. Membuat tabel gabungan

Tugas 3. Menggabungkan tabel virtual dengan cara yang berperforma untuk mengoptimalkan kueri Eksplorasi

Penggabungan yang efisien adalah komponen penting dalam menentukan Eksplorasi yang berperforma baik di Looker. Untuk meningkatkan efisiensi gabungan, pastikan untuk hanya menggabungkan tabel virtual yang diperlukan untuk menentukan Eksplorasi, gunakan kolom dasar (bukan kolom gabungan) sebagai kunci utama untuk tabel virtual, dan gunakan gabungan many_to_one jika memungkinkan.

Seperti yang dijelaskan dalam dokumentasi, kunci utama memberikan ID unik untuk kumpulan data dalam sebuah tabel dan penting untuk agregasi dan hubungan yang akurat di Looker. Kunci utama untuk tabel virtual adalah field yang berisi nilai unik (seperti kolom ID) dan diidentifikasi dalam file tabel virtual dengan parameter primary_key: yes.

Di bagian ini, Anda akan mengidentifikasi kolom yang paling tepat untuk menggunakan kunci utama untuk tabel virtual. Kemudian, Anda akan menentukan Eksplorasi baru untuk tabel gabungan dengan hanya tabel virtual pengguna yang digabungkan, menggunakan parameter from untuk menentukan order_items sebagai tabel virtual dasar Eksplorasi, lalu menggabungkan tabel virtual pengguna. Terakhir, Anda menghilangkan gabungan tambahan yang disertakan dalam Eksplorasi Item Pesanan yang ada dan menggunakan hubungan gabungan many_to_one untuk mendukung efisiensi kueri.

Mengidentifikasi kolom yang paling tepat untuk digunakan sebagai kunci utama tabel virtual

  1. Buka file users.view. Jawab pertanyaan berikut.

Di users.view, kolom IDd sudah diidentifikasi sebagai kunci utama menggunakan primary_key: yes. Kolom tersebut adalah kolom dasar yang berisi nilai unik (satu ID untuk setiap pengguna) dan bukan kolom gabungan yang dibuat dari beberapa kolom. Oleh karena itu, ID adalah pilihan terbaik untuk kunci utama tabel pengguna dan dapat mendukung penggabungan yang efisien.

  1. Buka file order_items.view. Jawab pertanyaan berikut.

order_item_id didasarkan pada kolom ID di tabel order_items dan diidentifikasi sebagai kunci utama. Namun, kolom ID lain dalam tabel ini berpotensi menjadi kunci unik tabel, termasuk order_id, yang didasarkan pada kolom order_id di tabel order_items.

Pada langkah berikutnya, Anda akan menjelajahi tabel order_items di SQL Runner untuk mengidentifikasi mengapa order_item_id adalah kolom terbaik untuk menggunakan primary_key.

  1. Buka jendela Looker baru di tab browser baru.

  2. Buka Develop > SQL Runner.

  3. Klik Settings (Ikon setelan/roda gigi) di samping Connection, lalu pilih Search public projects.

Jendela SQL Runner

  1. Kotak Project sekarang akan kosong. Ketik cloud-training-demos, lalu tekan ENTER.

  2. Untuk Dataset, pilih looker_ecomm.
    Daftar tabel yang tersedia di set data BigQuery ini akan ditampilkan.

Metode cepat dan mudah untuk memeriksa apakah suatu kolom merupakan kunci utama yang tepat atau tidak adalah dengan membandingkan jumlah kumpulan data dalam tabel dengan jumlah nilai unik dalam kolom. Jika kedua jumlah tersebut cocok, kolom tersebut berisi nilai unik dan merupakan kunci utama yang tepat untuk tabel.

  1. Untuk memeriksa apakah kolom user_id akan menjadi kunci utama yang tepat, tambahkan kueri berikut ke jendela SQL Query, lalu klik Run:
SELECT count(*), count(distinct user_id) FROM cloud-training-demos.looker_ecomm.order_items
  1. Ulangi kueri untuk kolom order_id, inventory_item_id, dan id.

Dalam kasus ini, id dan inventory_item_id cocok dengan jumlah kumpulan data dalam tabel karena keduanya adalah ID yang berbeda untuk item yang sama dalam suatu pesanan. Oleh karena itu, keduanya berpotensi digunakan sebagai kunci utama.

Kolom id dipilih sebagai kunci utama untuk order_items karena merupakan ID yang dihasilkan untuk suatu item dalam tabel order_items, tetapi inventory_item_id adalah ID item yang sama dalam tabel inventory_items.

  1. Tutup tab browser untuk SQL Runner, lalu kembali ke tab browser dengan Looker IDE.

Menggabungkan jumlah tabel virtual minimum untuk menentukan Eksplorasi baru

  1. Buka training_ecommerce.model.

  2. Tinjau Eksplorasi order_items yang ada.

Perhatikan bahwa kueri ini menyertakan empat gabungan berbeda yang masing-masing menggunakan jenis hubungan many_to_one. Bergantung pada kasus penggunaan Anda, semua penggabungan ini mungkin diperlukan. Namun, bagaimana jika Anda hanya memerlukan data pengguna dan pesanan yang digabungkan berdasarkan negara bagian atau jangka waktu? Jika demikian, gabungan tambahan ini tidak akan pernah digunakan dan akan memperlambat kueri di Eksplorasi.

Pada langkah berikutnya, Anda akan membuat Eksplorasi baru yang hanya menggabungkan data pesanan dan pengguna, berdasarkan user_id di tabel virtual order_items dan id di tabel virtual users.

  1. Di akhir file (sekitar baris 85), tambahkan kode berikut untuk menentukan Eksplorasi baru dengan order_items sebagai tabel dasar dan hanya tabel users yang digabungkan:
explore: aggregated_orders { from: order_items label: "Aggregated Sales" join: users { type: left_outer sql_on: ${aggregated_orders.user_id} = ${users.id} ;; relationship: one_to_many } aggregate_table: aggregate_sales { query: { dimensions: [aggregated_orders.created_date, users.state] measures: [aggregated_orders.average_sale_price, aggregated_orders.total_revenue] } materialization: { datagroup_trigger: daily_datagroup increment_key: "created_date" increment_offset: 3 } } }
  1. Klik Save Changes.
    File Anda akan terlihat seperti berikut:

File training_ecoomerce.model menampilkan baris kode untuk aggregate_sales explore

Parameter from digunakan untuk menentukan order_items sebagai tabel dasar Eksplorasi, yang akan digabungkan dengan tabel users. Kolom dalam tabel virtual order_items kini diidentifikasi menggunakan nama Eksplorasi baru sebagai aggregated_orders.fieldname.

Perhatikan juga bahwa hubungan antara tabel virtual users dan tabel virtual order_items saat ini diidentifikasi sebagai one_to_many. Pada langkah berikutnya, Anda akan menguji apakah gabungan ini berdasarkan hubungan one_to_many adalah konfigurasi yang paling optimal untuk Jelajah ini.

Menentukan hubungan gabungan yang berperforma baik untuk kueri Eksplorasi yang efisien

  1. Buka jendela Looker baru di tab browser baru.

  2. Buka Explore > Aggregated Sales.

  3. Di panel Data, buka tab SQL.

  4. Di bagian Aggregated Orders > Dimensions, pilih Created Date > Date.

  5. Di bagian Aggregated Orders > Measures, pilih:

    • Harga Jual Rata-rata
    • Pendapatan Total

Sebelum menjalankan kueri, perhatikan bahwa tabel gabungan tidak digunakan karena masalah fanout gabungan:

-- Did not use aggregated_orders::aggregate_sales; field aggregated_orders.average_sale_price was DISTINCT in the table due to a join fanout, but there was no fanout in the query

Fanout yang tidak diinginkan dapat terjadi jika hubungan antara dua tabel tidak diidentifikasi dengan benar untuk penggabungan. Dalam hal ini, tabel virtual dasar Explore adalah order_items, yang dapat berisi banyak pesanan untuk satu pengguna. Namun, tabel users hanya berisi satu kumpulan data untuk setiap pengguna.

Oleh karena itu, gabungan ini seharusnya didefinisikan sebagai many_to_one, atau banyak pesanan untuk satu pengguna, bukan satu pesanan untuk banyak pengguna. (Pelajari lebih lanjut masalah fanout di Pusat Bantuan Looker.)

  1. Klik Run.

  2. Buka tab Hasil.
    Hasilnya ditampilkan, tetapi Looker tidak menggunakan tabel gabungan yang efisien untuk mengambil hasil.

  3. Biarkan tab browser untuk Eksplorasi tetap terbuka, dan kembali ke tab browser dengan Looker IDE.

  4. Update parameter relationship ke many_to_one (baris 91) di aggregated_orders explore:

relationship: many_to_one
  1. Klik Save Changes.
    File Anda akan terlihat seperti berikut:

File training_ecommerce.model menampilkan baris kode untuk penggunaan relasi many-to-one

  1. Kembali ke tab browser untuk kueri Eksplorasi, lalu muat ulang halaman.

  2. Di panel Data, buka tab SQL.

Mirip dengan tab SQL untuk Tugas 1 dan 2, sekarang ada dua kueri: yang pertama untuk membuat PDT dan yang kedua untuk mengambil hasil dari PDT.

  1. Buka tab Results untuk melihat hasilnya.

Hasil penjualan gabungan

  1. Tutup tab browser untuk kueri Explore, dan kembali ke tab browser dengan Looker IDE.

  2. Klik Validate LookML.
    Tidak boleh ada error LookML.

Melakukan perubahan dan men-deploy ke produksi

  1. Klik Validate LookML, lalu klik Commit Changes & Push.

  2. Tambahkan pesan commit, lalu klik Commit.

  3. Terakhir, klik Deploy to Production.

Tetap berada di tab browser untuk Looker IDE saat Anda memulai tugas berikutnya.

Klik Periksa progres saya untuk memverifikasi tujuan. Menggabungkan jumlah minimum tabel ke Eksplorasi baru

Tugas 4. Memantau build tabel turunan persisten di instance Looker

Looker menyediakan kemampuan untuk memantau build PDT di instance Looker melalui halaman Persistent Derived Tables pada menu Admin. Bergantung pada konfigurasi Looker, pengguna Looker dengan hak istimewa untuk mempertahankan tabel dapat melihat halaman ini meskipun tanpa akses ke menu Admin lengkap. Anda dapat memeriksa status, waktu build, dan penyimpanan cache PDT di lingkungan pengembangan dan produksi sehingga Anda dapat dengan mudah menguji dan memantau PDT di instance Looker Anda.

Dalam tugas ini, Anda akan memantau PDT yang dibuat di lab ini terkait status, waktu build, caching, dan produksi versus pengembangan. PDT inkremental yang dibuat dari NDT (Tugas 1) harus memiliki waktu build terlama, dan tabel gabungan (Tugas 2 dan 3) harus memiliki waktu build tercepat. Hal ini disebabkan karena keduanya menggunakan definisi tabel yang sama, tetapi disertakan dalam Eksplorasi yang dikonfigurasi secara berbeda. Anda juga akan memodifikasi PDT dalam pengembangan dan memantau statusnya sebelum dan sesudah didorong ke produksi.

Meninjau status PDT dalam produksi

  1. Buka jendela Looker baru di tab browser baru.

  2. Buka Admin > Persistent Derived Tables.
    Tidak ada PDT yang tercantum di tab Development karena semua PDT Anda telah didorong ke produksi.

  3. Buka tab Production untuk melihat PDT yang Anda buat di Tugas 1-3.

Halaman All Connection terbuka di halaman tab Production, yang menampilkan PDT dalam produksi

Last Attempt Status menampilkan Success untuk semua PDT, dan semuanya menggunakan aturan persistensi yang sama (daily_datagroup). Untuk waktu build di bawah Last Build Duration, incremental_pdt mungkin memiliki build yang sedikit lebih lama daripada dua tabel gabungan.

Biarkan halaman Persistent Derived Tables ini terbuka saat Anda memulai langkah berikutnya.

Memodifikasi dan meninjau PDT dalam pengembangan

  1. Kembali ke tab browser dengan Looker IDE.

  2. Buka training_ecommerce.model.

  3. Tambahkan dimensi baru untuk users.country ke Explore aggregated_orders (sekitar baris 96):

dimensions: [aggregated_orders.created_date, users.state, users.country]
  1. Klik Save Changes.

  2. Kembali ke halaman Persistent Derived Tables, lalu muat ulang halaman.

Di tab Production, PDT aggregated_orders::aggregate_sales masih tercantum sebagai dibangun, meskipun Anda telah memodifikasi kode LookML untuk PDT dalam mode pengembangan.

Looker memungkinkan developer menguji perubahan pada PDT dalam mode pengembangan, mirip dengan cara developer bekerja dengan objek Looker lainnya dalam mode pengembangan. Misalnya, saat developer membuat dimensi dan ukuran baru dalam mode pengembangan, objek baru ini tidak akan muncul dalam produksi hingga developer melakukan commit perubahan dan men-deploy-nya ke produksi.

  1. Buka tab Development.

  1. Biarkan halaman Persistent Derived Tables ini tetap terbuka, lalu buka jendela Looker baru di tab browser baru.

  2. Buka Explore > Aggregate Sales.

  3. Di panel Data, buka tab SQL.

  4. Di bagian Users > Dimensions, pilih Country.

  5. Di bagian Aggregated Orders > Measures, pilih:

    • Harga Jual Rata-rata
    • Pendapatan Total

Ada dua kueri di tab SQL: yang pertama menghasilkan PDT, dan yang kedua mengambil hasil dari PDT yang baru dibuat.

  1. Klik Run.

  2. Buka tab Results untuk melihat hasilnya.

  3. Tutup tab browser untuk kueri Eksplorasi, kembali ke tab browser dengan halaman Persistent Derived Tables, dan muat ulang halaman.

Tab Development kini menunjukkan bahwa aggregated_orders::aggregate_sales telah berhasil dibuat.

  1. Biarkan tab browser untuk halaman Persistent Derived Tables tetap terbuka, dan kembali ke tab browser dengan Looker IDE.

  2. Klik Validate LookML.
    Tidak ada error LookML.

Melakukan perubahan dan men-deploy ke produksi

  1. Klik Validate LookML, lalu klik Commit Changes & Push.

  2. Tambahkan pesan commit, lalu klik Commit.

  3. Terakhir, klik Deploy to Production.

Kembali ke tab browser dengan halaman Persistent Derived Tables, lalu muat ulang halaman. Setelah perubahan pada produksi di-deploy, aggregated_orders::aggregate_sales PDT tidak lagi tercantum di tab Development, tetapi hanya tercantum di tab Production.

Selamat!

Di lab ini, Anda telah mempelajari kapan dan bagaimana cara menambahkan persistensi dan update inkremental ke tabel turunan, menggunakan aggregate awareness, menggabungkan tabel virtual dengan performa yang baik, dan memantau build PDT untuk mengoptimalkan kueri Looker.

Langkah berikutnya/Pelajari lebih lanjut

Sertifikasi dan pelatihan Google Cloud

...membantu Anda mengoptimalkan teknologi Google Cloud. Kelas kami mencakup keterampilan teknis dan praktik terbaik untuk membantu Anda memahami dengan cepat dan melanjutkan proses pembelajaran. Kami menawarkan pelatihan tingkat dasar hingga lanjutan dengan opsi on demand, live, dan virtual untuk menyesuaikan dengan jadwal Anda yang sibuk. Sertifikasi membantu Anda memvalidasi dan membuktikan keterampilan serta keahlian Anda dalam teknologi Google Cloud.

Manual Terakhir Diperbarui pada 23 April 2024

Lab Terakhir Diuji pada 6 Oktober 2023

Hak cipta 2026 Google LLC. Semua hak dilindungi undang-undang. Google dan logo Google adalah merek dagang dari Google LLC. Semua nama perusahaan dan produk lain mungkin adalah merek dagang masing-masing perusahaan yang bersangkutan.

Sebelum memulai

  1. Lab membuat project dan resource Google Cloud untuk jangka waktu tertentu
  2. Lab memiliki batas waktu dan tidak memiliki fitur jeda. Jika lab diakhiri, Anda harus memulainya lagi dari awal.
  3. Di kiri atas layar, klik Start lab untuk memulai

Gunakan penjelajahan rahasia

  1. Salin Nama Pengguna dan Sandi yang diberikan untuk lab tersebut
  2. Klik Open console dalam mode pribadi

Login ke Konsol

  1. Login menggunakan kredensial lab Anda. Menggunakan kredensial lain mungkin menyebabkan error atau dikenai biaya.
  2. Setujui persyaratan, dan lewati halaman resource pemulihan
  3. Jangan klik End lab kecuali jika Anda sudah menyelesaikan lab atau ingin mengulanginya, karena tindakan ini akan menghapus pekerjaan Anda dan menghapus project

Konten ini tidak tersedia untuk saat ini

Kami akan memberi tahu Anda melalui email saat konten tersedia

Bagus!

Kami akan menghubungi Anda melalui email saat konten tersedia

Satu lab dalam satu waktu

Konfirmasi untuk mengakhiri semua lab yang ada dan memulai lab ini

Gunakan penjelajahan rahasia untuk menjalankan lab

Gunakan jendela Samaran atau browser pribadi untuk menjalankan lab ini. Langkah ini akan mencegah konflik antara akun pribadi Anda dan akun Siswa yang dapat menyebabkan tagihan ekstra pada akun pribadi Anda.