Petunjuk dan konteks
Sebuah tugas lakehouse membaca Parquet dari object storage. Sebagian kecil file mengalami kerusakan setelah replikasi lintas wilayah, tetapi pipeline saat ini hanya mencoba ulang (retry) seluruh file. Rancang rencana CRC tingkat halaman: tentukan byte yang diperiksa, jelaskan batas kompresi, pertahankan kompatibilitas reader, isolasi halaman yang rusak, dan pilih metrik penerimaan. Ini adalah pertanyaan data tentang integritas file columnar.
Hal yang dievaluasi pewawancara
- Membedakan CRC halaman dari pemeriksaan tingkat file dan mengetahui bahwa bidang tersebut bersifat opsional.
- Menyatakan cakupan checksum dan batas kompresi secara tepat.
- Merancang peluncuran ketika reader yang lebih lama mengabaikan bidang CRC.
- Mencegah pembacaan parsial yang senyap (silent partial reads) dan memisahkan isolasi, pemulihan replikasi, dan penulisan ulang.
- Mengukur kebenaran (correctness), waktu lokalisasi, dan overhead CPU/I/O.
Pertanyaan klarifikasi yang perlu diajukan
- Apakah versi writer dan reader target menulis dan memverifikasi CRC halaman?
- Apakah kerusakan disebabkan oleh object storage, replikasi, atau cache lokal?
- Apakah kompresi, enkripsi, atau indeks halaman diaktifkan, dan dapatkah reader menemukan column chunk?
- Apakah setiap baris harus dipulihkan, atau dapatkah partisi dibangun kembali dari data upstream?
- Mungkinkah percobaan ulang terus menyimpan versi objek rusak yang sama ke dalam cache?
Jawaban 30 detik
"Pertama-tama saya akan memverifikasi dukungan CRC halaman terhadap format Parquet dan versi reader yang tepat, mencatat versi file, row group, column chunk, tipe halaman, dan versi objek. Kegagalan verifikasi harus mengarantina objek daripada melewati baris; pemulihan dapat mencoba replika yang cocok atau menulis ulang dari upstream. Reader lama mungkin mengabaikan CRC, sehingga tetap dapat dibaca tetapi tidak dapat mengklaim verifikasi integritas. Saya akan menyuntikkan kerusakan ke dalam halaman data, halaman kamus (dictionary), header, dan ekor replikasi, lalu membandingkan tingkat deteksi, waktu lokalisasi, biaya percobaan ulang, dan kesetaraan hasil."
Jawaban mendalam
Langkah 1: Tetapkan batas format
Header halaman Parquet berisi bidang CRC 32-bit opsional untuk tipe halaman seperti data dan dictionary page. Konfirmasikan bahwa writer mengisinya dan reader memverifikasinya; perubahan konfigurasi hanya pada writer tidak membuat pembacaan downstream menjadi aman.
write page bytes -> compute CRC32 -> persist header and payload
read page -> read header -> verify payload CRC -> decodeSertakan versi objek, row group, column chunk, dan ordinal halaman dalam diagnostik sehingga percobaan ulang dapat membuktikan bahwa ia membaca byte yang sama.
Langkah 2: Tetapkan urutan kompresi dan checksum
Spesifikasi dan implementasi format menentukan byte persis yang dicakup oleh CRC. Pertahankan matriks versi writer/reader dan jangan pernah mengarang checksum di atas nilai logis yang didekodekan. Kegagalan dekompresi dan ketidakcocokan CRC adalah kelas kegagalan yang berbeda dan memerlukan metrik terpisah.
Langkah 3: Isolasi kerusakan dengan aman
Jika terjadi kegagalan, gagalkan pembacaan file dan masukkan objek ke dalam antrean karantina beserta URI, versi, lokasi halaman, dan jenis kesalahan. Jangan abaikan halaman secara diam-diam. Baca replika yang cocok jika tersedia; jika semua salinan gagal, tulis ulang partisi atau putar ulang data upstream daripada mencoba ulang byte yang sama selamanya.
Langkah 4: Tangani reader lama
Reader lama mungkin mengabaikan bidang CRC dan tetap mengembalikan baris, sehingga dekode yang berhasil tidak membuktikan integritas. Selama peluncuran, pertahankan matriks kemampuan reader. Reader yang ketat (strict) memvalidasi beban kerja kritis; reader lama diberi label tidak memiliki verifikasi integritas, dan pemeriksaan sidecar tersampel dapat mengungkap perbedaan sebelum migrasi.
Langkah 5: Hubungkan CRC dengan enkripsi dan indeks halaman
Autentikasi enkripsi, kompresi, dan pengurutan CRC harus mengikuti implementasi target. CRC bukanlah tag autentikasi, dan indeks halaman tidak memvalidasi byte payload. Selesaikan pemeriksaan integritas yang diwajibkan oleh format sebelum mendekode atau memangkas (pruning), sambil tetap mempertahankan koordinat column-chunk untuk diagnosis.
Langkah 6: Bangun pengujian injeksi kerusakan
Balikkan satu bit (bit-flip) pada halaman data, lalu secara terpisah rusak halaman kamus, header halaman, ekor file, dan versi objek yang direplikasi. Cakup halaman terkompresi, halaman yang banyak berisi null, halaman kosong, dan halaman besar. Verifikasi lokasi pada reader yang ketat dan catat perilaku reader lama.
Langkah 7: Tentukan penerimaan yang dapat diulang
Dengan versi objek, konkurensi, dan cold cache yang sama, bandingkan CRC saat aktif dan nonaktif untuk CPU, byte yang dibaca, p95, tingkat deteksi, dan waktu lokalisasi. Hasil untuk input yang utuh harus cocok persis; kerusakan yang disuntikkan harus gagal dan masuk karantina. Buat peringatan untuk kegagalan checksum, percobaan ulang yang berulang, dan tingkat keberhasilan pemulihan.
Jawaban model
"Saya akan mulai dengan format Parquet dan implementasi reader target untuk mengonfirmasi bahwa CRC halaman bersifat opsional, tipe halaman apa saja yang membawanya, dan rentang byte persis yang dicakup. Pembacaan memverifikasi CRC sebelum dekompresi dan decoding; kesalahan dekompresi dan checksum adalah metrik terpisah. Halaman yang buruk akan menggagalkan dan mengarantina file, kemudian pemulihan menggunakan versi objek yang sama dari replika lain atau menulis ulang dari upstream. Sistem tidak boleh melewatkan halaman atau mencoba ulang objek yang buruk tanpa henti.
Reader lama mungkin mengabaikan CRC, jadi saya akan memublikasikan matriks kemampuan dan memigrasikan tugas-tugas kritis ke reader yang ketat. Pengujian byte-flip, header halaman, halaman kamus, dan pemotongan replikasi akan mengukur deteksi, lokalisasi, CPU, byte yang dibaca, tingkat pemulihan, dan hash hasil sebelum memperluas peluncuran."
Kesalahan umum
- Memperlakukan CRC sebagai autentikasi → CRC mendeteksi kerusakan acak, bukan gangguan manipulasi (tampering) → tambahkan enkripsi terautentikasi atau tanda tangan jika diperlukan.
- Hanya mengubah writer → reader downstream mungkin mengabaikan bidang tersebut → uji matriks versi.
- Melewatkan halaman yang rusak → menyebabkan baris hilang secara senyap → gagalkan dan karantina.
- Mencoba ulang satu objek selamanya → memperbesar biaya → kunci versi dan batasi percobaan ulang.
- Hanya menguji kerusakan file utuh → melewatkan batas halaman dan header → suntikkan kerusakan bertingkat.
- Mencampuradukkan kesalahan decode dan checksum → mengaburkan pemulihan → pisahkan metrik dan runbook.
Pertanyaan lanjutan dan jawaban
Pertanyaan lanjutan 1: Apakah CRC mencegah manipulasi berbahaya?
Tidak. CRC mendeteksi kerusakan yang tidak disengaja. Gunakan enkripsi terautentikasi, tanda tangan, atau verifikasi penyimpanan tepercaya untuk ketahanan terhadap manipulasi.
Pertanyaan lanjutan 2: Apakah reader lama merusak kompatibilitas?
Mereka umumnya tetap dapat mendekode format tersebut, tetapi mereka tidak dapat mengklaim bahwa CRC telah diverifikasi. Tugas kritis harus menggunakan reader yang ketat.
Pertanyaan lanjutan 3: Bisakah Anda membaca ulang hanya halaman yang rusak?
Cobalah pembacaan rentang (range read) atau replika yang cocok, tetapi validasi hasil lengkapnya. Jika tidak ada salinan terverifikasi, tulis ulang atau putar ulang data upstream.
Pertanyaan lanjutan 4: Mengapa mencatat versi objek?
Objek dapat tertimpa selama percobaan ulang. Pengidentifikasi versi mengikat kesalahan dan tindakan pemulihan ke satu urutan byte tertentu.
Pertanyaan lanjutan 5: Bagaimana Anda mengontrol overhead?
Lakukan tolok ukur (benchmark) CPU, throughput, dan p95 dengan ukuran halaman dan konkurensi yang realistis, lalu lakukan uji coba canary pada partisi berisiko tinggi sebelum peluncuran secara luas.