Kehendak soalan dan skop
Ini ialah soalan reka bentuk platform data dan kejuruteraan analitik yang lazim. Matlamatnya adalah untuk menguraikan "data yang boleh dipercayai" kepada dimensi yang boleh diukur dan menghubungkannya dengan penggunaan pengguna serta pemulihan, berbanding sekadar menyenaraikan beberapa semakan.
Perkara yang dinilai oleh penemu duga
- Sama ada anda membezakan kesegaran (freshness), kesempurnaan (completeness), kesahan (validity), ketepatan (accuracy), ketekalan (consistency), dan keunikan (uniqueness).
- Sama ada sasaran mencerminkan setiap produk data dan pengguna, bukannya satu ambang global.
- Sama ada pengesanan, amaran berasaskan tahap keterukan, penyekatan hiliran, dan pemulihan direka bentuk bersama-sama.
- Sama ada bukti kualiti, versi, dan keturunan data (lineage) dikekalkan supaya amaran kekal boleh diambil tindakan.
Soalan penjelasan untuk ditanya terlebih dahulu
Sahkan input kelompok (batch) berbanding penstriman (streaming), masa peristiwa berbanding masa ketibaan, jadual atau medan yang digunakan oleh pelanggan, kewangan, atau model, kelewatan yang dibenarkan, sekatan lewat dan zon masa, serta sama ada pengguna perlu disekat, diturunkan kualiti perkhidmatan (degrade), atau memaparkan syot kilat (snapshot) dipercayai yang terakhir semasa insiden berlaku.
Struktur jawapan 30 saat
Saya akan mentakrifkan kontrak data mengikut penggunaan pengguna, kemudian mengkonfigurasi semakan kesegaran, volum, kesempurnaan, dan kesahan bagi setiap set data. Saluran paip menyimpan hasil kualiti dan lineage, menghalakan amaran dan kegagalan yang menyekat kepada pemilik, serta membolehkan tugas hiliran membaca status kualiti. Bagi pelepasan yang disekat, pengguna menerima snapshot dipercayai yang bertanda masa; pemulihan menggunakan pengisian semula (backfill), pengiraan semula, dan penyelarasan untuk menutup insiden.
Jawapan mendalam
1. Menghubungkan dimensi kualiti dengan penggunaan
Kesegaran menilai bila data boleh guna terkini dihasilkan; kesempurnaan memeriksa sama ada medan atau sekatan yang diperlukan telah tiba; volum memeriksa baris atau bait yang dijangkakan; kesahan memeriksa format dan julat; ketekalan memeriksa hubungan rentas jadual; keunikan memeriksa data pendua. Ambang batas harus berbeza untuk penyelesaian kewangan (settlement), papan pemuka operasi, dan latihan model luar talian.
2. Mentakrifkan SLA dan SLO yang boleh dilaksanakan
Rekodkan tarikh akhir perniagaan, kelewatan maksimum, nisbah kehilangan yang dibenarkan, syarat penyekatan, pemilik, dan masa eskalasi bagi setiap set data. Jejaki "data tiba tetapi gagal pengesahan" secara berasingan daripada "sistem huluan tidak menghasilkan data baharu." Berikan tetingkap backfill yang terhad untuk data yang lewat; selepas tamat tempoh, tandakan sekatan sebagai tidak tersedia dan bukannya menunggu selama-lamanya.
3. Menyimpan bukti berversi
Kekalkan versi peraturan, kelompok atau sekatan, nilai yang diperhatikan, ambang batas, masa larian, lineage input dan output, serta hasil keputusan. Expectations atau sistem deklaratif lain boleh mentakrifkan semakan, manakala lejar kualiti yang boleh ditanya membolehkan kegagalan diaudit. Nilaikan ambang baharu berbanding garis dasar sejarah supaya perubahan konfigurasi tidak menyembunyikan regresi.
4. Mereka bentuk amaran, penyekatan, dan degradasi
Hala amaran mengikut impak dan keterukan kepada pemilik data, pasukan on-call platform, dan pengguna perniagaan. Sekatan hilang yang boleh dipulihkan boleh ditandakan sebagai lewat sementara snapshot yang dipercayai kekal tersedia; kegagalan yang boleh mencemarkan data kewangan atau model mesti menyekat penerbitan. Setiap sekatan memerlukan syarat eskalasi, kelulusan, dan pelepasan supaya pengguna tidak boleh memintasnya begitu sahaja.
5. Melengkapkan kitaran dengan backfill dan penyelarasan
Selepas membetulkan sistem huluan, lakukan backfill mengikut sekatan atau masa perniagaan, jalankan semula versi transformasi dan peraturan yang sama, serta rekodkan kelompok pembaikan untuk mengelakkan penulisan pendua. Selaraskan baris input, baris output, data ditolak, rekod lewat, dan penggunaan hiliran. Tutup insiden hanya selepas metrik kembali kepada garis dasar, kemudian laraskan peraturan, ambang, atau pemilikan dalam semakan pasca-insiden.
Contoh jawapan yang mantap
Saya akan mentakrifkan kontrak mengikut pengguna. Jadual settlement mesti tiba dalam tempoh satu jam daripada tarikh akhir hariannya dengan ambang kesempurnaan yang ditetapkan, manakala papan pemuka penerokaan boleh bertoleransi dengan kelewatan yang lebih lama. Setiap set data menerima semakan kesegaran, kiraan sekatan, medan wajib, julat, dan rentas jadual; setiap hasil menyimpan versi peraturan, pemerhatian, kelompok, lineage, dan pemilik. Had masa kesegaran akan memberi amaran terlebih dahulu, tetapi kegagalan kesempurnaan pada data kewangan menyekat penerbitan dan membekalkan snapshot dipercayai yang bertanda masa. Selepas pembetulan huluan, saya melakukan backfill mengikut masa perniagaan, menggunakan semula transformasi dan semakan yang sama, menyelaraskan input, output, data ditolak, dan kiraan pengguna, serta menutup insiden hanya apabila metrik pulih sepenuhnya.
Kesilapan lazim
- Memantau kejayaan tugas tanpa memeriksa sama ada data itu segar, lengkap, dan sah.
- Menggunakan satu ambang global untuk set data yang mempunyai pengguna dan tarikh akhir yang berbeza.
- Menulis hasil kualiti hanya pada log, tanpa pautan kelompok, versi peraturan, atau lineage.
- Menyekat setiap pengguna hiliran bagi kegagalan yang terhad kepada satu set data atau sekatan sahaja.
- Menulis ganti sejarah semasa pembaikan tanpa kelompok backfill, penyelarasan, atau kawalan penyahduplikasian.
- Melaporkan satu skor tunggal yang tidak memberitahu pengguna tentang dimensi mana yang tidak tersedia.
Soalan susulan
Bagaimana jika tugas huluan berjaya tetapi tiada data baharu yang tiba?
Semak masa ketibaan dan masa perniagaan secara berasingan, kemudian bandingkan sekatan dipercayai yang terakhir dengan kekerapan kemas kini yang dijangkakan. Tugas yang berjaya hanya membuktikan pelaksanaan, bukannya pematuhan SLA; had masa yang terlampaui harus mencetuskan insiden kualiti.
Bagaimanakah anda mengendalikan positif palsu (false positives) dalam peraturan kualiti?
Simpan rekod pemerhatian, ambang, dan versi peraturan; perhatikan garis dasar dalam mod bayangan (shadow mode) sebelum menguatkuasakannya. Gunakan ambang bertingkat dan nisbah anomali, rekodkan impak pengguna, dan semak perubahan daripada melumpuhkan amaran secara senyap.
Patutkah setiap kegagalan menyekat semua sistem hiliran?
Skopkan respons mengikut lineage dan penggunaan. Kegagalan yang boleh mencemarkan settlement atau model boleh menyekat penerbitan yang berkaitan, manakala set data penerokaan yang bebas boleh menggunakan versi terdahulu yang disertakan amaran. Kedua-dua skop dan syarat pelepasan mestilah boleh diaudit.
Bagaimanakah anda membuktikan pemulihan tidak kehilangan baris data?
Selaraskan kelompok, sekatan, kiraan input dan output, data ditolak, rekod lewat, dan penggunaan hiliran, kemudian lakukan pensampelan set kunci utama. Kelompok pembaikan mestilah boleh dimainkan semula (replayable) dan boleh dikesan, serta pelaksanaan berulang harus menghasilkan keputusan yang sama.