Batch vs streaming

Memetakan spektrum latensi antara batch dan streaming beserta pertimbangan jujur memilih batch sebagai default.

Daftar isi

Topik ini memetakan spektrum latensi pemrosesan data dari batch harian, mikro-batch, sampai streaming berorde detik, kemudian menimbang kapan masing-masing titik pada spektrum itu benar-benar dibutuhkan. Pembahasan berujung pada pertimbangan yang jujur, yaitu batch sebagai pilihan default dan streaming sebagai pengecualian yang harus dibenarkan. Satu contoh pemrosesan batch dijalankan dengan Python agar sifat dasarnya terlihat langsung pada kode yang sederhana.

Spektrum latensi, bukan pilihan biner#

Perbedaan batch dan streaming pada dasarnya adalah perbedaan titik pada spektrum latensi, yakni jeda antara kejadian terjadi dan data itu siap dipakai. Batch memproses himpunan data yang sudah terkumpul pada jadwal tertentu, streaming memproses setiap kejadian begitu kejadian itu tiba, sedangkan mikro-batch (micro-batch) menjadi titik tengah yang memproses kelompok kecil kejadian pada interval pendek. Ketiganya dapat menjalankan logika transformasi yang serupa, sehingga yang dipilih adalah tingkat kesegaran data yang dibutuhkan konsumen, bukan jenis pekerjaannya.

PolaPemicu pemrosesanLatensi tipikalCiri operasional
Batch harianjadwal tetap, misalnya sekali sehariorde jamsatu pekerjaan besar yang mudah diulang
Mikro-batchinterval pendek, misalnya tiap beberapa menitorde menitpekerjaan kecil berulang, kompromi latensi dan biaya
Streamingsetiap kejadian tibaorde detiklayanan yang berjalan terus, paling mahal dioperasikan

Diagram berikut menempatkan ketiganya pada satu garis spektrum dari latensi terbesar ke terkecil.

Spektrum latensi dari batch harian hingga streamingBatchorde jamMikro-batchorde menitStreamingorde detiklatensi besarlatensi kecilkejadian diproses mengikuti jadwal yang makin rapat
Spektrum latensi dari batch harian hingga streaming

Setiap titik pada spektrum juga punya wajah teknologi yang dikenal. Pekerjaan batch dijadwalkan dengan orkestrator seperti Airflow, pemrosesan mikro-batch dipraktikkan oleh mesin seperti Spark Structured Streaming, sedangkan penyaluran kejadian untuk streaming bertumpu pada broker pesan seperti Kafka. Angka latensi pada tabel sengaja dinyatakan sebagai orde, bukan janji produk, karena latensi sesungguhnya ditentukan desain pipeline, bukan nama alatnya.

Mengapa batch menjadi default yang jujur#

Batch menjadi pilihan default karena pekerjaan sekali jalan adalah bentuk pemrosesan yang paling sederhana untuk dioperasikan. Kegagalan pekerjaan batch ditangani dengan menjalankan ulang pekerjaan yang sama, dan pekerjaan yang idempoten, yakni aman dijalankan berulang dengan hasil akhir yang sama, membuat pengulangan itu tidak menambah dan tidak mengurangi data. Data masukannya berhenti pada batas jendela yang tetap, sehingga keluarannya dapat ditebak, dibandingkan, dan diuji seperti keluaran fungsi biasa.

Keunggulan itu berlanjut ke sisi biaya dan pemulihan. Komputasi batch hanya hidup selama pekerjaan berjalan, sehingga biayanya mudah dikendalikan, dan pengisian ulang data lama (backfill) cukup dilakukan dengan menjalankan pekerjaan yang sama pada jendela lama. Semua kemudahan itu patah satu per satu ketika berpindah ke streaming, karena layanannya berjalan terus, kejadian bisa datang terlambat atau tidak berurutan, dan pencatatan kemajuan pemrosesan (checkpoint) menjadi bagian dari kebenaran hasilnya.

Streaming tetap dibenarkan untuk kasus yang benar-benar membutuhkannya, yaitu ketika nilai keputusannya menyusut cepat terhadap waktu. Peringatan anomali suhu server, pemantauan yang harus menyala dalam hitungan detik, dan penyaringan data masuk secara langsung termasuk kebutuhan semacam itu. Di luar kelompok tersebut, laporan harian atau per beberapa menit sudah menjawab kebutuhan konsumen data tanpa biaya operasional yang berlipat.

Batch sederhana dalam Python#

Pemrosesan batch pada intinya memproses seluruh himpunan data yang sudah tersedia dalam satu putaran, dan perilaku itu terlihat paling jelas pada skrip kecil berikut. Daftar kejadian pada skripnya menggambarkan hasil ekstraksi semalam yang sudah lengkap tersedia, sebagaimana masukan pekerjaan batch sungguhan.

python batch-harian.py
"""Rekap harian bergaya batch: seluruh kejadian diproses dalam satu putaran."""

kejadian = [
    ("2026-01-12T08:02:00", "login"),
    ("2026-01-12T08:05:00", "catatan_dibuat"),
    ("2026-01-12T09:14:00", "login"),
    ("2026-01-12T10:01:00", "catatan_dibuat"),
    ("2026-01-12T16:40:00", "logout"),
    ("2026-01-13T08:10:00", "login"),
    ("2026-01-13T09:00:00", "catatan_dibuat"),
    ("2026-01-13T09:30:00", "catatan_diedit"),
]

rekap: dict[str, int] = {}
for waktu, _ in kejadian:
    hari = waktu[:10]
    rekap[hari] = rekap.get(hari, 0) + 1

print("Jumlah kejadian per hari:")
for hari in sorted(rekap):
    print(f"  {hari} : {rekap[hari]} kejadian")
text Keluaran
Jumlah kejadian per hari:
  2026-01-12 : 5 kejadian
  2026-01-13 : 3 kejadian

Keluarannya selalu sama selama masukannya sama, dan sifat itulah yang membuat pekerjaan batch mudah diuji serta mudah dipulihkan. Angka pada rekapnya juga dapat dihitung ulang dengan tangan, sehingga skrip sejenis mudah diperiksa silang sebelum dipindahkan ke penjadwal sungguhan. Bandingkan dengan versi streaming dari tugas yang sama, yang harus menentukan kapan sebuah jendela hari dianggap selesai, bagaimana memperlakukan kejadian yang tiba setelah jendelanya ditutup, dan di mana kemajuan pemrosesannya disimpan. Skrip sepuluh baris di atas tidak perlu mengambil satu pun dari keputusan itu karena seluruh datanya sudah tersedia sejak awal.

Kesalahan umum#

  1. Memilih streaming karena terlihat modern. Penyebabnya, kompleksitas operasional streaming tidak terlihat pada awal proyek dan baru terasa saat kejadian terlambat mulai menumpuk. Perbaikannya, tuliskan lebih dahulu keputusan yang menunggu detik itu juga, lalu pilih titik latensi dari kebutuhan tersebut.
  2. Menganggap batch tidak dapat diperbarui lebih sering. Penyebabnya, kata harian pada pekerjaan batch sering dibaca sebagai batas yang baku. Perbaikannya, rapatkan jadwal atau gunakan mikro-batch sebelum mempertimbangkan streaming.
  3. Mengabaikan kejadian terlambat pada kedua pola. Penyebabnya, jendela pekerjaan dianggap menutup data secara mutlak, padahal data sumber bisa tiba setelah jendelanya lewat. Perbaikannya, sediakan jeda pembilasan sebelum jendela dianggap selesai dan sediakan proses pembaruan untuk jendela yang sudah ditutup.

Ringkasan#

  • Batch, mikro-batch, dan streaming adalah titik-titik pada satu spektrum latensi, bukan tiga jenis pekerjaan yang terpisah.
  • Batch menjadi default karena paling sederhana dioperasikan, diuji, dipulihkan, dan dibayar.
  • Streaming dibenarkan hanya ketika nilai keputusannya menyusut cepat terhadap waktu, sedangkan mikro-batch menjadi jalan tengah yang layak dicoba lebih dahulu.

Referensi#