Mengoptimalkan performa Looker

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

Mengoptimalkan performa kueri

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

  • Buat Eksplorasi menggunakan gabungan many_to_one jika memungkinkan. Menggabungkan tampilan 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 untuk 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 berintegrasi lebih erat dengan pipeline data backend, sehingga penggunaan cache dapat dimaksimalkan tanpa risiko menganalisis data yang usang. Kebijakan caching bernama dapat diterapkan ke seluruh model dan/atau ke setiap Eksplorasi dan tabel turunan persisten (PDT).
  • Gunakan fungsi aggregate awareness Looker untuk membuat tabel ringkasan atau rollup yang dapat digunakan Looker untuk kueri jika memungkinkan, terutama untuk kueri umum database besar. Anda juga dapat memanfaatkan kesadaran gabungan untuk meningkatkan performa seluruh dasbor secara drastis. Lihat Tutorial kesadaran gabungan untuk mengetahui informasi tambahan.
  • Gunakan PDT untuk kueri yang lebih cepat. Konversi Eksplorasi dengan banyak gabungan yang kompleks atau tidak berperforma baik, atau dimensi dengan subkueri atau subpilihan, menjadi PDT sehingga tampilan telah digabungkan sebelumnya dan siap sebelum runtime.
  • Jika dialek database Anda mendukung PDT inkremental, konfigurasi PDT inkremental untuk mengurangi waktu yang digunakan Looker untuk membangun ulang PDT.
  • Hindari menggabungkan tampilan ke dalam Eksplorasi pada kunci utama yang digabungkan dan ditentukan di Looker. Sebagai gantinya, gabungkan kolom dasar yang membentuk kunci utama gabungan dari tampilan. Atau, buat ulang tampilan sebagai PDT dengan kunci utama yang digabungkan yang telah ditentukan sebelumnya dalam definisi SQL tabel, bukan dalam LookML tampilan.
  • Gunakan alat Explain in SQL Runner untuk 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 Tampilkan Indeks.

    Kolom paling umum yang dapat memanfaatkan indeks adalah tanggal penting dan kunci asing. 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 langkah-langkah untuk memastikan server dan aplikasi Looker berjalan secara optimal:

  • Membatasi jumlah elemen dalam setiap dasbor. Tidak ada aturan yang tepat untuk menentukan jumlahnya, karena desain setiap elemen memengaruhi konsumsi memori berdasarkan berbagai faktor; namun, dasbor dengan 25 kartu atau lebih cenderung menimbulkan masalah terkait performa.
  • Gunakan fitur pemuatan ulang otomatis dasbor secara strategis. Jika dasbor menggunakan refresh otomatis, pastikan dasbor tidak di-refresh lebih cepat daripada proses ETL yang berjalan di latar belakang.
  • Gunakan perputaran secara strategis, dan hindari penggunaan perputaran yang berlebihan dalam kartu dasbor dan Look. Kueri dengan dimensi yang diputar akan menggunakan lebih banyak memori. Semakin banyak dimensi yang diubah, semakin banyak memori yang digunakan saat konten (Eksplorasi, Look, atau dasbor) dimuat.
  • Gunakan fitur, seperti gabungkan hasil, kolom kustom, dan kalkulasi tabel, dengan hemat. Fitur ini dimaksudkan untuk digunakan sebagai bukti konsep untuk membantu mendesain model Anda. Sebaiknya lakukan pengodean permanen untuk 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.
  • Batasi jumlah tampilan yang disertakan dalam model jika ada banyak file tampilan. Menyertakan semua tampilan dalam satu model dapat memperlambat performa. Jika ada banyak tampilan dalam project, pertimbangkan untuk menyertakan hanya file tampilan yang diperlukan dalam setiap model. Pertimbangkan untuk menggunakan konvensi penamaan strategis untuk nama file tampilan, agar dapat menyertakan grup tampilan dalam model. Contohnya diuraikan dalam dokumentasi parameter includes.
  • Hindari menampilkan sejumlah besar titik data secara default dalam kartu 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 Eksplorasi, serta di tingkat LookML dengan parameter required filters, conditionally_filter, dan sql_always_where.
  • Download atau kirimkan kueri menggunakan opsi Semua Hasil dengan hemat, karena beberapa kueri bisa sangat besar dan membebani server Looker saat diproses.
  • Pahami dampak performa koneksi pada seluruh instance Looker. Looker menggunakan resource bersama untuk memproses kueri dari semua koneksi database. Resource ini mencakup pod Kubernetes, antrean kueri, dan kumpulan thread. Karena infrastruktur yang digunakan 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 yang terkait langsung dengan dasbor atau Eksplorasi yang lambat.

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