Batch vs Streaming untuk Analis: Kapan Real-Time Benar-benar Perlu
TL;DR
Batch memproses data dalam kelompok pada jadwal tertentu (misal tiap jam atau tiap malam), sementara streaming memproses tiap kejadian begitu data masuk. Buat mayoritas laporan bisnis, batch tiap jam udah cukup. Real-time baru layak kalau ada keputusan otomatis yang harus jalan dalam hitungan detik, kayak deteksi fraud atau stok flash sale.
Batch itu proses data yang dikumpulin dulu, baru diolah sekaligus pada jadwal tertentu. Streaming ngolah tiap kejadian begitu datanya masuk, tanpa nunggu.
Bedanya kelihatan sepele di diagram. Tapi di tagihan cloud dan jam kerja tim data, selisihnya gede banget.
Aku sering nemu tim yang minta dashboard real-time, padahal rapatnya cuma seminggu sekali tiap Senin pagi. Data yang update tiap 3 detik nggak ngubah satu pun keputusan di rapat itu.
Apa bedanya batch dan streaming?
Batch ngumpulin data dalam periode tertentu lalu memprosesnya sekaligus, misal tiap 1 jam atau tiap tengah malam. Streaming memproses tiap baris data begitu dia lahir, dengan jeda hitungan detik. Batch dioptimalkan buat volume besar dan biaya murah. Streaming dioptimalkan buat latensi rendah, dan harganya jauh lebih mahal.
Satu hal yang sering ketuker: real-time di percakapan bisnis biasanya artinya "data hari ini", bukan "data 5 detik lalu". Tanya dulu ke yang minta, angka toleransinya berapa menit.
Kapan batch udah cukup?
Batch cukup kalau keputusan yang diambil dari angka itu punya siklus lebih lambat dari jadwal pipeline-nya. Laporan omzet harian, rekap stok mingguan, analisis cohort analysis bulanan, semuanya masuk kategori ini.
Contoh nyata dari toko_berkah, toko sembako yang datanya aku pakai buat latihan. Owner-nya cek dashboard rata-rata 2 kali sehari: jam 9 pagi sebelum buka dan jam 8 malam setelah tutup. Pipeline yang jalan tiap jam udah 12 kali lebih sering dari kebutuhannya.
Query rekapnya sesederhana ini:
SELECT
DATE_TRUNC('hour', waktu_transaksi) AS jam,
COUNT(*) AS jumlah_transaksi,
SUM(total) AS omzet
FROM toko_berkah.transaksi
WHERE waktu_transaksi >= NOW() - INTERVAL '24 hours'
GROUP BY 1
ORDER BY 1;
Hasilnya 24 baris, satu baris per jam. Cukup buat lihat jam ramai dan jam sepi. Nggak butuh streaming buat itu.
Kapan streaming beneran perlu?
Streaming layak kalau ada aksi otomatis yang harus jalan sebelum kejadiannya lewat. Kuncinya bukan seberapa penasaran kamu sama angkanya, tapi apakah ada sistem yang bertindak tanpa manusia.
- Deteksi transaksi mencurigakan di payment gateway, harus diblok sebelum settle.
- Stok flash sale yang dibagi ke 3 marketplace sekaligus, oversell bikin refund massal.
- Alert operasional pabrik, mesin harus berhenti sebelum barang rusak.
- Harga dinamis yang berubah mengikuti permintaan menit itu juga.
Kalau use case kamu nggak ada di daftar semacam ini, kemungkinan besar batch tiap 15 menit udah nutup semua kebutuhan.
Tabel perbandingan batch vs streaming
| Aspek | Batch | Streaming |
|---|---|---|
| Jeda data | 15 menit sampai 24 jam | Di bawah 10 detik |
| Biaya infrastruktur | Rendah, cuma bayar saat job jalan | Tinggi, cluster nyala 24 jam |
| Kesulitan debugging | Gampang, tinggal ulang job-nya | Susah, data lewat sekali |
| Data telat datang | Otomatis ikut kejaring di job berikutnya | Butuh logika windowing sendiri |
| Skill tim yang dibutuhkan | SQL plus orkestrasi dasar | Kafka atau sejenisnya plus engineering |
| Cocok buat | Laporan, dashboard, model bulanan | Alert, blokir otomatis, sinkron stok |
Gimana cara nentuin mana yang dipakai?
Aku pakai 4 pertanyaan ini tiap kali ada permintaan real-time. Jawab urut, berhenti di jawaban pertama yang "nggak".
- Ada keputusan yang berubah kalau datanya lebih baru? Kalau angka jam 8 pagi dan jam 8 lewat 5 bikin orang ambil langkah beda, lanjut. Kalau nggak, batch.
- Keputusannya diambil mesin atau manusia? Manusia butuh waktu baca, rapat, konfirmasi. Jeda 15 menit nggak kerasa. Mesin yang butuh detik.
- Berapa biaya kalau telat 1 jam? Hitung rupiahnya. Kalau oversell flash sale bikin refund Rp 12 juta per kejadian, streaming murah. Kalau cuma bikin rapat mundur 10 menit, batch.
- Tim kamu sanggup jaga pipeline yang nyala 24 jam? Streaming yang mati jam 2 pagi butuh orang yang bangun. Kalau tim cuma 2 orang, ini beban nyata.
Dari 9 permintaan real-time yang pernah aku terima waktu jadi analis, cuma 2 yang lolos sampai pertanyaan keempat. Sisanya selesai pakai batch tiap 15 menit dan nggak ada yang protes.
Contoh kasus: toko_berkah dan permintaan dashboard real-time
Toko_berkah punya 3 cabang di Bekasi dengan total 1.847 transaksi per hari. Owner minta dashboard stok real-time karena takut barang kosong pas ramai.
Aku cek dulu datanya. Dari 3 bulan riwayat, kejadian stok habis di tengah hari cuma 11 kali, semuanya di 6 SKU yang sama. Semua SKU itu punya pola: habis rata-rata 4 jam setelah restock pagi.
Solusinya bukan streaming. Cukup batch tiap 30 menit plus alert sederhana buat 6 SKU itu doang. Biaya tambahan nol, karena pipeline-nya udah ada. Kalau maksa streaming, estimasi biaya cluster paling murah di cloud lokal sekitar Rp 3,5 juta per bulan buat data yang kurang dari 2.000 baris sehari.
Angka 2.000 baris per hari itu penting. Streaming dirancang buat jutaan event per menit. Dipakai buat ribuan baris per hari, kamu bayar mesin balap buat antar galon.
Kesalahan umum saat milih antara batch dan streaming
- Nyamain real-time dengan akurat. Data yang datang cepat tapi belum dibersihin justru bikin keputusan salah. Cek dulu data quality sebelum ngejar kecepatan.
- Lupa ngitung biaya orang. Streaming nambah on-call, monitoring, dan replay logic. Ini biaya bulanan yang nggak muncul di invoice cloud.
- Bikin streaming buat dashboard yang dibuka 2 kali sehari. Ukur dulu berapa kali dashboard dibuka. Angkanya biasanya bikin kaget.
- Nggak nyiapin penanganan data telat. Di streaming, transaksi yang masuk telat 10 menit bisa hilang dari agregasi kalau window-nya nggak diatur.
- Ngukur kecepatan doang, lupa metric bisnisnya. Latensi turun dari 60 menit ke 5 detik itu bagus di slide. Kalau omzet nggak gerak, nggak ada gunanya.
Jalan tengah yang sering dilupain: micro-batch
Micro-batch itu batch yang jalan tiap 1 sampai 15 menit. Dari sisi pengguna rasanya kayak real-time, tapi arsitekturnya masih batch biasa, jadi debugging-nya tetap gampang.
Buat mayoritas UMKM dan tim data kecil di Indonesia, ini titik yang paling masuk akal. Data cukup segar buat operasional harian, biaya masih ketebak, dan tim nggak perlu belajar Kafka dulu.
Kalau kamu pakai warehouse modern, micro-batch bisa dijalanin cuma dengan scheduler bawaan plus query SQL biasa. Detail cara kerja pemrosesan data terjadwal bisa kamu baca di dokumentasi scheduled queries BigQuery.
FAQ
Apa itu batch processing dalam analisis data?
Batch processing itu cara ngolah data dengan cara ngumpulin dulu dalam periode tertentu, baru diproses sekaligus. Misalnya semua transaksi hari ini diproses jam 1 pagi jadi tabel ringkasan. Kelebihannya murah, gampang diulang kalau gagal, dan cocok buat data volume besar yang nggak butuh kecepatan detik.
Apakah streaming selalu lebih baik dari batch?
Nggak. Streaming cuma lebih baik kalau ada keputusan yang harus jalan dalam hitungan detik. Di luar itu, streaming nambah biaya cluster yang nyala 24 jam, nambah kerumitan debugging, dan nambah beban tim. Buat laporan dan dashboard biasa, batch justru lebih aman soalnya gampang diulang saat ada data yang salah.
Berapa jeda data yang wajar buat dashboard bisnis?
Buat dashboard operasional harian, jeda 15 sampai 60 menit biasanya cukup. Buat laporan manajemen mingguan atau bulanan, update sekali sehari udah aman. Patokannya sederhana: jeda datanya harus lebih cepat dari siklus keputusan yang dipakai orang yang buka dashboard itu.
Apa itu micro-batch dan bedanya sama streaming?
Micro-batch itu job batch yang jalan tiap 1 sampai 15 menit, jadi datanya terasa segar tanpa arsitektur streaming. Bedanya, micro-batch tetap memproses kelompok data dan bisa diulang kalau gagal. Streaming memproses tiap event satu per satu dan datanya lewat sekali, jadi butuh mekanisme replay sendiri.
Skill apa yang perlu dipelajari analis buat pipeline data?
Mulai dari SQL yang kuat, terutama agregasi dan window function. Habis itu belajar orkestrasi jadwal, misalnya scheduled query atau Airflow dasar. Streaming baru relevan kalau kamu udah kerja di tim yang punya kasus latensi detik. Urutan ini nghemat berbulan-bulan belajar yang belum kepakai.
Ringkasnya
Batch murah, gampang diperbaiki, dan cukup buat hampir semua laporan bisnis. Streaming mahal dan cuma sepadan kalau ada mesin yang harus bertindak dalam hitungan detik.
Sebelum bikin arsitektur baru, jawab dulu 4 pertanyaan di atas dan hitung rupiah kerugian kalau data telat 1 jam.
Mau latihan bikin query agregasi per jam yang jadi dasar pipeline batch? Kulik langsung di artikel semantic layer buat lihat gimana definisi metrik dirapikan sebelum masuk dashboard.
Mau praktek langsung? Mulai latihan SQL gratis
Latihan interaktif, langsung di browser.
Artikel terkait
7 Antipattern SQL yang Bikin Query Lambat
Tujuh pola SQL yang diam-diam bikin query lambat, dari SELECT bintang, fungsi di kolom filter, sampai OFFSET besar. Plus cara benerin tiap satunya.
CTE vs Subquery vs Temp Table: Mana Lebih Cepat
CTE, subquery, dan temp table sama-sama bikin hasil sementara, tapi performanya beda. Ini panduan milih yang mana buat query kamu.
Partisi Tabel di SQL untuk Data Besar
Partisi tabel memecah satu tabel besar jadi potongan kecil biar query cuma baca bagian yang relevan. Ini cara bikin dan kapan kamu butuh.