Mengoptimalkan performa Looker

Praktik terbaik ini mencerminkan rekomendasi yang telah dibagikan oleh tim lintas fungsi Looker yang berpengalaman. Insight ini berasal dari pengalaman bertahun-tahun bekerja dengan pelanggan Looker, mulai dari implementasi hingga kesuksesan jangka panjang. Praktik ini ditulis agar dapat diterapkan oleh sebagian besar pengguna dan situasi, tetapi Anda harus menggunakan penilaian terbaik Anda saat menerapkannya.

Mengoptimalkan performa kueri

Anda dapat memastikan bahwa kueri dibuat dan dijalankan secara optimal terhadap database Anda dengan tips frontend dan backend berikut:

• Buat Eksplorasi menggunakan gabungan many_to_one jika memungkinkan. Menggabungkan tabel virtual dari tingkat paling terperinci ke tingkat detail tertinggi (many_to_one) biasanya memberikan performa kueri terbaik.
• Maksimalkan caching untuk disinkronkan dengan kebijakan ETL Anda jika memungkinkan guna mengurangi traffic kueri database. 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 dengan menerapkan grup data dalam Eksplorasi, menggunakan parameter persist_with. Hal ini memungkinkan Looker untuk berintegrasi lebih erat dengan pipeline data backend, sehingga penggunaan cache dapat dimaksimalkan tanpa risiko menganalisis data yang tidak berlaku. Kebijakan caching bernama dapat diterapkan ke seluruh model dan/atau ke Eksplorasi tertentu dan tabel turunan persisten (PDT).
• Gunakan fungsi aggregate awareness Looker untuk membuat tabel ringkasan atau roll-up yang dapat digunakan Looker untuk kueri jika memungkinkan, terutama untuk kueri umum database besar. Anda juga dapat memanfaatkan awareness agregat untuk meningkatkan performa seluruh dasbor secara drastis. Lihat Tutorial aggregate awareness untuk mengetahui informasi tambahan.
• Gunakan PDT untuk kueri yang lebih cepat. Konversikan Eksplorasi dengan banyak gabungan yang kompleks atau tidak berperforma, atau dimensi dengan subkueri atau subpilihan, menjadi PDT sehingga tabel virtual digabungkan sebelumnya dan siap sebelum runtime.
• Jika dialek database Anda mendukung PDT inkremental, konfigurasikan PDT inkremental untuk mengurangi waktu yang dihabiskan Looker untuk membangun ulang PDT.
• Hindari menggabungkan tabel virtual ke dalam Eksplorasi pada kunci utama yang digabungkan yang ditentukan di Looker. Sebagai gantinya, gabungkan kolom dasar yang membentuk kunci utama gabungan dari tabel virtual. Atau, buat ulang tabel virtual sebagai PDT dengan kunci utama gabungan yang telah ditentukan sebelumnya dalam definisi SQL tabel, bukan dalam LookML tabel virtual.
• Gunakan alat Explain in SQL Runner untuk melakukan tolok ukur. EXPLAIN menghasilkan ringkasan rencana eksekusi kueri database Anda untuk kueri SQL tertentu, sehingga Anda dapat mendeteksi komponen kueri yang dapat dioptimalkan. Pelajari lebih lanjut di Postingan komunitas Cara mengoptimalkan SQL dengan EXPLAIN.
• Mendeklarasikan indeks. Anda dapat melihat indeks setiap tabel langsung di Looker dari SQL Runner dengan mengklik ikon roda gigi di tabel, lalu memilih Show Indexes.
  Kolom yang paling umum yang dapat memanfaatkan indeks adalah tanggal penting dan kunci asing. Menambahkan indeks ke kolom ini akan meningkatkan performa hampir semua kueri. Hal ini juga berlaku untuk PDT. Parameter LookML, seperti indexes, sort keys, dan distribution, dapat diterapkan dengan tepat.
• Tingkatkan memori, core, dan I/O (input/output) database dengan hardware yang tidak memadai atau resource yang disediakan yang diperlukan (seperti AWS) untuk memproses set data besar, guna meningkatkan performa kueri.

Mengoptimalkan performa server Looker

Anda juga dapat mengambil langkah-langkah untuk memastikan server dan aplikasi Looker berperforma optimal:

• Batasi jumlah elemen dalam satu dasbor. Tidak ada aturan pasti untuk menentukan jumlahnya, karena desain setiap elemen memengaruhi konsumsi memori berdasarkan berbagai faktor; namun, dasbor dengan 25 ubin atau lebih cenderung bermasalah dalam hal performa.
• Gunakan fitur pemuatan ulang otomatis dasbor secara strategis. Jika dasbor menggunakan pemuatan ulang otomatis, pastikan dasbor tidak dimuat ulang lebih cepat daripada proses ETL yang berjalan di balik layar.
• Gunakan pivot secara strategis, dan hindari penggunaan pivot yang berlebihan dalam tile dasbor dan Look. Kueri dengan dimensi yang di-pivot akan menggunakan lebih banyak memori. Semakin banyak dimensi yang di-pivot, semakin banyak memori yang digunakan saat konten (Explore, Look, atau dasbor) dimuat.
• Gunakan fitur seperti kolom kustom dan kalkulasi tabel, seperlunya. Fitur ini dimaksudkan untuk digunakan sebagai bukti konsep guna membantu mendesain model Anda. Praktik terbaiknya adalah melakukan hardcode pada penghitungan dan fungsi yang sering digunakan di LookML, yang akan menghasilkan SQL untuk diproses di database Anda. Penghitungan yang berlebihan dapat bersaing untuk mendapatkan memori Java di instance Looker, sehingga menyebabkan instance Looker merespons lebih lambat.
• Untuk kueri hasil gabungan, gunakan kueri penggabungan dalam database jika memungkinkan. Kueri penggabungan dalam database diproses di database Anda, bukan di memori Looker.
• Membatasi jumlah tabel virtual yang disertakan dalam model jika ada banyak file tabel virtual. Menyertakan semua tabel virtual dalam satu model dapat memperlambat performa. Jika ada banyak tabel virtual dalam sebuah project, pertimbangkan untuk hanya menyertakan file tabel virtual yang diperlukan dalam setiap model. Pertimbangkan untuk menggunakan konvensi penamaan strategis untuk nama file tampilan, agar grup tampilan dapat disertakan dalam model. Contohnya diuraikan dalam dokumentasi parameter includes.
• Hindari menampilkan titik data dalam jumlah besar secara default dalam tile dasbor dan Look. Kueri yang menampilkan ribuan titik data akan menggunakan lebih banyak memori. Pastikan data dibatasi jika memungkinkan dengan menerapkan filter frontend ke dasbor, Look, dan Explore, serta di level LookML dengan parameter required filters, conditionally_filter, dan sql_always_where.
• Download atau kirim kueri menggunakan opsi All Results dengan hemat, karena beberapa kueri bisa sangat besar dan membebani server Looker saat diproses.
• Memahami dampak performa koneksi terhadap seluruh instance Looker. Looker menggunakan resource bersama untuk memproses kueri dari semua koneksi database. Resource ini mencakup pod Kubernetes, antrean kueri, dan thread pool. Karena infrastruktur bersama ini, satu koneksi database yang lambat atau kelebihan beban dapat berdampak negatif pada performa kueri di semua koneksi lainnya. Jika Anda melihat penurunan performa yang meluas, selidiki kondisi semua koneksi database Anda, bukan hanya koneksi yang terkait langsung dengan dasbor atau Eksplorasi yang lambat.
• Distribusikan pengiriman terjadwal dan hindari eksekusi tugas secara bersamaan. Jika beberapa Look atau dasbor dijadwalkan untuk dijalankan pada menit yang sama persis (terutama di awal jam), lonjakan permintaan kueri simultan yang tiba-tiba dapat membebani resource instance, meningkatkan kedalaman antrean, dan menghabiskan kumpulan koneksi database. Bottleneck konkurensi ini dapat menyebabkan pengiriman terjadwal dan kueri Explore interaktif terhenti selama fase inisialisasi kueri. Gunakan strategi berikut untuk mencegah bottleneck konkurensi:
  • Atur jadwal tugas terjadwal dalam interval 15 menit atau 30 menit (atau menit yang tidak berada di awal jam seperti :15, :30, atau :45), bukan menjadwalkan semua pengiriman di awal jam.
  • Jika memungkinkan, gunakan datagroup untuk memicu pengiriman yang didasarkan pada penyelesaian ETL, bukan jadwal berbasis waktu, sehingga mencegah kueri yang tidak perlu terhadap data yang belum diperbarui.
  • Kelompokkan atau batasi skrip eksternal dan panggilan API otomatis yang menjalankan kueri atau memicu pengiriman.
  • Jika lonjakan kueri yang tiba-tiba menyebabkan instance Anda tidak responsif atau kueri berputar tanpa batas, Anda dapat menghapus tugas yang sedang diproses dengan memulai ulang instance (lihat Memulai ulang instance Looker (Google Cloud core) untuk instance Looker (Google Cloud core)).

Untuk mendapatkan bantuan lebih lanjut dalam mengidentifikasi sumber masalah performa, lihat halaman Praktik Terbaik Ringkasan performa.