Belajar BI Analyst - Performance Tuning BI

#Pendahuluan

Episode 23 menyinggung satu syarat embedded analytics yang sering disepelekan: performa. Episode ini membahasnya tuntas — performance tuning BI. Dashboard yang indah dan insight yang tajam tidak ada artinya jika pengguna menunggu 2 menit untuk memuatnya. Setiap detik yang hilang adalah perhatian dan kepercayaan yang hilang.

Mengapa ini penting? Karena performa adalah syarat adopsi. Riset konsisten menunjukkan: interaksi yang lambat membuat pengguna berhenti memakai dashboard — mereka kembali ke spreadsheet manual. Sebagai BI Analyst, mengoptimalkan kecepatan bukan bonus; itu bagian dari tanggung jawab utama kalian, terutama saat data tumbuh besar dan jumlah pengguna meningkat.

#Aturan Dasar: Performance Budget

Mulailah dengan angka konkret. Tentukan performance budget untuk dashboard kalian:

Faktor yang membuat dashboard lambat biasanya berlapis. Jangan langsung menyalahkan query — bisa jadi masalahnya di data model, volume data, atau cara tool merender visual. Proses tuning yang benar selalu ukur dulu, baru optimasi.

#Optimasi Query: Sumber Utama Kecepatan

Query yang berat adalah penyebab paling umum dashboard lambat. Prinsip dasarnya sederhana: minta sesedikit mungkin data dari database.

Buruk:
SELECT * FROM fact_orders
WHERE order_date >= '2024-01-01'
 
Baik:
SELECT region, category, SUM(sales) AS revenue
FROM fact_orders
WHERE order_date >= '2024-01-01'
GROUP BY region, category

Pola query yang wajib diterapkan:

• Pilih kolom yang dibutuhkan saja — jangan SELECT * lalu memotong di dashboard.
• Filter dan agregasi di server, bukan di client — biarkan database yang menghitung.
• Batasi rentang tanggal: dashboard operasional jarang butuh 10 tahun data; taruh filter default yang masuk akal.
• Manfaatkan index dan partisi di sisi warehouse (episode 6): kolom yang sering difilter (tanggal, region) sebaiknya ber-index atau dipartisi per bulan.

#Optimasi Data Model: Star Schema dan Agregasi

Data model menentukan seberapa banyak kerja yang harus dilakukan query di setiap interaksi. Dua perbaikan paling berdampak:

1. Kembali ke star schema (episode 5): pastikan fact tables ramping (hanya foreign key + angka yang diukur) dan dimensi terpisah. Model yang terlalu lebar membuat setiap query membaca kolom yang tidak perlu.
2. Turunkan cardinality: kolom dengan nilai unik terlalu banyak (misal order ID per baris) memperlambat agregasi dan penyimpanan. Ringkas di lapisan semantic jika detailnya tidak dipakai di dashboard.

Khusus untuk Power BI dan Tableau, perhatikan measure yang ditulis tanpa perhitungan yang tepat — misalnya fungsi iterasi per baris (SUMX, RANKX) yang dipakai di tempat SUM/AVERAGE biasa. Ini sumber "bug performa" yang paling sering ditemui:

// Lambat: iterasi baris demi baris
GrossMargin = SUMX('FactOrder', 'FactOrder'[Sales] - 'FactOrder'[Cost])
 
// Efisien: agregasi langsung
GrossMargin = SUM('FactOrder'[Sales]) - SUM('FactOrder'[Cost])

#Incremental Refresh: Hanya Proses Delta

Semakin besar data, refresh penuh (memuat ulang seluruh tabel) semakin tidak masuk akal. Incremental refresh hanya memproses data baru/berubah sejak refresh terakhir — sisanya diambil dari cache.

Tanpa incremental:
- Setiap refresh: muat 5 juta baris fact_orders → 40 menit, 2x sehari
 
Dengan incremental (7 hari terakhir + 2 tahun history):
- Refresh 1: muat history penuh
- Refresh berikutnya: hanya baris baru sejak kemarin → 2 menit

Dampaknya ganda: refresh jauh lebih cepat dan beban database turun drastis. Di Power BI ini dikonfigurasi langsung di model; di database, konsepnya sama dengan tabel partisi per bulan (episode 6) sehingga query harian hanya membaca partisi yang relevan.

#Caching: Menyimpan Hasil yang Sudah Dihitung

Caching menyimpan hasil query sehingga permintaan berikutnya tidak perlu menghitung ulang. Bayangkan dapur restoran: koki menyiapkan hidangan sekali, lalu menyajikan ulang dari lemari penyimpanan — jauh lebih cepat daripada memasak dari nol untuk setiap pelanggan.

Lokasi cache yang umum di arsitektur BI:

Caching bukan sihir gratis: ada tradeoff dengan kesegaran data (staleness). Cache yang terlalu lama membuat angka basi; terlalu pendek membuat beban database naik. Atur TTL (time-to-live) sesuai SLA bisnis — laporan mingguan tidak perlu data 5 menit terakhir.

#Strategi Menyeluruh: Temukan Bottleneck, Bukan Menebak

Optimasi tanpa pengukuran adalah menebak. Alur yang benar:

1. Profil: buka dashboard, ukur waktu tiap visual (developer tools / usage metrics)
2. Identifikasi: visual mana yang paling lambat? query mana yang paling berat?
3. Prioritaskan: perbaiki yang berdampak paling besar untuk pengguna paling banyak
4. Optimasi: query → data model → incremental refresh → caching
5. Ukur ulang: apakah sudah memenuhi performance budget? catat baseline

Monitoring berkelanjutan itu penting: gunakan query log dan usage analytics dari tool BI (Power BI usage metrics, Tableau Performance Recorder) untuk menemukan dashboard yang performanya menurun seiring data bertambah.

#Praktik: Tuning Dashboard

Gunakan dashboard revenue yang kalian bangun di episode 8-9 sebagai bahan latihan:

Praktik:
1. Ukur baseline: berapa lama dashboard memuat? catat angkanya
2. Periksa query terberat: kolom tak terpakai? filter kurang selektif?
3. Perbaiki data model: rapikan star schema, ringkas cardinality
4. Terapkan incremental refresh pada fact_orders
5. Aktifkan caching di tool BI dengan TTL yang masuk akal
6. Ukur ulang: bandingkan dengan baseline — catat perbedaannya

Target latihan: dashboard yang tadinya 15 detik menjadi di bawah 5 detik. Jika sudah tercapai, kalian sudah menguasai skill yang paling dicari tim data.

#Kesalahan Umum Performance Tuning

• Optimasi tanpa pengukuran: "sepertinya lambat di sini" bukan dasar yang baik; selalu ukur dulu.
• SELECT * dan filter terlambat: data besar ditarik ke client hanya untuk dibuang di visual.
• Melebihi jumlah visual: dashboard "kaya" secara visual tapi berat secara query.
• Refresh penuh terus-menerus: buang waktu dan beban database padahal data lama tidak berubah.
• Cache terlalu agresif: angka basi dikira fresh — kepercayaan hilang. Sesuaikan TTL dengan SLA.

#Penutup

Inti yang harus dibawa pulang:

• Tetapkan performance budget dan ukur secara berkala — jangan menebak.
• Optimasi query dan data model adalah sumber perbaikan terbesar; gunakan star schema dan agregasi.
• Incremental refresh memproses hanya delta, bukan seluruh tabel — refresh turun dari jam ke menit.
• Caching mempercepat akses berulang dengan tradeoff kesegaran data yang harus disepakati.
• Praktik: ukur baseline dashboard, perbaiki lapisan demi lapisan, lalu ukur ulang sampai lolos budget.

Di episode 25 selanjutnya kita akan membahas BI strategy & operating model — maturity model, struktur organisasi BI, dan ROI. Performa yang cepat tidak ada artinya tanpa arah strategi yang jelas: dashboard yang cepat untuk keputusan yang salah tetap sia-sia. Pastikan tetap semangat!