Mengoptimalkan performa Looker

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

Mengoptimalkan performa kueri

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

  • Buat Explore menggunakan many_to_one join jika memungkinkan. Gabungan tampilan dari tingkat yang paling terperinci ke tingkat detail tertinggi (many_to_one) biasanya memberikan performa kueri terbaik.
  • Maksimalkan penyimpanan cache untuk menyinkronkan dengan kebijakan ETL Anda jika memungkinkan untuk mengurangi traffic kueri database. Secara default, Looker menyimpan kueri dalam cache selama satu jam. Anda dapat mengontrol kebijakan caching dan menyinkronkan pembaruan data Looker dengan proses ETL dengan menerapkan grup data dalam Jelajah, menggunakan parameter persist_with. Hal ini memungkinkan Looker terintegrasi lebih erat dengan pipeline data backend, sehingga penggunaan cache dapat dimaksimalkan tanpa risiko menganalisis data yang sudah tidak berlaku. Kebijakan penyimpanan cache bernama dapat diterapkan ke seluruh model dan/atau ke masing-masing Jelajah dan tabel turunan persisten (PDT).
  • Gunakan fungsi aggregate awareness di Looker untuk membuat tabel ringkasan atau tabel ringkasan yang dapat digunakan Looker untuk kueri jika memungkinkan, terutama untuk kueri umum database besar. Anda juga dapat memanfaatkan awareness gabungan untuk meningkatkan performa seluruh dasbor secara drastis. Lihat Tutorial awareness gabungan untuk informasi tambahan.
  • Gunakan PDT untuk kueri yang lebih cepat. Konversikan Explore dengan banyak join yang kompleks atau tidak berperforma, atau dimensi dengan subkueri atau subpilihan, menjadi PDT sehingga tampilan sudah bergabung sebelumnya dan siap sebelum runtime.
  • Jika dialek database Anda mendukung PDT inkremental, konfigurasikan PDT inkremental untuk mengurangi waktu yang dihabiskan Looker untuk membangun kembali tabel PDT.
  • Hindari menggabungkan tampilan ke dalam Jelajah pada kunci utama gabungan yang ditentukan di Looker. Sebagai gantinya, gabungkan pada kolom dasar yang membentuk kunci utama sambungan dari tampilan. Atau, buat kembali tampilan sebagai PDT dengan kunci utama gabungan yang telah ditetapkan sebelumnya dalam definisi SQL tabel, bukan dalam LookML tampilan.
  • Manfaatkan alat Jelaskan di SQL Runner untuk menjalankan benchmark. 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 Pelari SQL dengan mengklik ikon roda gigi di tabel, lalu memilih Tampilkan Indeks.

    Kolom paling umum yang dapat diuntungkan dengan indeks adalah tanggal penting dan {i>foreign key<i}. Menambahkan indeks ke kolom ini akan meningkatkan performa untuk 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 tindakan untuk memastikan server dan aplikasi Looker berperforma optimal:

  • Batasi jumlah elemen dalam setiap dasbor. Tidak ada aturan pasti untuk menentukan angka, karena desain setiap elemen memengaruhi konsumsi memori berdasarkan berbagai faktor; namun, dasbor dengan 25 ubin atau lebih cenderung bermasalah dalam hal performa.
  • Gunakan fitur refresh otomatis dasbor secara strategis. Jika dasbor menggunakan refresh otomatis, pastikan dasbor dimuat ulang tidak lebih cepat dari proses ETL yang berjalan di balik layar.
  • Gunakan pivot secara strategis, dan hindari penggunaan pivot secara berlebihan dalam ubin dasbor dan Tampilan. Kueri dengan dimensi yang dipivot akan menggunakan lebih banyak memori. Semakin banyak dimensi yang diubah, semakin banyak memori yang terpakai saat konten (Jelajahi, Tampilan, atau dasbor) dimuat.
  • Gunakan fitur pemrosesan pascakueri, seperti hasil penggabungan, kolom kustom, dan penghitungan tabel, dengan hemat. Fitur-fitur ini dimaksudkan untuk digunakan sebagai bukti konsep untuk membantu mendesain model Anda. Praktik terbaik 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 memperebutkan memori Java pada instance Looker, sehingga menyebabkan instance Looker merespons lebih lambat.
  • Membatasi jumlah tampilan yang disertakan dalam model ketika ada banyak file tampilan. Menyertakan semua tampilan dalam satu model dapat memperlambat performa. Jika ada banyak tampilan dalam project, pertimbangkan untuk hanya menyertakan file tampilan yang diperlukan dalam setiap model. Pertimbangkan untuk menggunakan konvensi penamaan strategis untuk nama file tampilan, guna memudahkan penyertaan kelompok tampilan dalam model. Contohnya diuraikan dalam dokumentasi parameter includes.
  • Hindari menampilkan sejumlah besar titik data secara default dalam ubin dasbor dan Tampilan. Kueri yang menampilkan ribuan titik data akan menggunakan lebih banyak memori. Pastikan data dibatasi sebisa mungkin dengan menerapkan filter frontend ke dasbor, Tampilan dan Jelajah, serta pada tingkat LookML dengan parameter required filters, conditionally_filter, dan sql_always_where.
  • Download atau kirimkan kueri menggunakan opsi Semua Hasil seperlunya, karena beberapa kueri dapat berukuran sangat besar dan membebani server Looker saat diproses.

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