Raw Dulu, Parse Belakangan: Pola Harvest yang Tahan Gagal
Pola raw dulu, parse belakangan: data mentah disimpan utuh dulu, parsing jadi proses turunan yang aman diulang saat parser berubah.
Ringkasan
Scraping data dari web itu rentan mandek di tengah jalan, makanya jangan langsung parsing sambil ambil. Simpan dulu data mentahnya utuh, baru parsing terpisah lewat perintah rebuild, pakai kursor dan ledger idempoten biar bisa lanjut tanpa data dobel. Jadi kalau parser ada yang salah, tinggal perbaiki terus rebuild deh, nggak usah buka situs sumbernya lagi.
Sesi pengambilan data berhenti di halaman 8 dari total 20 halaman daftar perkara. Empat belas halaman detail perkara berhasil ditangkap satu per satu melalui panel pratinjau peramban interaktif. Pada titik ini, aksi klik atau buka tautan tidak lagi merespons, dan hanya navigasi menggunakan tombol Enter yang berfungsi.
Asumsi yang terasa masuk akal adalah melakukan parsing selama proses pengambilan berlangsung. Satu kali proses berjalan, data langsung terstruktur, dan pekerjaan dianggap selesai. Efisiensi komputasinya memang terlihat di atas kertas.
Fakta pada implementasinya berbeda. Alat pencatat menyimpan teks yang dirender secara verbatim terlebih dahulu ke raw/page-N.txt dan raw/detil-*.txt. Pemrosesan terstruktur berjalan pada tahap kedua secara terpisah. Sebuah subperintah rebuild kemudian menghasilkan ulang ledger dan berkas CSV dari direktori raw tersebut. Dengan pola ini, perbaikan pada logika parser dapat diterapkan secara retrospektif pada data yang sudah diambil, tanpa mengakses ulang sumber asli.
Ilusi Efisiensi Parsing Sekali Jalan
Sumber data pada kasus ini terikat pada sesi PHP di balik gerbang anti-bot yang menyertakan interstitial captcha. Dalam kondisi seperti ini, akses ulang tidak pernah terjamin. Sesi dapat kedaluwarsa, alamat IP dapat diblokir, atau struktur DOM dapat berubah tanpa peringatan. Sementara itu, kesalahan parsing adalah hal yang pasti terjadi seiring bertambahnya variasi format halaman.
Pendekatan raw dulu, parse belakangan mengubah risiko akses ulang menjadi proses parsing ulang lokal yang terkendali. Data mentah berfungsi sebagai satu-satunya sumber kebenaran. W3C PROV-Overview mendefinisikan provenance sebagai informasi mengenai entitas, aktivitas, dan pihak yang terlibat dalam menghasilkan suatu data, yang digunakan untuk menilai kualitas, keandalan, dan kepercayaan data tersebut [1]. Menyimpan data mentah secara utuh memenuhi prinsip provenance ini dengan menyediakan jejak audit yang tidak berubah.
Prinsip yang sama muncul di skala besar pada Medallion architecture dari Databricks, di mana lapisan Bronze mendaratkan data mentah sebagaimana adanya: arsip historis, lineage, auditabilitas, dan kemampuan pemrosesan ulang tanpa membaca ulang sistem sumber [3]. Direktori raw pada skrip pengambilan data memainkan peran lapisan Bronze yang sama, hanya pada skala berkas teks.
Pola ini bukan untuk semua sumber. API terbuka dengan endpoint yang stabil dapat diambil ulang kapan saja; menyimpan respons mentah per eksekusi hanyalah bonus. Raw-first membayar ketika akses ulang mahal: sumber bergerbang captcha, sesi yang kedaluwarsa, atau halaman yang bisa berubah antara dua kunjungan. Semakin mahal sebuah halaman untuk didatangi ulang, semakin berharga berkas verbatimnya.
Ledger Idempoten dan Kursor yang Dapat Dilanjutkan
Implementasi pola ini memerlukan pencatatan yang rapi. Kursor eksekusi disimpan pada state.json: identitas run, nomor halaman daftar, referensi yang tertunda, dan set kasus yang sudah selesai. Jika sesi interaktif terhenti di tengah jalan, eksekusi berikutnya melanjutkan dari kursor terakhir tanpa mengulang pekerjaan yang sudah valid.
Setiap aksi dicatat satu baris dalam run-log.jsonl. Format JSON Lines memang dirancang untuk data terstruktur yang diproses satu catatan demi satu catatan, cocok untuk berkas log dan kompatibel dengan alat teks standar [4]. Urutan eksekusi dapat ditelusuri penuh ketika ada anomali.
Hasil parsing tersimpan dalam ledger.jsonl, idempoten berdasarkan case_no dan detail_url. Mekanismenya meniru perilaku UPSERT pada SQLite: INSERT berperilaku sebagai UPDATE atau no-op saat pelanggaran constraint keunikan terjadi [2]. Eksekusi berulang atas detail yang sama otomatis dilewati, sehingga tidak ada data ganda yang tersisa di ledger.
Pemulihan saat menemukan field yang salah parse berjalan dalam satu langkah: perbaiki aturan di parser, bukan di data, lalu jalankan rebuild. Seluruh baris terbentuk ulang dari berkas raw dalam hitungan detik. Tidak ada satu pun halaman yang perlu didatangi ulang.
Ketika parser berubah lagi enam bulan kemudian, langkahnya tetap sama. Representasi terstruktur mengikuti parser terbaru; data mentah tidak pernah berubah. Kebutuhan menyentuh ulang situs sumber yang bergerbang hilang sama sekali, dan itulah return sesungguhnya dari menyimpan raw terlebih dahulu.