Prompt dan konteks
Sebuah event lake menambahkan miliaran baris setiap hari dan menerima permintaan penghapusan pengguna secara terus-menerus. Tim ingin menggunakan deletion vector Iceberg v3 untuk menghindari penulisan ulang file data pada setiap penghapusan. Jelaskan perbedaannya dengan position delete dan equality delete, serta rancang konsistensi snapshot, kompatibilitas reader, dan pembersihan fisik akhir.
Hal yang dievaluasi oleh pewawancara
- Pemahaman bahwa deletion vector adalah penanda posisi baris logis, bukan penghapusan instan byte pada object storage.
- Membandingkan ketiga representasi penghapusan berdasarkan amplifikasi penulisan, biaya pembacaan, dan batasan cakupan.
- Merancang commit snapshot atomik, penggabungan konkuren, fallback untuk reader lama, dan pemadatan (compaction).
- Menghubungkan bukti privasi dengan kebenaran kueri, pencadangan (backup), dan retensi replikasi.
Pertanyaan klarifikasi
- Apakah setiap writer, katalog, engine kueri, dan SDK mendukung Iceberg v3 dan deletion vector?
- Apakah penghapusan diidentifikasi berdasarkan posisi yang stabil, business key, atau kecocokan di seluruh file?
- Berapa lama penghapusan logis boleh bertahan, dan kapan versi objek, cadangan, serta replika kedaluwarsa?
- Bagaimana engine memuat file penghapusan, dan apakah cache key-nya menyertakan snapshot ID?
- Apakah pemadatan dapat mengalami race condition dengan penulisan streaming, kedaluwarsa snapshot, atau penghapusan privasi?
Jawaban 30 detik
Saya akan memperlakukan deletion vector sebagai lapisan logis di dalam snapshot: setiap file data dapat mereferensikan satu vektor yang menandai posisi baris yang dihapus; operasi baca memfilter baris-baris tersebut, sementara file fisik ditulis ulang kemudian di bawah pemadatan yang terkontrol. Position delete juga mengidentifikasi posisi tetapi umumnya menggunakan file penghapusan terpisah. Equality delete mencocokkan nilai kolom, yang fleksibel tetapi dapat memindai lebih banyak data. Saya akan memverifikasi dukungan v3, menggunakan commit snapshot atomik, menyediakan jalur kompatibilitas reader lama, dan menyelaraskan pemadatan, kedaluwarsa, cadangan, serta replika ke satu SLA penghapusan.
Jawaban mendalam
Langkah 1: Tentukan semantik penghapusan
Deletion vector adalah bitmap atau struktur setara yang terkait dengan file data dan menandai posisi yang dihapus. Ini menyembunyikan baris dari snapshot logis tetapi tidak membuktikan bahwa byte object storage telah dihapus, sehingga penghapusan privasi juga memerlukan penulisan ulang, kedaluwarsa, dan tata kelola pencadangan.
Langkah 2: Bandingkan ketiga representasi
Position delete menyebutkan posisi file dan cocok untuk writer yang sudah mengetahui file dan barisnya. Equality delete mencocokkan nilai kolom dan cocok untuk CDC atau penghapusan berdasarkan business key, tetapi reader mungkin memindai lebih banyak file. Deletion vector memusatkan tanda posisi per file data, mengurangi banyak file penghapusan kecil sekaligus memindahkan biaya pemfilteran dan pemeliharaan vektor ke jalur pembacaan.
Langkah 3: Tetapkan batasan snapshot
Referensi vektor di-commit secara atomik bersama snapshot Iceberg dan mencatat path file data, lokasi vektor, ukuran, checksum, serta versi format. Generator membaca snapshot input yang tetap dan tidak pernah mengubah vektor yang ada secara langsung di tempat (in place). Saat terjadi konflik konkuren, generator menggabungkan dari snapshot terbaru alih-alih menimpa penghapusan lain.
Langkah 4: Rancang jalur pembacaan
Planner membaca manifes dan metadata snapshot, lalu memuat vektor yang berlaku. Jika vektor hilang, rusak, atau tidak didukung, hasil yang aman adalah menolak snapshot atau beralih ke representasi penghapusan tepercaya; memperlakukan kesalahan sebagai "tidak ada penghapusan" akan membocorkan baris data. Cache key mencakup tabel, file data, snapshot ID, dan versi vektor.
Langkah 5: Rencanakan pemadatan dan pembersihan
Ketika kepadatan vektor, amplifikasi pembacaan acak, atau rasio penghapusan melewati ambang batas yang terukur, tulis ulang baris yang tersisa ke dalam file data baru dan hapus file lama serta vektor dalam snapshot baru. Siklus hidup object storage, cadangan, replika, dan kedaluwarsa snapshot harus memenuhi SLA penghapusan yang sama; menghapus pointer katalog bukanlah bukti penghapusan fisik.
Langkah 6: Migrasikan reader lama
Inventarisasi versi format, dukungan file penghapusan, dan perilaku cache dari setiap engine. Reader lama dapat mengonsumsi snapshot kompatibilitas yang diwakili oleh position delete atau equality delete untuk sementara, atau menggunakan materialized view. Jangan memublikasikan snapshot yang mengandung vektor ke reader yang tidak dapat menginterpretasikannya.
Langkah 7: Verifikasi kebenaran dan kepatuhan
Uji penghapusan konkuren dan duplikat, pembaruan setelah penghapusan (update-after-delete), rollback snapshot, vektor rusak, dan pemadatan yang terinterupsi. Untuk setiap snapshot, bandingkan hash hasil dengan dan tanpa pengoptimalan, lakukan pengambilan sampel untuk memastikan baris yang dihapus tidak terlihat, dan catat waktu retensi akhir file data, cadangan, serta replika.
Jawaban model
Pertama, saya akan memastikan bahwa setiap reader dapat mem-parsing Iceberg v3 dan deletion vector. Transaksi penghapusan menetapkan snapshot dasar, membangun vektor posisi baris per file data, dan secara atomik men-commit referensi dengan snapshot baru; konflik akan membaca ulang dan menggabungkan snapshot terbaru. Operasi baca memuat vektor berdasarkan snapshot ID. Vektor yang hilang atau tidak didukung akan menghentikan publikasi atau beralih ke file penghapusan tepercaya, tidak pernah ke vektor kosong. Setelah kepadatan melewati ambang batas yang terukur, pemadatan menulis ulang baris yang tersisa, dan file lama, snapshot, cadangan, serta replika kedaluwarsa di bawah satu SLA penghapusan. Penerimaan mencakup pengujian penghapusan konkuren, vektor rusak, rollback, dan pemulihan yang terinterupsi, membandingkan hash hasil, serta menghasilkan bukti pembersihan fisik.
Kesalahan umum
- Menganggap deletion vector sebagai penghapusan instan pada object storage.
- Menimpa vektor yang ada secara langsung di tempat tanpa kontrol versi dan snapshot.
- Membiarkan reader khusus v2 mengonsumsi snapshot yang mengandung vektor dengan harapan reader tersebut mengabaikannya.
- Menyatakan penghapusan yang patuh hanya setelah menghapus pointer katalog.
- Menjalankan pemadatan tanpa memeriksa snapshot konkuren, sehingga kehilangan data yang ditulis atau dihapus.
Pertanyaan lanjutan dan jawaban
Lanjutan 1: Mengapa tidak selalu menggunakan equality delete?
Metode tersebut mengekspresikan penghapusan business key dengan baik, tetapi operasi baca mungkin harus mencocokkan ke banyak file. Ketika posisi fisik diketahui dan penghapusan sering terjadi, vektor dapat mengurangi overhead file penghapusan. Ukur dukungan reader dan biaya kueri sebelum memilih.
Lanjutan 2: Bisakah vektor yang rusak mengembalikan data yang tidak difilter?
Tidak. Hal itu akan mengekspos baris yang telah dihapus. Validasi checksum dan versi, tolak snapshot atau beralih ke representasi tepercaya, dan kirimkan peringatan (alert) untuk perbaikan.
Lanjutan 3: Bagaimana vektor berinteraksi dengan pembaruan (update)?
Pembaruan umumnya menulis file data baru dan menandai baris lama sebagai dihapus. Commit file baru dan referensi penghapusan dalam satu snapshot agar reader melihat baris lama atau baris baru, tidak pernah keduanya.
Lanjutan 4: Bagaimana cara menetapkan ambang batas pemadatan?
Ukur rasio penghapusan, ukuran vektor, amplifikasi pembacaan acak, latensi pemindaian, dan biaya penyimpanan di bawah beban kerja yang representatif. Jangan memilih ambang batas hanya berdasarkan jumlah file.
Lanjutan 5: Bagaimana Anda membuktikan penghapusan privasi?
Sediakan pemeriksaan ketidakterlihatan tingkat baris, catatan snapshot yang kedaluwarsa, manifes file yang ditulis ulang, hasil penghapusan versi objek, retensi cadangan dan replika, serta pemindaian sampel tanpa kecocokan.