1. Perintah dan konteks
Sebuah data lake menerima file object-storage setiap hari, menulisnya sebagai Parquet, dan melakukan commit snapshot tabel untuk dasbor dan model. Tim khawatir tentang transfer yang terpotong, objek yang diganti, metadata yang tidak lagi cocok dengan konten, dan penulisan duplikat setelah percobaan ulang (retry). Rancang pemeriksaan yang menemukan batas kegagalan alih-alih hanya membandingkan satu jumlah baris akhir.
2. Apa yang sedang diuji oleh pewawancara
- Memisahkan integritas transport, kerusakan file, konsistensi tabel, dan kebenaran bisnis.
- Menjelaskan bahwa checksum mendeteksi perubahan byte yang tidak disengaja tetapi tidak membuktikan kebenaran semantik atau menghentikan penulisan ulang yang berbahaya secara mandiri.
- Membedakan pemeriksaan write-time, read-time, dan background, beserta biaya dan cakupannya.
- Menyediakan alur kerja peringatan, perbaikan, dan audit yang dapat diisolasi dan diulang kembali (replayable).
3. Pertanyaan untuk diklarifikasi terlebih dahulu
- Apakah kita mencegah kesalahan transfer, mendeteksi kerusakan senyap (silent corruption), atau membuat bukti kepatuhan? Setiap tujuan mengubah algoritma dan retensi.
- Apakah file bersifat immutable? Jika penggantian langsung (in-place replacement) diizinkan, versi objek atau digest konten harus menjadi bagian dari snapshot tabel.
- Berapa batas toleransi keterlambatan deteksi dan tingkat positif palsu? Pemeriksaan real-time dan pemindaian penuh harian memiliki anggaran biaya yang berbeda.
- Apakah ada beberapa format, penyimpanan, atau salinan lintas wilayah? Setiap batasan memerlukan verifikasi baru.
4. Kerangka jawaban tiga puluh detik
“Saya akan menggunakan empat lapisan: memverifikasi checksum objek selama upload, memverifikasi CRC halaman Parquet selama read, memverifikasi manifes file dan metadata saat melakukan commit snapshot, dan merekonsiliasi jumlah baris, rentang partisi, serta metrik penting di lapisan bisnis. Simpan algoritma, digest, versi objek, ID job, dan timestamp untuk setiap pemeriksaan. Karantina file yang gagal dan bangun kembali dari sumber upstream atau replika tepercaya. Gabungkan pengambilan sampel berbasis risiko dengan pemindaian penuh, dan kelompokkan peringatan berdasarkan dataset dan radius dampak (blast radius). Terakhir, tulis hasilnya ke tabel yang dapat diaudit alih-alih membiarkan kegagalan hanya ada di log.”
5. Penalaran langkah demi langkah
Pertama, lindungi transfer. Produsen menghitung digest sebelum upload dan layanan penyimpanan memvalidasinya; ketidakcocokan akan menolak objek dan memicu percobaan ulang. Amazon S3 mendukung checksum untuk upload single-part dan multipart serta memungkinkan klien meminta checksum selama download. ETag multipart tidak boleh diperlakukan sebagai MD5 dari keseluruhan objek.
Kedua, lindungi file. Parquet dapat memeriksa checksum setiap halaman data dengan CRC32, memungkinkan pembaca menemukan kerusakan sebelum dekompresi. Checksum halaman mempersempit area yang rusak tetapi tidak menegakkan aturan bisnis, sehingga manifes juga harus menyimpan path, ukuran, versi format, dan digest konten.
Ketiga, lindungi snapshot. Pada saat commit, buat manifes file yang immutable yang berisi versi objek atau digest, partisi, jumlah baris, dan ID job penulis. Tolak snapshot jika file hilang, terduplikasi, atau memiliki digest berbeda; jika tidak, file yang rusak dapat masuk ke pembacaan downstream.
Keempat, rekonsiliasi sinyal bisnis. Untuk partisi penting, hitung jumlah baris, rasio nilai null, total nilai/jumlah, dan hitungan distinct-key, lalu bandingkan dengan buku besar upstream atau versi sebelumnya. Metrik yang sama tidak membuktikan konten yang sama, sehingga rekonsiliasi merupakan sinyal independen di luar checksum.
Kelima, patroli dan perbaikan. Verifikasi data panas saat dibaca dan ambil sampel data dingin berdasarkan risiko; jalankan pemeriksaan penuh pada dataset bernilai tinggi atau yang diatur regulasi. Amazon S3 Batch Operations dapat menghasilkan laporan checksum objek lengkap atau komposit secara asinkron untuk kumpulan objek besar dalam penyimpanan. Karantina anomali beserta digest asli, waktu deteksi, dan referensi snapshot, bangun kembali dari replika tepercaya, dan lakukan commit kembali hanya setelah verifikasi.
6. Contoh jawaban berkualitas tinggi
“Saya tidak akan memperlakukan checksum sebagai keseluruhan rencana kualitas data. Lapisan upload memverifikasi digest transport, pembaca Parquet mengaktifkan CRC halaman, commit snapshot menyimpan manifes immutable dengan versi objek dan ID penulis, dan lapisan bisnis merekonsiliasi jumlah, kunci, dan total nilai untuk partisi penting. Setiap pemeriksaan mencatat algoritma, digest, dan waktunya. Kegagalan saat pembacaan atau patroli akan mengarantina file dan mencegah snapshot baru mereferensikannya. Saya akan memverifikasi data panas secara sinkron, mencakup data biasa dengan pengambilan sampel berbasis risiko, dan memindai data yang diatur regulasi secara penuh sesuai jadwal. Perbaikan dibangun kembali dari replika tepercaya dan mempertahankan bukti kegagalan asli. Lapisan-lapisan ini membedakan kegagalan transfer, penyimpanan, snapshot, dan logika bisnis sekaligus memperjelas biaya dan titik butanya.”
7. Kesalahan umum
- Kesalahan → Hanya membandingkan total baris → penggantian atau duplikasi baris masih bisa lolos → tambahkan digest objek, pemeriksaan distinct-key, dan rekonsiliasi penting.
- Kesalahan → Memperlakukan ETag multipart sebagai MD5 file → semantik algoritma tidak berlaku → simpan tipe checksum yang dideklarasikan dan versi objek.
- Kesalahan → Melakukan pemeriksaan kuat penuh pada setiap pembacaan → latensi dan biaya menjadi tidak terbatas → periksa data panas secara sinkron dan patroli data dingin berdasarkan risiko.
- Kesalahan → Menjalankan ulang seluruh pipeline setelah satu file rusak → file baik yang sudah dikonfirmasi dapat tertulis dua kali → karantina, temukan berdasarkan ID job, dan bangun kembali hanya file yang terpengaruh.
- Kesalahan → Menggunakan checksum sebagai bukti kebenaran bisnis → digest hanya membuktikan bahwa byte berubah atau tidak berubah → pertahankan aturan kualitas bisnis yang independen.
8. Pertanyaan lanjutan
Bagaimana jika penyerang mengganti file dan juga memperbarui digest-nya?
Checksum biasa menangani kerusakan yang tidak disengaja. Tambahkan tanda tangan terproteksi, kontrol akses, penguncian versi objek, dan rantai audit. Simpan digest tepercaya di penyimpanan metadata yang terpisah dari izin penulisan dan catat siapa yang menyetujui versi baru.
Anda hanya memiliki waktu satu jam per hari untuk pemindaian penuh. Bagaimana Anda mengalokasikannya?
Beri skor partisi berdasarkan nilai data, perubahan terbaru, riwayat kegagalan, dan jalur replikasi. Pindai yang paling berisiko terlebih dahulu, dan tutupi sisanya dengan pemeriksaan read-time, pengambilan sampel, dan rolling window. Laporkan cakupan dan jendela yang belum diverifikasi alih-alih mengklaim bahwa seluruh lake telah terverifikasi.
Bagaimana Anda mencegah job perbaikan menduplikasi data?
Gunakan ID file asli, snapshot target, dan kunci penulisan idempoten. Sebelum commit, periksa apakah manifes sudah berisi digest konten yang sama, lalu perbarui pointer snapshot secara atomik. Percobaan ulang hanya membangun kembali file yang gagal dan tidak pernah menambahkan file yang sudah dikonfirmasi.