Batch vs Streaming untuk Analis: Kapan Real-Time Benar-benar Perlu
Blog/Tutorial SQL/Batch vs Streaming untuk Analis: Kapan Real-Time Benar-benar Perlu

Batch vs Streaming untuk Analis: Kapan Real-Time Benar-benar Perlu

BimaBima
·14 November 2025·8 menit baca

Penulis

Bima

Bima

Founder & Data Professional

Bagikan

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

AspekBatchStreaming
Jeda data15 menit sampai 24 jamDi bawah 10 detik
Biaya infrastrukturRendah, cuma bayar saat job jalanTinggi, cluster nyala 24 jam
Kesulitan debuggingGampang, tinggal ulang job-nyaSusah, data lewat sekali
Data telat datangOtomatis ikut kejaring di job berikutnyaButuh logika windowing sendiri
Skill tim yang dibutuhkanSQL plus orkestrasi dasarKafka atau sejenisnya plus engineering
Cocok buatLaporan, dashboard, model bulananAlert, 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".

  1. 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.
  2. Keputusannya diambil mesin atau manusia? Manusia butuh waktu baca, rapat, konfirmasi. Jeda 15 menit nggak kerasa. Mesin yang butuh detik.
  3. 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.
  4. 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.

Coba Langsung

Mau praktek langsung? Mulai latihan SQL gratis

Latihan interaktif, langsung di browser.

Buka NgulikSQL →
Bagikan:
Bima
Ditulis oleh

Bima

Founder & Data Professional

Founder Ngulik Data. Passionate about making data analysis accessible for everyone.

Artikel terkait

Cara Membuat Pivot Dinamis di SQL (Panduan 2026)
Tutorial SQL
19 Juli 2026•10 menit baca

Cara Membuat Pivot Dinamis di SQL (Panduan 2026)

Pivot dinamis di SQL ngubah baris jadi kolom tanpa kamu hardcode nama kolomnya. Ini cara bikinnya pakai CASE WHEN dan versi yang kolomnya ngikut data.

BimaBima
Menghitung YTD, QTD, dan MTD di SQL (Panduan 2026)
Tutorial SQL
17 Juli 2026•9 menit baca

Menghitung YTD, QTD, dan MTD di SQL (Panduan 2026)

YTD, QTD, dan MTD ngukur total dari awal tahun, kuartal, atau bulan sampai hari ini. Ini cara ngitungnya di SQL pakai DATE_TRUNC, plus satu query gabungan.

BimaBima
Gap and Island Analysis di SQL
Tutorial SQL
15 Juli 2026•10 menit baca

Gap and Island Analysis di SQL

Gap and island analysis di SQL nyari deret data yang berturut-turut (island) dan celah yang bolong (gap). Cocok buat hitung streak login atau cari tanggal transaksi yang hilang.

BimaBima
Kembali ke Blog
Ngulik Data logoNgulik Data

Platform edukasi data lengkap untuk professionals Indonesia. Belajar SQL, Data Analysis, dan lebih banyak lagi dengan praktek langsung dan feedback real-time.

© 2026 Ngulik Data. Semua hak dilindungi.

TAUTAN
BantuanHargaDatasetBlogAfiliasi
LEGAL
Syarat & KetentuanKebijakan Privasi
Ngulik Data
DatasetLeaderboardBlogStore