Temu Bual Kejuruteraan Data: Bagaimanakah anda mereka bentuk saluran paip kuarantin kualiti data yang boleh diaudit?

Masalah dan Konteks

Sistem huluan menghantar 200 juta peristiwa pesanan setiap hari, dan kira-kira 0.2% daripadanya mungkin mempunyai medan mandatori yang hilang, kegagalan penghuraian (parsing) atau pelanggaran peraturan perniagaan. Peristiwa yang sah mesti terus mengalir ke dalam jadual fakta dan metrik hiliran. Peristiwa tidak sah tidak boleh hilang secara senyap; selepas dibaiki, ia mesti boleh dimainkan semula daripada input asal tanpa mengira peristiwa yang sama sebanyak dua kali.

Andaikan reka bentuk kelompok-dan-strim dengan event_id yang stabil bagi setiap input, salinan mentah yang tidak boleh diubah (immutable), peraturan dengan versi skema, dan rekod kuarantin yang mengekalkan sebab kegagalan, versi peraturan serta keadaan percubaan semula. Masalah temu bual ini adalah mengenai penghalaan kejuruteraan data, kebolehcerapan dan pemulihan, dan bukannya sekadar pilihan Spark tunggal.

Perkara yang Dinilai oleh Penemu Bual

Mengasingkan kegagalan penghuraian, medan hilang dan kegagalan pengesahan perniagaan kepada kelas yang boleh diambil tindakan.
Mengekalkan bukti mentah, versi peraturan dan salasilah (lineage) untuk audit dan main semula.
Memilih antara fail-fast, drop dan redirect/quarantine berdasarkan radius impak.
Menggunakan kunci keidempotetan, status penyahduplikasian dan versi output untuk mengelakkan pengiraan dua kali.
Mereka bentuk metrik kualiti, ambang amaran, aliran kerja pembaikan dan pagar main semula.
Menangani data toksik, PII, pengekalan dan kawalan capaian dalam kawasan kuarantin.

Penjelasan untuk Ditanya Terlebih Dahulu

Adakah 0.2% merupakan belanjawan kecacatan yang diterima, atau adakah sebarang pelanggaran mesti menyekat pelepasan? Ini menentukan pemagaran berasaskan ambang berbanding toleransi sifar.
Bolehkah peristiwa dicuba semula, tiba tidak mengikut urutan atau diduplikasi? Jika ya, event_id mesti mentakrifkan sempadan keidempotetan.
Bolehkah kegagalan peraturan dibaiki secara automatik, atau adakah kelulusan manusia diperlukan? Ini mengubah barisan gilir main semula dan kawalan.
Bolehkah metrik hiliran bertoleransi terhadap kelewatan atau pembetulan? Jika tidak, data yang dibaiki memerlukan partisi pampasan dan laporan berversi.
Adakah muatan mentah mengandungi data peribadi? Perkara itu mengubah keperluan penyulitan, penyembunyian (masking), capaian dan pemadaman.

Kerangka Jawapan 30 Saat

Saya membahagikan saluran paip kepada peringkat mentah tidak boleh ubah, penghuraian, pengesahan peraturan, sah dan kuarantin. Kegagalan penghuraian dan peraturan menghasilkan rekod kuarantin yang mengandungi event_id, versi skema dan peraturan, kod sebab, serta rujukan mentah; peristiwa yang sah memasuki jadual fakta melalui penulisan idempoten. Kawasan kuarantin menyediakan barisan gilir pembaikan, kelulusan dan main semula. Main semula menggunakan event_id yang sama dan menyahduplikasi pada sempadan sasaran. Saya memantau kadar sah, nisbah kod sebab, usia kuarantin dan kejayaan main semula, kemudian memilih pagar amaran atau penyekatan mengikut SLO perniagaan dan tahap keterukan.

Perincian Langkah demi Langkah

1. Kekalkan Bukti Mentah Terlebih Dahulu

Partisikan objek atau log tidak boleh ubah mengikut kelompok, sumber dan masa penerimaan, serta simpan checksum. Tugas pemprosesan menambahkan status dan bukannya menulis ganti muatan mentah. Ini membolehkan peningkatan peraturan, pembaikan penghurai dan pertikaian pembekal dapat dihasilkan semula daripada input yang sama. Kebenaran berasingan untuk lapisan mentah dan kuarantin menghalang pengguna sokongan daripada menyunting fakta secara langsung.

2. Kelaskan Kegagalan dan Simpan Sebab

Jalankan penghuraian bait/format terlebih dahulu, pemeriksaan jenis skema dan medan mandatori kedua, dan peraturan perniagaan rentas-medan ketiga. Simpan nilai reason_code berstruktur seperti MALFORMED_JSON, MISSING_ORDER_ID atau INVALID_CURRENCY. Sesuatu rekod mungkin mempunyai pelbagai sebab, tetapi kekalkan peringkat kegagalan pertama dan versi peraturan supaya pembaikan kemudiannya kekal boleh dijelaskan.

text

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

Pilihan fail Spark boleh merekodkan fail yang rosak atau mengabaikan fail yang korup, tetapi meneruskan tugas tidak sama dengan mengekalkan rekod perniagaan dengan selamat. Reka bentuk mesti menghalakan rekod yang boleh dipulihkan ke kuarantin secara eksplisit daripada hanya mendayakan suis abaikan.

3. Pilih Fail, Drop atau Kuarantin

Input infrastruktur yang tidak boleh dibaca, tandatangan yang tidak dipercayai atau kerosakan yang boleh mencemarkan keseluruhan kelompok harus menggagalkan kelompok (fail) dan mengekalkan amaran. Ralat rekod tunggal yang boleh diasingkan tanpa menjejaskan peristiwa lain harus dikuarantin supaya data yang sah terus mengalir. Drop hanya boleh diterima apabila rekod tidak boleh dipulihkan, pemilik perniagaan menerima kehilangan tersebut dan jejak audit diperlukan; setiap rekod yang digugurkan mesti kekal boleh dikira dan dikesan.

4. Takrifkan Penulisan Sah yang Idempoten

Gunakan event_id ditambah versi sumber sebagai kunci unik, dan tulis jadual fakta melalui upsert idempoten atau log komit. Sebelum memainkan semula kuarantin, semak sama ada sasaran telah menerima peristiwa tersebut, kemudian pilih langkau, kemas kini atau versi pampasan. Untuk fakta yang boleh diperbetulkan seperti jumlah pesanan, jangan tulis ganti sejarah secara senyap; keluarkan peristiwa pembetulan dan biarkan laporan hiliran mengira semula mengikut versi atau masa berkuat kuasa.

5. Baiki, Luluskan dan Main Semula

Alat pembaikan mencipta muatan atau tampalan baharu dan tidak sekali-kali mengubah lapisan mentah. Rekodkan pengendali, sebab, cincangan (hash) input dan versi peraturan, kemudian halakan perubahan melalui kelulusan. Pekerja main semula membaca status kuarantin dan menjalankan semula rantaian pengesahan yang lengkap. Jika berjaya, ia memindahkan QUARANTINED kepada REPLAYED secara atomik; jika gagal, ia meningkatkan bilangan percubaan dan menjadualkan masa seterusnya. Pajakan atau kunci pangkalan data menghalang dua pekerja daripada menggunakan peristiwa yang sama secara serentak.

6. Metrik Kualiti dan Pagar Pelepasan

Pantau jumlah pengambilan, kadar sah, setiap nisbah reason_code, persentil usia kuarantin, kejayaan main semula, peristiwa pendua dan pembetulan hiliran. Tetapkan pagar mengikut tahap keterukan: kegagalan tandatangan mungkin bertoleransi sifar manakala medan pilihan yang hilang hanya mencetuskan amaran. Walaupun 0.2%, ia harus dibandingkan dengan garis dasar sejarah, campuran sumber dan kerugian perniagaan dan bukannya diisytiharkan sebagai normal. Apabila pagar terpicu, bekukan penerbitan hiliran atau undurkan (rollback) ke versi peraturan sebelumnya dan rekodkan sebarang pelepasan manual.

7. Pengekalan, Privasi dan Pemulihan

Simpan hanya medan mentah minimum yang diperlukan untuk pembaikan, sulitkan muatan sensitif dan sekat capaian. Permintaan pengekalan dan pemadaman mesti dipetakan daripada event_id kepada objek mentah, baris kuarantin dan indeks terbitan. Sandarkan barisan gilir, jadual metadata dan storan objek secara berasingan. Jika penulisan sasaran berjaya tetapi kemas kini status gagal, cuba semula mengikut kunci unik; jika main semula ditandakan tetapi penulisan tidak pasti, pulihkan daripada log komit atau pemeriksaan jadual sasaran dan bukannya menyimpulkan kejayaan daripada respons pekerja.

Jawapan Model Berkualiti Tinggi

Saya akan terlebih dahulu mengesahkan belanjawan kecacatan yang boleh diterima, penghantaran pendua atau lewat, dan sama ada pembetulan pesanan boleh menunggu pelaporan. Saluran paip mengekalkan lapisan mentah yang tidak boleh diubah, kemudian menjalankan penghuraian, skema dan peraturan perniagaan mengikut peringkat. Ralat peringkat rekod yang boleh dipulihkan pergi ke kuarantin; kegagalan infrastruktur atau keselamatan menyekat kelompok. Baris kuarantin menyimpan kunci keidempotetan, rujukan mentah, versi peraturan, kod sebab dan status. Peristiwa yang sah ditulis secara idempoten ke dalam jadual fakta. Pembaikan mencipta muatan baharu dan memerlukan kelulusan; main semula menjalankan semula rantaian pengesahan penuh dan menandakan kejayaan secara atomik. Metrik merangkumi kadar sah, sebab, usia kuarantin, kadar main semula dan kesan pendua, dengan pagar berasaskan keterukan. Ini memastikan sebahagian kecil data rosak tidak menyekat keseluruhan kelompok tanpa menyembunyikan anomali sebagai data yang sihat.

Kesilapan Biasa

Mendayakan ignoreCorruptFiles dan mengisytiharkan kejayaan → tugas diteruskan tetapi rekod mungkin lenyap → halakan rekod yang boleh dipulihkan ke kuarantin berkod sebab.
Menyimpan kegagalan dalam jadual yang boleh disunting → bukti mentah boleh diubah → pastikan data mentah tidak boleh diubah dan cipta versi pembaikan baharu.
Memasukkan semula peristiwa yang dimainkan semula secara langsung → metrik hiliran mengira dua kali → gunakan sempadan keunikan event_id dan log komit.
Menyekat keseluruhan kelompok untuk setiap ralat → sebahagian kecil data rosak memusnahkan kesegaran → pilih fail atau kuarantin mengikut peringkat dan keterukan.
Hanya mengira jumlah kegagalan → regresi sumber dan peraturan kekal tersembunyi → pecahkan metrik mengikut sebab, versi skema, sumber dan masa.
Melangkau pengesahan selepas pembaikan → tampalan boleh memperkenalkan kecacatan kedua → main semula mesti melaksanakan rantaian pengesahan yang lengkap.

Soalan Susulan dan Maklum Balas

Kadar kuarantin melonjak daripada 0.2% kepada 8%. Adakah anda terus menerbitkan?

Pecahkan mengikut sebab dan sumber terlebih dahulu. Jika seorang pembekal mempunyai medan hilang yang boleh dipulihkan, jeda sumber tersebut dan teruskan yang lain. Jika penghuraian atau pengesahan tandatangan gagal, bekukan penerbitan hiliran dan undurkan versi peraturan. Ambang harus mencerminkan kerugian perniagaan dan garis dasar sejarah, bukan hanya peratusan mutlak.

Bagaimanakah anda menghalang main semula daripada mengubah pesanan yang telah diselesaikan (settled)?

Asingkan peristiwa asal dan pembetulan, serta kekalkan lajur versi atau masa berkuat kuasa dalam jadual fakta. Snapshot penyelesaian menetapkan generasi inputnya. Peristiwa yang dibaiki melalui aliran kerja pampasan di mana peraturan kewangan memutuskan sama ada untuk membuat pelarasan dan bukannya menulis ganti jumlah yang telah diselesaikan secara senyap.

Kawasan kuarantin mengandungi PII. Bagaimanakah pihak sokongan boleh menyiasat?

Paparkan medan yang disembunyikan (masked) dan kod sebab secara lalai. Berikan capaian dibenarkan jangka pendek kepada muatan mentah dan rekodkan setiap peristiwa audit. Permintaan pemadaman mengikut event_id merentasi objek mentah, baris kuarantin dan indeks terbitan, dengan hanya mengekalkan ringkasan (digest) audit yang tidak boleh diterbalikkan selepas itu.

Pekerja terhenti (crash) selepas penulisan sasaran tetapi sebelum menukar status kuarantin. Apakah yang berlaku?

Semasa mencuba semula, semak jadual sasaran dan log komit mengikut kunci keidempotetan. Jika ada, baiki status sahaja; jangan ulangi kesan sampingan. Jika tiada, serahkan semula. Gunakan peralihan status bersyarat dan boleh dicuba semula supaya hasil yang tidak diketahui tidak pernah diteka sebagai berjaya atau gagal.

Bilakah rekod patut digugurkan (drop) dan bukannya disimpan?

Hanya apabila ia tidak boleh dipulihkan, tiada peraturan pematuhan yang memerlukan pengekalan, dan pemilik perniagaan secara eksplisit menerima kehilangan tersebut. Walaupun begitu, kekalkan kiraan, sebab, kelompok dan versi dasar yang boleh diaudit, serta dedahkan pengguguran tersebut dalam laporan kualiti.