Belajar BI Analyst - Real-Time BI & Streaming

#Pendahuluan

Semua dashboard yang kalian bangun sejauh ini adalah batch: data di-refresh harian atau per jam. Episode ini membuka mode baru: real-time BI — dashboard yang memperbarui diri dalam hitungan detik saat data baru masuk. Di era 2026 dengan operasi yang bergerak cepat, ini semakin menjadi ekspektasi.

Namun real-time bukanlah "lebih baik secara otomatis". Episode ini akan membahas kapan real-time benar-benar layak, bagaimana arsitekturnya bekerja, dan berapa biaya yang harus dibayar. Sebagai BI Analyst, kalian harus bisa menjelaskan trade-off ini kepada stakeholder — bukan sekadar ikut tren.

#Batch vs Real-Time: Kapan Memilih Apa

Pertanyaan pertama yang harus dijawab: apakah keputusan butuh data terbaru dalam hitungan detik?

Aturan emasnya: pakai batch untuk keputusan strategis, real-time untuk keputusan operasional. Revenue bulanan tidak perlu real-time; tetapi dashboard stok gudang di puncak promo sangat layak. Menghitung kapan real-time layak: kalau keputusan berubah dalam hitungan menit, real-time masuk akal; kalau tidak, batch cukup.

#Arsitektur Real-Time BI

Real-time BI mengikuti alur yang mirip batch, tetapi dengan perbedaan kunci di lapisan ingest:

Lapisan-lapisannya:

1. Sumber event: aplikasi menghasilkan event — transaksi, klik, sensor IoT — sering dikirim sebagai message.
2. Message broker: menampung dan mendistribusikan event secara real-time. Yang paling populer: Apache Kafka, plus alternatif seperti Redpanda dan NATS.
3. Stream processing: memproses event berjalan — agregasi per menit, alerting. Contoh: Flink, Kafka Streams, atau pola dbt incremental untuk mikro-batch.
4. Real-time store: penyimpanan yang bisa menulis dan membaca cepat — contoh: ClickHouse, Pinot, Doris, atau warehouse dengan dukungan streaming.
5. Dashboard live: tool BI yang mendukung refresh otomatis atau query push — Power BI dengan streaming dataset, Tableau dengan data source real-time.

Sebagai BI Analyst, kalian tidak perlu membangun Kafka sendiri — tetapi wajib memahami alurnya agar bisa berkolaborasi dengan Data Engineer dan mendesain KPI yang tepat.

#CDC: Sinkronisasi Perubahan Data

CDC (Change Data Capture) adalah teknik penting di real-time BI: menangkap perubahan di database operasional (insert/update/delete) dan mengalirkannya ke downstream secara real-time. Alih-alih menyalin seluruh tabel tiap malam, CDC hanya mengirim perubahannya.

Contoh tool CDC: Debezium (membaca binlog/transaction log) dan Debezium Server untuk sinkronisasi ringan. Alur khasnya:

PostgreSQL (produksi)
  → Debezium membaca walog/binlog
    → Kafka (topic per tabel)
      → stream processing / sink
        → real-time store → dashboard live

Bagi kalian, CDC berarti: data yang tadinya "baru besok pagi" kini bisa "baru sekarang" — selama biaya infra dan kompleksitasnya memang terbayar.

#KPI Live yang Bermakna

Real-time hanya berguna jika KPI-nya dirancang untuk itu. Contoh KPI yang layak live:

Perhatikan pola: semua KPI di atas memancing aksi seketika. KPI strategis seperti "margin kuartal" tidak masuk daftar ini — dan tidak seharusnya masuk.

#Praktik: Live Dashboard Sederhana

Untuk memahami prinsipnya tanpa infrastruktur berat, simulasi alur dengan query mikro-batch yang di-refresh cepat. Buat dashboard "Live Operations" dari tabel orders:

SELECT
    DATE_TRUNC('hour', order_date) AS hour,
    COUNT(DISTINCT order_id)        AS orders,
    SUM(sales)                      AS revenue
FROM fact_orders
WHERE order_date >= CURRENT_DATE
GROUP BY 1
ORDER BY 1 DESC;

Di tool kalian:

1. Power BI: aktifkan auto-refresh data source (contoh: setiap 1-5 menit) atau buat streaming dataset. Set visual ke mode auto-refresh.
2. Tableau: set data source ke Live Connection dan aktifkan Auto refresh pada worksheet.
3. Looker: dashboard dengan refresh_interval di file model:

explore: fact_orders {
    ...
}
datagroup: orders_default {
    sql_trigger: SELECT MAX(order_date) FROM fact_orders ;;
    max_cache_age: "5 minutes"
}

max_cache_age menentukan berapa lama Looker boleh menyajikan data lama sebelum query ulang — cara Looker mendukung dashboard semi-real-time.

Batas kewajaran untuk praktik: menit-an. Selama praktik, jangan berpura-pura menjadi sistem menit-detik yang butuh Kafka; pahami dulu pola dan trade-off-nya. Kalau nanti perusahaan benar-benar butuh detik-an, kalian sudah punya peta arsitekturnya untuk kolaborasi dengan Data Engineer.

#Kesalahan Umum Real-Time BI

• Real-time untuk hal yang tidak perlu: biaya infra naik, keputusan tidak berubah lebih baik.
• KPI "live" yang tidak memicu aksi: dashboard update tiap detik tapi tidak ada yang perlu dilakukan = pemborosan.
• Mengabaikan latensi pipeline: "real-time" yang kenyataannya tertunda 5 menit karena pipeline tidak dioptimalkan.
• Query besar ke OLTP setiap detik: menjatuhkan aplikasi produksi — pakai broker + store khusus streaming.
• Tanpa alerting: dashboard live yang tidak dilihat siapa pun sama saja dengan dashboard biasa.

#Penutup

Inti yang harus dibawa pulang:

• Batch untuk keputusan strategis, real-time untuk keputusan operasional.
• Arsitektur real-time: event source → broker (Kafka) → stream processing → real-time store → dashboard live.
• CDC (Debezium) mengalirkan perubahan database operasional secara real-time.
• KPI live harus memicu aksi seketika — bukan sekadar angka yang berkedip.
• Praktik: dashboard live Superstore dengan auto-refresh menit-an, plus pemahaman kapan butuh arsitektur streaming penuh.

Di episode 17 selanjutnya kita akan membahas enterprise BI & stakeholder management — bagaimana scaling BI di perusahaan besar, mengelola stakeholder, dan governance report. Dari operasi harian, kita naik ke level organisasi. Pastikan tetap semangat!