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.
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.
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.
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.
Kalau use case kamu nggak ada di daftar semacam ini, kemungkinan besar batch tiap 15 menit udah nutup semua kebutuhan.
| 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 |
Aku pakai 4 pertanyaan ini tiap kali ada permintaan real-time. Jawab urut, berhenti di jawaban pertama yang "nggak".
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.
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.
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.
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.
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.
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.
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.
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.
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.
Kolom waktu isinya angka gede kayak 1704067200 dan bikin bingung? Itu Unix timestamp. Ini cara ngubahnya jadi tanggal beneran di SQL, plus balik lagi.
Data transaksi tersimpan UTC, tapi laporan harus jam WIB. Kalau salah konversi, angka penjualan tengah malam bisa kecatat di tanggal yang salah. Ini cara handle timezone di SQL dengan benar.
Nambah 30 hari ke tanggal invoice, ngurangin sebulan buat cari periode lalu, ngitung selisih hari antar order. Semua itu aritmetika tanggal, dan SQL punya operator INTERVAL buat ngerjainnya.