Wawancara Rekayasa Data: Bagaimana Anda merancang pipeline karantina kualitas data yang dapat diaudit?

Masalah dan Konteks

Sistem upstream mengirimkan 200 juta event pesanan per hari, dan sekitar 0,2% mungkin memiliki kolom wajib yang hilang, kegagalan parsing, atau pelanggaran aturan bisnis. Event yang valid harus terus mengalir ke tabel fakta dan metrik downstream. Event yang tidak valid tidak boleh hilang begitu saja secara diam-diam; setelah diperbaiki, event tersebut harus dapat diputar ulang dari input asli tanpa menghitung event yang sama dua kali.

Asumsikan desain batch-dan-stream dengan event_id yang stabil per input, salinan mentah (raw) yang tidak dapat diubah (immutable), aturan dengan versi skema, dan rekaman karantina yang menyimpan alasan kegagalan, versi aturan, dan status percobaan ulang (retry). Masalah wawancara ini berfokus pada perutean rekayasa data, observabilitas, dan pemulihan daripada sekadar opsi Spark tunggal.

Apa yang Dinilai Pewawancara

Memisahkan kegagalan parsing, kolom yang hilang, dan kegagalan validasi bisnis ke dalam kelas-kelas yang dapat ditindaklanjuti.
Mempertahankan bukti mentah, versi aturan, dan silsilah data (lineage) untuk audit dan pemutaran ulang.
Memilih antara fail-fast, drop, dan redirect/quarantine berdasarkan radius dampak (blast radius).
Menggunakan kunci idempotensi, status deduplikasi, dan versi output untuk mencegah penghitungan ganda.
Merancang metrik kualitas, ambang batas peringatan, alur kerja perbaikan, dan gerbang pemutaran ulang.
Menangani data beracun (toxic data), PII, retensi, dan kontrol akses di area karantina.

Klarifikasi yang Perlu Ditanyakan Terlebih Dahulu

Apakah 0,2% merupakan batas cacat (defect budget) yang diterima, atau apakah pelanggaran apa pun harus memblokir rilis? Ini menentukan gating berbasis ambang batas versus nol toleransi.
Bisakah event dicoba ulang, tiba tidak berurutan, atau terduplikasi? Jika ya, event_id harus menentukan batasan idempotensi.
Bisakah kegagalan aturan diperbaiki secara otomatis, atau apakah persetujuan manusia diperlukan? Ini mengubah antrean pemutaran ulang dan kontrolnya.
Bisakah metrik downstream mentolerir penundaan atau koreksi? Jika tidak, data yang diperbaiki memerlukan partisi kompensasi dan laporan berversi.
Apakah payload mentah berisi data pribadi (PII)? Hal tersebut mengubah persyaratan enkripsi, penyamaran (masking), akses, dan penghapusan.

Kerangka Jawaban 30 Detik

Saya membagi pipeline menjadi beberapa tahap: raw immutable, parsing, validasi aturan, valid, dan karantina. Kegagalan parsing dan aturan menghasilkan rekaman karantina yang berisi event_id, versi skema dan aturan, kode alasan, serta referensi data mentah; event yang valid masuk ke tabel fakta melalui penulisan idempoten. Area karantina menyediakan antrean perbaikan, persetujuan, dan pemutaran ulang. Pemutaran ulang menggunakan event_id yang sama dan melakukan deduplikasi pada batas target. Saya memantau tingkat validitas, rasio kode alasan, usia karantina, dan keberhasilan pemutaran ulang, lalu memilih gerbang peringatan atau pemblokiran berdasarkan SLO bisnis dan tingkat keparahan.

Pembahasan Mendalam Langkah demi Langkah

1. Pertahankan Bukti Mentah Terlebih Dahulu

Partisi objek atau log immutable berdasarkan batch, sumber, dan waktu penerimaan, serta simpan checksum. Tugas pemrosesan menambahkan status alih-alih menimpa payload mentah. Hal ini membuat peningkatan aturan, perbaikan parser, dan perselisihan pemasok dapat direproduksi dari input yang identik. Izin terpisah untuk lapisan mentah dan karantina mencegah pengguna dukungan mengedit fakta secara langsung.

2. Klasifikasikan Kegagalan dan Simpan Alasannya

Jalankan parsing byte/format terlebih dahulu, pemeriksaan tipe skema dan kolom wajib kedua, dan aturan bisnis lintas-kolom ketiga. Simpan nilai reason_code terstruktur seperti MALFORMED_JSON, MISSING_ORDER_ID, atau INVALID_CURRENCY. Sebuah rekaman mungkin memiliki beberapa alasan, tetapi pertahankan tahap kegagalan pertama dan versi aturan agar perbaikan selanjutnya tetap dapat dijelaskan.

text

quarantine_record = {
  event_id, source_batch, raw_uri, payload_hash,
  schema_version, rule_version, failed_stage,
  reason_codes, first_seen_at, status
}

Opsi file Spark dapat merekam file buruk atau mengabaikan file yang rusak, tetapi melanjutkan tugas tidak sama dengan menjaga rekaman bisnis secara aman. Desain harus secara eksplisit merutekan rekaman yang dapat dipulihkan ke karantina daripada hanya mengaktifkan sakelar abaikan.

3. Pilih Fail, Drop, atau Karantina

Input infrastruktur yang tidak dapat dibaca, tanda tangan yang tidak tepercaya, atau kerusakan yang dapat mengontaminasi seluruh batch harus menggagalkan batch (fail) dan mempertahankan peringatan. Kesalahan rekaman tunggal yang dapat diisolasi tanpa memengaruhi event lain harus dikarantina agar data yang valid tetap mengalir. Drop dapat diterima hanya jika rekaman tidak dapat dipulihkan, pemilik bisnis menerima kerugian tersebut, dan jejak audit diperlukan; setiap drop harus tetap dapat dihitung dan dilacak.

4. Tentukan Penulisan Valid yang Idempoten

Gunakan event_id ditambah versi sumber sebagai kunci unik, dan tulis ke tabel fakta melalui upsert idempoten atau commit log. Sebelum memutar ulang karantina, periksa apakah target telah menerima event tersebut, lalu pilih lewati (skip), perbarui (update), atau versi kompensasi. Untuk fakta yang dapat dikoreksi seperti jumlah pesanan, jangan menimpa riwayat secara diam-diam; keluarkan event koreksi dan biarkan laporan downstream menghitung ulang berdasarkan versi atau waktu efektif.

5. Perbaiki, Setujui, dan Putar Ulang

Alat perbaikan membuat payload atau patch baru dan tidak pernah memodifikasi lapisan mentah. Catat operator, alasan, hash input, dan versi aturan, lalu rutekan perubahan melalui persetujuan. Pekerja pemutaran ulang (replay worker) membaca status karantina dan menjalankan kembali seluruh rantai validasi. Jika berhasil, pekerja tersebut secara atomik memindahkan QUARANTINED ke REPLAYED; jika gagal, ia meningkatkan hitungan percobaan dan menjadwalkan waktu berikutnya. Lease atau kunci basis data mencegah dua pekerja menerapkan event yang sama secara bersamaan.

6. Metrik Kualitas dan Gerbang Rilis

Pantau total asupan, tingkat validitas, rasio masing-masing reason_code, persentil usia karantina, keberhasilan pemutaran ulang, event duplikat, dan koreksi downstream. Buat gerbang berdasarkan tingkat keparahan: kegagalan tanda tangan mungkin bernilai nol toleransi sementara kolom opsional yang hilang hanya memicu peringatan. Bahkan angka 0,2% harus dibandingkan dengan baseline historis, bauran sumber, dan kerugian bisnis alih-alih dinyatakan normal. Ketika gerbang terpicu, bekukan publikasi downstream atau lakukan rollback ke versi aturan sebelumnya dan catat rilis manual apa pun.

7. Retensi, Privasi, dan Pemulihan

Simpan hanya kolom mentah minimum yang diperlukan untuk perbaikan, enkripsi payload sensitif, dan batasi akses. Permintaan retensi dan penghapusan harus dipetakan dari event_id ke objek mentah, baris karantina, dan indeks turunan. Cadangkan antrean, tabel metadata, dan penyimpanan objek secara terpisah. Jika penulisan target berhasil tetapi pembaruan status gagal, coba lagi berdasarkan kunci unik; jika pemutaran ulang ditandai tetapi penulisan belum pasti, pulihkan dari commit log atau pemeriksaan tabel target alih-alih menyimpulkan keberhasilan dari respons pekerja.

Jawaban Model Berkualitas Tinggi

Pertama-tama saya akan mengonfirmasi batas cacat yang diterima, pengiriman duplikat atau terlambat, dan apakah koreksi pesanan dapat menunggu pelaporan. Pipeline mempertahankan lapisan mentah yang immutable, lalu menjalankan parsing, skema, dan aturan bisnis secara bertahap. Kesalahan tingkat rekaman yang dapat dipulihkan masuk ke karantina; kegagalan infrastruktur atau keamanan memblokir batch. Baris karantina menyimpan kunci idempotensi, referensi mentah, versi aturan, kode alasan, dan status. Event yang valid ditulis secara idempoten ke tabel fakta. Perbaikan membuat payload baru dan memerlukan persetujuan; pemutaran ulang menjalankan kembali rantai validasi lengkap dan menandai keberhasilan secara atomik. Metrik mencakup tingkat validitas, alasan, usia karantina, tingkat pemutaran ulang, dan dampak duplikasi, dengan gerbang berbasis keparahan. Ini menjaga agar bagian buruk yang kecil tidak memblokir batch tanpa menyembunyikan anomali sebagai data yang sehat.

Kesalahan Umum

Mengaktifkan ignoreCorruptFiles dan menyatakan berhasil → tugas berlanjut tetapi rekaman dapat hilang → rutekan rekaman yang dapat dipulihkan ke karantina berkode alasan.
Menyimpan kegagalan dalam tabel yang dapat diedit → bukti mentah dapat diubah → pertahankan data mentah tetap immutable dan buat versi perbaikan baru.
Memasukkan kembali event yang diputar ulang secara langsung → metrik downstream menghitung dua kali → gunakan batasan keunikan event_id dan commit log.
Memblokir seluruh batch untuk setiap kesalahan → bagian buruk yang kecil merusak kesegaran (freshness) data → pilih fail atau karantina berdasarkan tahap dan tingkat keparahan.
Hanya menghitung total kegagalan → regresi sumber dan aturan tetap tersembunyi → uraikan metrik berdasarkan alasan, versi skema, sumber, dan waktu.
Melewatkan validasi setelah perbaikan → patch dapat memperkenalkan cacat kedua → pemutaran ulang harus mengeksekusi rantai validasi lengkap.

Pertanyaan Lanjutan dan Tanggapan

Tingkat karantina melonjak dari 0,2% menjadi 8%. Apakah Anda tetap memublikasikannya?

Pisahkan berdasarkan alasan dan sumber terlebih dahulu. Jika satu pemasok memiliki kolom hilang yang dapat dipulihkan, jeda sumber tersebut dan lanjutkan yang lain. Jika parsing atau validasi tanda tangan gagal, bekukan publikasi downstream dan lakukan rollback versi aturan. Ambang batas harus mencerminkan kerugian bisnis dan baseline historis, bukan hanya persentase absolut.

Bagaimana Anda mencegah pemutaran ulang mengubah pesanan yang sudah diselesaikan (settled)?

Pisahkan event asli dan koreksi, dan pertahankan kolom versi atau waktu efektif di tabel fakta. Snapshot penyelesaian mengunci generasi inputnya. Event yang diperbaiki melalui alur kerja kompensasi di mana aturan keuangan memutuskan apakah akan membuat penyesuaian daripada menimpa jumlah yang telah diselesaikan secara diam-diam.

Area karantina berisi PII. Bagaimana dukungan dapat menyelidikinya?

Tampilkan kolom yang disamarkan (masked) dan kode alasan secara default. Berikan akses berwenang berdurasi singkat ke payload mentah dan catat setiap event audit. Permintaan penghapusan mengikuti event_id di seluruh objek mentah, baris karantina, dan indeks turunan, dan hanya mempertahankan ringkasan (digest) audit yang tidak dapat diubah setelahnya.

Seorang pekerja mengalami crash setelah penulisan target tetapi sebelum mengubah status karantina. Apa yang terjadi?

Saat mencoba lagi, periksa tabel target dan commit log berdasarkan kunci idempotensi. Jika ada, perbaiki statusnya saja; jangan ulangi efek samping penulisan. Jika tidak ada, kirim ulang. Gunakan transisi status bersyarat yang dapat dicoba ulang sehingga hasil yang tidak diketahui tidak pernah ditebak sebagai keberhasilan atau kegagalan.

Kapan sebuah rekaman harus di-drop alih-alih disimpan?

Hanya jika rekaman tersebut tidak dapat dipulihkan, tidak ada aturan kepatuhan yang mewajibkan retensi, dan pemilik bisnis secara eksplisit menerima kerugian tersebut. Meskipun demikian, pertahankan jumlah, alasan, batch, dan versi kebijakan yang dapat diaudit, serta tampilkan rekaman yang di-drop tersebut dalam laporan kualitas.