Wawancara Data Engineering: Kapan Anda Harus Menggunakan Batch, Micro-Batch, atau Stream Processing?

Masalah dan Ruang Lingkup

Sebuah platform e-commerce menulis event pesanan ke log yang tahan lama dan dapat diputar ulang (replayable) serta mempertahankan data mentah yang tidak dapat diubah (immutable). Laju stabil tidak ditentukan; puncaknya adalah 20.000 event per detik, dengan lonjakan promosi singkat hingga sepuluh kali lipat dari laju tersebut. Anomali inventaris membutuhkan peringatan dalam waktu 10 detik sejak pembuatan event. Dasbor operasional harus diperbarui dalam waktu 5 menit. Bagian keuangan menutup pembukuan keesokan harinya dan membutuhkan hari bisnis yang sama agar dapat dijalankan ulang dan direkonsiliasi. Sekitar 2% event terlambat, hingga 6 jam.

Laju-laju tersebut, pengganda lonjakan, persentase keterlambatan, dan tenggat waktu adalah asumsi masalah, bukan klaim performa tentang suatu mesin. Asumsikan setiap event memiliki event_id, order_id, event_time, dan versi skema yang stabil. Keuangan menggunakan hari bisnis dalam zona waktu yang eksplisit. Tim data yang beranggotakan empat orang telah mengoperasikan warehouse dan scheduler dengan andal, tetapi belum memiliki operasional on-call yang matang untuk pekerjaan streaming stateful.

Masalah ini tidak memerlukan satu mode pemrosesan untuk ketiga konsumen. Tujuannya adalah menurunkan desain minimum yang memadai dari tenggat waktu tindakan, kelengkapan hasil, pemulihan, dan biaya pemeliharaan. Ini termasuk dalam data karena intinya adalah semantik pemrosesan, kesegaran (freshness), dan kompromi kualitas data, bukan arsitektur platform lintas-domain.

Apa yang Dinilai Pewawancara

Sinyal pertama adalah apakah kandidat bekerja mundur dari tindakan bisnis berguna yang terakhir, alih-alih langsung memilih streaming secara default setelah melihat antrean pesan. Sumber tanpa batas (unbounded source) hanya menyatakan bahwa data terus berdatangan. Hal ini tidak mengharuskan setiap hasil hilir memproses satu rekaman pada satu waktu. Keuangan hari berikutnya dapat membaca snapshot terbatas dari log yang sama dan memperoleh reproduktibilitas yang lebih mudah dari pemrosesan batch.

Sinyal kedua adalah memisahkan latensi pemrosesan dari latensi tindakan. Sebuah mesin mungkin dapat menghitung dalam 500 milidetik, tetapi sink yang menyegarkan setiap 5 menit menghalangi terwujudnya dasbor tingkat detik. Jawaban yang kuat menganggarkan penyerapan (ingestion), antrean, komputasi, penulisan, penyegaran cache, dan pengiriman peringatan secara terpisah, lalu mengukur setiap segmen.

Sinyal ketiga adalah batasan kebenaran yang presisi. Pemrosesan exactly-once dalam mesin streaming tidak membuktikan bahwa data yang terlambat sudah lengkap, dan tidak secara otomatis melindungi efek samping eksternal (external side effects). Pekerjaan batch yang dapat dijalankan ulang juga tidak otomatis aman. Tanpa rentang input yang terdefinisi, kunci bisnis, versi snapshot, dan publikasi atomik, eksekusi ulang dapat menduplikasi atau mencampurkan definisi.

Terakhir, pewawancara menguji penilaian operasional. Streaming berkelanjutan membutuhkan kapasitas berkelanjutan, pemulihan backlog, state, checkpoint, penerapan yang aman, dan kepemilikan on-call. Jika micro-batch dapat memenuhi tenggat waktu 5 menit dengan andal, state tingkat rekaman menambah mode kegagalan tanpa mengubah keputusan. Sebaliknya, pemrosesan batch per jam menghancurkan nilai peringatan 10 detik yang sebenarnya memicu pengisian ulang stok atau penghentian penjualan.

Pertanyaan untuk Diklarifikasi Sebelum Menjawab

• Di mana tenggat waktu dimulai dan berakhir? Di sini tenggat dimulai saat sistem sumber melakukan commit terhadap event dan berakhir saat peringatan tiba atau hasil kueri terlihat. Janji yang berakhir pada penyerapan warehouse mengabaikan penundaan sink dan cache.
• Apakah peringatan 10 detik memicu tindakan otomatis? Perubahan inventaris otomatis, penghentian penjualan, atau notifikasi memerlukan deduplikasi, idempotensi, dan audit. Peringatan observasional dapat mentoleransi lebih banyak positif palsu atau duplikat.
• Apakah dasbor 5 menit berupa perkiraan atau angka lengkap? Micro-batch sudah cukup untuk perkiraan yang dapat direvisi dengan waktu "per tanggal/jam" (as of). Jika setiap tampilan harus menyertakan ekor data terlambat 6 jam, persyaratan kesegaran 5 menit dan kelengkapan akan berbenturan dan kontrak produk harus diubah.
• Kapan keuangan membekukan penutupan buku, dan dapatkah mereka menyesuaikannya nanti? Menghasilkan draf hari berikutnya yang diikuti oleh entri penyesuaian berbeda dengan menunggu enam jam sebelum pembekuan. Jawabannya menentukan batas waktu (cutoff) batch dan protokol revisi.
• Bisakah ketiga penggunaan tersebut berbagi lapisan mentah dan definisi transformasi? Mereka dapat berbagi event ternormalisasi, kunci bisnis, dan perlengkapan uji (test fixtures). Menyalin filter, zona waktu, dan aturan jumlah secara independen pada akhirnya akan menciptakan pergeseran (drift) antara batch dan stream.
• Bisakah tim mengoperasikan stream stateful sepanjang waktu? Tanpa peringatan backlog, latihan pemulihan checkpoint, dan deployment yang aman, continuous streaming harus dibatasi pada jalur terkecil yang benar-benar membutuhkan tindakan tingkat detik.

Jawaban 30 Detik

“Saya akan membagi konsumen berdasarkan tenggat waktu tindakan bisnis alih-alih menerapkan satu mode pada sumber data. Jalur anomali inventaris 10 detik menggunakan continuous streaming. Dasbor operasional 5 menit menggunakan micro-batch satu atau dua menit, menyisakan anggaran untuk penulisan dan penyegaran cache. Keuangan hari berikutnya menggunakan snapshot hari bisnis dalam batch dan tetap menjadi sumber rekonsiliasi. Ketiganya berbagi event mentah yang immutable, aturan normalisasi, dan kunci bisnis.

Hasil streaming adalah tampilan yang dapat direvisi, bukan klaim bahwa data terlambat sudah lengkap. Tindakan eksternal bersifat idempoten berdasarkan versi event dan aturan. Sebelum cutover, saya memutar ulang riwayat yang sama melalui jalur batch, micro-batch, dan stream, membandingkan jumlah hitungan, nilai moneter, dan latensi ekor (tail latency) secara bayangan (shadow), serta mengaktifkan tindakan hanya untuk jalur tingkat detik. Aturannya adalah memilih mode paling sederhana yang memenuhi SLO tindakan dan yang pemulihannya konvergen.”

Pembahasan Mendalam Langkah demi Langkah

Langkah 1: Tulis tiga kontrak hasil

Tentukan kunci, tenggat waktu, kelengkapan, dan perilaku revisi dari setiap output sebelum memilih Spark, Flink, atau produk lainnya.

Satu event dapat melayani tiga kontrak yang berbeda. Antrean pesan adalah transportasi input dan tidak dapat memaksa ketiga baris tersebut ke dalam mode eksekusi yang sama.

Langkah 2: Alokasikan anggaran tindakan menyeluruh (end-to-end)

Anggaran awal yang dapat diuji untuk peringatan 10 detik mungkin menetapkan masing-masing 2 detik untuk commit sumber dan transportasi, antrean, komputasi, tindakan sink dan aturan, serta pengiriman peringatan. Uji beban harus menggantikan alokasi sementara tersebut, tetapi totalnya tidak boleh melebihi tenggat waktu bisnis. Catat p95, p99, dan usia backlog maksimum untuk setiap segmen. Waktu operator saja menyembunyikan sink yang lambat.

Dasbor 5 menit dapat memulai micro-batch setiap 1 atau 2 menit. Dengan irisan 2 menit, waktu tunggu jadwal paling buruk sekitar 2 menit, komputasi dan penulisan masing-masing menerima 1 menit, dan penyegaran cache menerima menit terakhir. Jika lonjakan sepuluh kali lipat mendorong komputasi melampaui anggaran, pertama-tama tingkatkan paralelisme, persingkat irisan, atau tunda dimensi bernilai rendah. Waktu eksekusi rata-rata tidak membuktikan SLO ekor.

Keuangan dibatasi oleh reproduktibilitas dan definisi yang dibekukan, bukan latensi minimum. Batch membaca snapshot eksplisit atau rentang offset, menulis hasil ke area staging yang diberi label run_id, memvalidasinya, dan mempublikasikannya secara atomik. Mengulang input dan versi aturan yang sama harus menghasilkan hasil yang sama.

Langkah 3: Berbagi fakta tanpa menciptakan utang implementasi ganda

Event mentah pertama kali masuk ke log yang dapat diputar ulang atau object store dengan muatan asli, versi skema, waktu penyerapan, dan posisi sumber. Lapisan normalisasi menangani evolusi skema, zona waktu, unit jumlah, status pembatalan, dan kunci bisnis secara konsisten. Setiap mode eksekusi membaca setelah batasan tersebut.

Fakta bersama tidak memerlukan pembagian kode baris demi baris di antara ketiga mesin. Batasan yang lebih berguna adalah kontrak data bersama, golden fixture, dan aturan deterministik. Jika batch dan stream harus mengimplementasikan logika jendela secara terpisah, jalankan pengujian kesetaraan pada fixture yang sama. Keuangan dapat mempertahankan pemeriksaan independen yang lebih kuat; penggunaan kembali kode tidak boleh menghilangkan kontrol.

Langkah 4: Rancang duplikat, data terlambat, dan efek samping secara terpisah

Stream inventaris melakukan deduplikasi berdasarkan event_id, menghitung jendela event-time pendek, dan memancarkan versi aturan dan hasil. Penghentian penjualan, pengisian ulang, atau notifikasi menggunakan kunci idempotensi tindakan yang stabil. Checkpoint yang berhasil tidak membuktikan bahwa panggilan HTTP eksternal terjadi sekali, sehingga percobaan ulang (retries) harus mengenali tindakan yang telah dilakukan.

Micro-batch operasi membaca rentang offset sumber setengah terbuka (half-open) yang tetap dan menggantikan jendela target berversi alih-alih menambahkan total lainnya. Event yang terlambat masuk ke batch berikutnya dan menaikkan versi hasil. Dasbor menunjukkan waktu "as of", memperjelas bahwa kesegaran 5 menit tidak berarti ekor data 6 jam telah lengkap.

Batch keuangan membaca input yang dibekukan setelah batas waktu yang disepakati. Event yang lebih baru masuk ke eksekusi penyesuaian yang mempertahankan eksekusi asli, rentang input, versi aturan, dan persetujuan diskrepansi. Pemrosesan stream exactly-once dapat mencegah duplikasi hasil pemrosesan yang dipersistensikan dalam beberapa batasan, tetapi itu tidak membuktikan kelengkapan di hadapan data yang terlambat atau meluas secara otomatis ke efek samping eksternal.

Langkah 5: Buat kapasitas dan biaya dapat direproduksi

Puncak yang dinyatakan adalah 20.000 event per detik, sehingga lonjakan sepuluh kali lipat adalah 200.000 per detik. Jika sebuah event ternormalisasi diilustrasikan sebesar 1 KiB, penyerapan puncak adalah sekitar 195 MiB per detik. Ini hanyalah estimasi kapasitas; penentuan ukuran produksi harus menghitungnya kembali dari distribusi ukuran terkompresi dan tidak terkompresi.

Continuous streaming membutuhkan kapasitas berkelanjutan untuk lalu lintas puncak dan pemulihan backlog. Kegagalan selama sepuluh menit pada 20.000 event per detik menciptakan 12 juta event yang mengantre. Jika kapasitas yang dipulihkan hanya setara dengan input saat ini, backlog tidak akan pernah bersih. Micro-batch harus menyelesaikan satu irisan sebelum irisan berikutnya tiba. Batch dapat memusatkan sumber daya pada periode yang lebih murah, tetapi batch yang sangat kecil dan sering membuat overhead startup, commit, dan file kecil menjadi dominan.

Perbandingan ini mencakup komputasi berkelanjutan, penyimpanan state dan checkpoint, penulisan sink, pemindaian, pekerjaan on-call, dan kompleksitas deployment. Biaya cloud saja mengabaikan biaya tim beranggotakan empat orang yang memelihara tiga implementasi serupa. Desain yang disarankan membatasi continuous streaming hanya untuk peringatan inventaris, menghindari state sepanjang waktu untuk keuangan dan dasbor.

Langkah 6: Migrasi dengan pemutaran ulang bayangan (shadow replay) alih-alih satu kali cutover langsung

Bekukan segmen riwayat yang mencakup lalu lintas normal, lonjakan sepuluh kali lipat, duplikat, ketidakteraturan urutan, dan ekor keterlambatan 6 jam. Gunakan hasil batch lama sebagai baseline sementara pekerjaan micro-batch dan stream baru berjalan dalam mode bayangan tanpa memicu tindakan inventaris. Bandingkan hitungan, jumlah nilai, versi, dan riwayat revisi keterlambatan untuk setiap kunci bisnis, dan jelaskan setiap diskrepansi.

Tingkatkan eksposur secara bertahap: tulis hanya ke tabel bayangan, buka dasbor internal, lalu izinkan peringatan stream memicu tindakan yang dapat dibatalkan (reversible). Injeksi kegagalan (fault injection) mencakup crash sebelum dan sesudah checkpoint, timeout sink, partisi yang macet, perubahan skema, dan pengejaran backlog. Metrik penerimaan mencakup p99 end-to-end, usia backlog maksimum, waktu penyelesaian micro-batch, tingkat revisi keterlambatan, jumlah tindakan duplikat, perbedaan jumlah batch-stream, dan waktu pemulihan.

Tentukan juga kriteria keluar. Jika micro-batch berulang kali melewati 5 menit, periksa penjadwalan, skew, sink, dan kapasitas lonjakan sebelum mempertimbangkan continuous streaming. Jika peringatan 10 detik tidak lagi mendorong tindakan, turunkan versinya ke micro-batch untuk mengurangi biaya on-call. Mode pemrosesan adalah pilihan bisnis yang dapat diverifikasi, bukan identitas permanen.

Contoh Jawaban yang Kuat

“Saya memisahkan input tanpa batas dari mode pemrosesannya. Para konsumen ini memiliki tenggat waktu tindakan yang berbeda, jadi saya tidak akan memaksakan semuanya ke dalam streaming demi keseragaman teknis. Anomali inventaris benar-benar harus bertindak dalam 10 detik, jadi saya menggunakan continuous stream, mengalokasikan anggaran di seluruh sumber, antrean, komputasi, penulisan, dan pengiriman, serta membuat setiap tindakan idempoten berdasarkan event_id dan versi aturan. Dasbor operasional hanya membutuhkan 5 menit, jadi saya mulai dengan micro-batch satu atau dua menit yang menggantikan hasil berdasarkan jendela dan versi serta mengekspos waktu as-of. Penutupan keuangan membaca snapshot hari bisnis yang dibekukan dalam batch, menempatkannya di staging berdasarkan run_id, memvalidasi, lalu mempublikasikannya secara atomik; data yang terlambat masuk ke eksekusi penyesuaian.

Ketiga jalur tersebut berbagi event mentah yang dapat diputar ulang, kontrak ternormalisasi, dan golden fixture, sementara keuangan mempertahankan kontrol independen. Pada 20.000 event per detik dengan lonjakan singkat sepuluh kali lipat, saya menguji penyerapan 200.000 per detik dan rasio pengejaran (catch-up) setelah kegagalan, bukan hanya kondisi stabil. Checkpoint stream tidak menggantikan idempotensi tindakan eksternal, dan pemrosesan exactly-once tidak membuktikan bahwa ekor keterlambatan 6 jam sudah lengkap.

Untuk migrasi, saya memutar ulang riwayat yang sama dan membandingkan hasil tingkat kunci dan revisi dari jalur batch, micro-batch, dan stream dalam tabel bayangan. Continuous streaming dimulai dengan peringatan observasional. Ini memicu tindakan otomatis hanya setelah p99 berada di bawah 10 detik, tindakan duplikat nol, dan backlog dibersihkan dalam targetnya. Aturan keputusan saya adalah memilih mode paling sederhana yang memenuhi tenggat waktu tindakan, kelengkapan, dan kontrak pemulihan. Latensi yang lebih rendah layak dibayar dengan biaya state dan on-call hanya jika hal itu mengubah keputusan bisnis.”

Kesalahan Umum

• Memindahkan semuanya ke streaming karena ada Kafka → input berkelanjutan tidak membuat setiap hasil harus diproses rekaman demi rekaman, sehingga keuangan dan dasbor mewarisi biaya state dan operasional tanpa manfaat → pilihlah berdasarkan tenggat waktu tindakan konsumen.
• Hanya mengatakan bahwa streaming memiliki latensi rendah → sink, cache, dan pengiriman notifikasi dapat menghabiskan seluruh anggaran → ukur jalur end-to-end dan setiap latensi ekor.
• Menyebut tampilan 5 menit sebagai hasil final → event masih dapat tiba hingga 6 jam terlambat → tentukan semantik perkiraan, revisi, pembekuan, dan penyesuaian.
• Memperlakukan checkpoint sebagai tindakan eksternal exactly-once → percobaan ulang dapat mengulang panggilan inventaris atau notifikasi → gunakan kunci idempotensi tindakan, catatan audit, dan uji pemutaran ulang.
• Menambahkan (append) total baru dari setiap micro-batch → jendela yang sama dihitung berulang kali → gantikan secara atomik berdasarkan jendela dan versi atau tentukan protokol retractable-delta.
• Menyalin aturan bisnis ke dalam batch dan stream secara independen → definisi zona waktu, pembatalan, dan jumlah nilai akan bergeser (drift) → bagikan kontrak dan fixture, lalu bandingkan pada tingkat kunci.
• Menentukan ukuran kapasitas hanya untuk input stabil → lonjakan sepuluh kali lipat dan backlog kegagalan tidak dapat diselesaikan dalam tenggat waktu → uji puncak, laju pemulihan bersih, dan kapasitas sink secara bersamaan.
• Mengaktifkan tindakan nyata pada deployment pertama → diskrepansi semantik secara langsung mengubah inventaris → lakukan shadow-write dan amati peringatan sebelum secara bertahap mengaktifkan tindakan yang dapat dibatalkan.

Pertanyaan Lanjutan dan Jawabannya

Pertanyaan Lanjutan 1: Mengapa tidak menggunakan continuous streaming untuk dasbor 5 menit?

Jika micro-batch satu atau dua menit selesai dengan andal di bawah kondisi puncak dan pemulihan, dengan penulisan akhir dan penyegaran cache masih dalam waktu 5 menit, continuous streaming tidak mengubah keputusan operasional. Ini justru menambah biaya state jangka panjang, checkpoint, pemulihan backlog, dan deployment. Jika tenggat waktu nantinya menjadi 30 detik, atau penjadwalan dan startup menghabiskan sebagian besar anggaran micro-batch, putar ulang riwayat yang sama untuk membandingkannya dengan continuous streaming. Bukti terhadap SLO, bukan label “real time”, yang memicu peningkatan tersebut.

Pertanyaan Lanjutan 2: Bisakah satu stream menghasilkan peringatan, dasbor, dan hasil keuangan?

Bisa saja, tetapi satu checkpoint, perubahan skema, atau jendela yang buruk tidak boleh memblokir ketiga penggunaan tersebut. Peringatan dapat membaca stream yang dinormalisasi dan mempertahankan state pendek, dasbor dapat membaca agregat berversi, dan keuangan masih dapat menghitung ulang dari riwayat immutable pada snapshot yang dibekukan. Bagikan input dan definisi sambil mengisolasi deployment dan domain kegagalan. Gabungkan unit runtime hanya setelah membuktikan bahwa dampak kegagalan, backfill, dan audit tetap dapat diterima.

Pertanyaan Lanjutan 3: Apakah pemrosesan exactly-once membuat output stream cocok untuk penutupan keuangan?

Label itu saja tidak cukup. Semantik pemrosesan dapat menjaga output yang di-commit agar tidak menduplikasi pada percobaan ulang, tetapi mereka tidak menjamin bahwa rekaman yang terlambat telah tiba dan tidak secara otomatis mencakup efek samping. Keuangan masih memerlukan rentang input yang dibekukan, versi aturan, eksekusi yang dapat diulang, batasan buku besar, dan persetujuan diskrepansi. Output stream dapat berupa estimasi awal. Ini menjadi input penutupan buku hanya jika kontrol audit tersebut juga terpenuhi dan rekonsiliasi jangka panjang membuktikan kesetaraannya.

Pertanyaan Lanjutan 4: Bagaimana Anda membuktikan pemulihan dari lonjakan sepuluh kali lipat?

Catat durasi lonjakan dan durasi kegagalan, hitung event yang mengantre, dan ukur laju pengurasan bersih (net drain rate). Jika input saat ini adalah 20.000 per detik dan konsumen memproses 30.000 per detik, laju pengurasan bersih hanya 10.000 per detik; 12 juta event yang mengantre membutuhkan waktu sekitar 20 menit. Penerimaan juga mengamati latensi peringatan end-to-end, batas sink, pertumbuhan state, dan penundaan autoscaling. Angka throughput puncak tanpa perhitungan pemulihan bersih menyembunyikan pelanggaran batas ekor panjang (long-tail breach).

Pertanyaan Lanjutan 5: Kapan continuous streaming harus diturunkan ke micro-batch?

Turunkan saat bisnis tidak lagi mengambil tindakan berdasarkan output tingkat detik, micro-batch memenuhi tenggat waktu baru, atau biaya on-call dan state streaming secara terus-menerus melebihi kerugian yang dicegahnya. Pertama, jalankan micro-batch secara bayangan (shadow-run) dan bandingkan hasil serta latensinya. Kemudian nonaktifkan tindakan nyata sambil mempertahankan input yang dapat diputar ulang dan jendela rollback. Lanjutkan memantau revisi data terlambat dan waktu penyelesaian puncak setelah perubahan sehingga penghematan biaya tidak menyembunyikan data usang.