Bagaimana pendekatan untuk memproses data dalam jumlah besar?

Question

IT Interview Practice · Accepted Answer

**Mulai dari hasil, tenggat, dan aturan kebenaran sebelum memilih alat big data.** Dataset besar tidak otomatis membutuhkan framework pemrosesan terdistribusi.

Misalnya bisnis membutuhkan pendapatan kemarin per merchant setiap pagi. Ini berbeda dari mendeteksi pembayaran mencurigakan sebelum menyetujuinya. Keduanya mungkin melibatkan banyak record, tetapi yang satu memungkinkan pemrosesan terjadwal, sedangkan yang lain membutuhkan keputusan tepat waktu.

## 1. Tentukan apa yang harus diproses

Perjelas jumlah data yang ada, kecepatan kedatangan data baru, field yang dibutuhkan, dan masa penyimpanannya. Untuk laporan pendapatan, sepakati apakah refund mengubah hari transaksi asli atau hari refund. Tanpa aturan itu, pipeline yang lebih cepat tetap dapat menghasilkan total yang salah.

Tentukan juga sumber kebenaran serta penanganan record terlambat atau dikoreksi. Keputusan ini menentukan apakah hasil lama dapat difinalisasi atau harus direvisi kemudian.

## 2. Kurangi pekerjaan sebelum mendistribusikannya

Ukur penggunaan waktu dan sumber daya: pembacaan file, kueri database, komputasi, transfer jaringan, atau penulisan hasil. Lalu saring record yang tidak relevan sedini mungkin dan baca hanya kolom yang diperlukan laporan.

Proses potongan berukuran terbatas alih-alih memuat semuanya ke memori. Jika satu worker dapat selesai sebelum tenggat dengan biaya yang dapat diterima, itu mungkin sistem paling mudah dioperasikan. Lebih banyak mesin menambah biaya koordinasi dan transfer data, jadi tambahkan untuk mengatasi batas yang sudah diamati.

## 3. Pilih batch atau streaming berdasarkan tenggat

| Kebutuhan | Pendekatan awal | Alasan dan tanggung jawab |
|---|---|---|
| Laporan lengkap setiap pagi | Batch terjadwal | Input terbatas lebih mudah dicocokkan dan dijalankan ulang; proses harus selesai sebelum tenggat |
| Dashboard diperbarui sepanjang hari | Batch inkremental atau streaming | Proses data baru lebih sering; tentukan bagaimana koreksi memperbarui total sebelumnya |
| Keputusan segera setelah setiap event | Streaming | Kurangi keterlambatan sambil menangani duplikasi, event terlambat, dan pemulihan |

Streaming berarti memproses data yang datang secara berkelanjutan, bukan menganggap setiap event tiba sekali dan berurutan. Untuk laporan harian tadi, saya akan mulai dengan batch kecuali bisnis benar-benar membutuhkan hasil lebih segar.

## 4. Buat kegagalan sebagian tetap aman

Bayangkan worker menulis total pendapatan lalu gagal sebelum mencatat progres. Saat dimulai ulang, worker mungkin memproses record yang sama lagi. Jika nilainya sekadar ditambahkan kembali, pendapatan akan terlalu besar.

Gunakan pengenal record yang stabil dan penulisan yang aman diulang, atau koordinasikan hasil dan pencatatan progres secara transaksional jika didukung. Checkpoint mencatat progres yang selesai; menyimpannya sebelum hasil tersimpan dengan aman dapat melewatkan pekerjaan setelah kegagalan. Menyimpannya setelah hasil membutuhkan pengulangan aman untuk celah tersebut.

- Pertahankan data sumber cukup lama untuk memproses ulang periode yang diperlukan.
- Pisahkan record tidak valid untuk diperiksa, bukan membuangnya diam-diam.
- Batasi laju pengiriman worker ke tujuan yang lebih lambat. Backpressure ini mencegah buffer memori atau antrean tumbuh tanpa batas.

Perilaku pemulihan merupakan bagian dari desain, bukan pekerjaan pembersihan setelah kegagalan pertama.

## 5. Distribusikan hanya pekerjaan yang membutuhkannya

Ketika satu worker tidak cukup, bagi input menjadi bagian yang dapat dijalankan independen. Periksa distribusi data sebenarnya: satu merchant sangat besar dapat membuat satu worker terus sibuk sementara yang lain selesai lebih awal.

Pengelompokan dan join mungkin membutuhkan pemindahan record antar-worker, yang disebut shuffle. Kurangi data sebelum pemindahan jika memungkinkan dan pastikan tujuan mampu menerima hasil gabungan. Spark menawarkan teknik yang relevan, tetapi kesesuaiannya bergantung pada kueri dan versi; lihat [panduan optimasi performa](https://spark.apache.org/docs/3.5.6/sql-performance-tuning.html).

Penyimpanan juga perlu mengikuti pola akses. File berorientasi kolom seperti Parquet dapat cocok untuk pemindaian analitik atas field terpilih, sedangkan database berindeks mungkin lebih sesuai untuk pengambilan record operasional individual. Pilih berdasarkan kebutuhan akses yang diukur, bukan ukuran file saja.

## 6. Buktikan kecepatan dan kebenaran bersama-sama

Bandingkan hasil dengan dataset kecil yang terpercaya, dengan memeriksa jumlah record sekaligus total bisnis. Sertakan event duplikat, refund, record terlambat, dan kegagalan antara penulisan hasil dan penyimpanan progres.

Kemudian uji volume dan ketimpangan realistis sambil mengukur durasi, puncak memori, tumpukan pekerjaan, dan biaya. Untuk laporan pendapatan, keberhasilan berarti total yang benar dan dapat dihasilkan ulang tersedia sebelum tenggat yang disepakati. **Pilih pipeline paling sederhana yang memenuhi kondisi tersebut dan dapat pulih tanpa kehilangan atau menghitung data dua kali.**

Kebutuhan	Pendekatan awal	Alasan dan tanggung jawab
Laporan lengkap setiap pagi	Batch terjadwal	Input terbatas lebih mudah dicocokkan dan dijalankan ulang; proses harus selesai sebelum tenggat
Dashboard diperbarui sepanjang hari	Batch inkremental atau streaming	Proses data baru lebih sering; tentukan bagaimana koreksi memperbarui total sebelumnya
Keputusan segera setelah setiap event	Streaming	Kurangi keterlambatan sambil menangani duplikasi, event terlambat, dan pemulihan

1. Tentukan apa yang harus diproses

2. Kurangi pekerjaan sebelum mendistribusikannya

3. Pilih batch atau streaming berdasarkan tenggat

4. Buat kegagalan sebagian tetap aman

5. Distribusikan hanya pekerjaan yang membutuhkannya

6. Buktikan kecepatan dan kebenaran bersama-sama

Pertanyaan terkait