Perintah dan cakupan
Sebuah tabel Apache Iceberg menyimpan data pengguna dan harus mendukung penghapusan GDPR serta koreksi yang sering. Tim berencana untuk meningkatkan dari v2 ke v3 dan sedang mempertimbangkan deletion vector. Jelaskan trade-off di antara ketiga format penghapusan tingkat baris dan bagaimana Anda menjaga pembaca lama, writer konkuren, rollback, dan pemadatan (compaction) tetap aman.
Pertanyaan ini menguji protokol baca/tulis format tabel, bukan sekadar tombol fitur. Spesifikasi Iceberg mendefinisikan deletion vector (DV) sebagai bitmap posisi untuk satu file data yang direferensikan; cakupan, metadata, dan kewajiban pemeliharaannya berbeda dari file equality delete dan position delete.
Apa yang dievaluasi oleh pewawancara
- Apakah Anda membedakan penghapusan berbasis nilai, posisi file, dan bitmap.
- Apakah Anda mengetahui bahwa deletion vector adalah kemampuan Iceberg v3 dan tidak baru didukung di v2.
- Apakah Anda dapat menjelaskan kondisi path file, partisi, dan nomor urut untuk pembacaan snapshot.
- Apakah Anda memperhitungkan paling banyak satu DV per file data dan penggabungan position delete yang lebih lama.
- Apakah Anda menghubungkan pilihan format dengan amplifikasi baca, amplifikasi tulis, kepadatan penghapusan, kompatibilitas, dan anggaran pemeliharaan.
- Apakah Anda merancang observabilitas, latihan rollback, dan jalur aman untuk pembaca lama.
Klarifikasi yang perlu ditanyakan terlebih dahulu
Konfirmasikan:
- Apakah tabel berupa Iceberg v2 atau v3, dan versi apa dari setiap reader dan writer yang digunakan?
- Apakah permintaan penghapusan berisi nilai kunci bisnis, atau sudah mengidentifikasi file data dan posisi baris?
- Berapa kepadatan penghapusan, laju pembaruan, target latensi kueri, dan anggaran pemadatan?
- Apakah engine v2 yang hanya-baca masih ada, dan apakah time travel serta rollback snapshot diperlukan?
- Apakah penghapusan harus masuk ke aliran CDC hilir, atau invisibilitas pada snapshot saat ini sudah cukup?
Jika detail tidak ada, asumsikan sebagian besar reader mendukung v3, sebagian kecil populasi reader v2 masih ada, dan commit yang berhasil harus membuat penghapusan terlihat pada snapshot yang di-commit.
Kerangka jawaban tiga puluh detik
Saya akan memilih berdasarkan semantik: equality delete cocok dengan nilai kolom, position delete mengidentifikasi file dan posisi baris serta dapat melayani kompatibilitas v2, dan tabel v3 dapat menggabungkan position delete yang sering untuk satu file data ke dalam deletion vector. Reader harus memvalidasi file yang direferensikan, partisi, dan cakupan nomor urut daripada hanya melihat bitmap.
Writer harus menyimpan paling banyak satu DV per file data dalam sebuah snapshot dan menggabungkan position delete yang ada ke dalamnya. Commit menggunakan pemeriksaan konkurensi snapshot Iceberg. Karena reader v2 tidak dapat menginterpretasikan DV, saya akan membangun matriks kemampuan, perbandingan pembacaan ganda, dan rencana rollback sebelum mengaktifkan penulisan. Uji penerimaan mencakup visibilitas penghapusan, snapshot lama, konflik, pemadatan, dan performa.
Pembahasan mendalam langkah demi langkah
1. Tentukan semantik dari setiap format
Equality delete mencocokkan baris dalam file data apa pun yang berlaku berdasarkan satu atau beberapa nilai kolom, seperti id = 5. Position delete mengidentifikasi path file dan posisi baris berbasis nol. Deletion vector menyimpan bitmap posisi untuk satu file data yang direferensikan; bit yang disetel berarti baris tersebut dihapus.
Ini bukan sekadar tingkat kompresi. Equality delete cocok untuk kejadian berbasis kunci tetapi memerlukan pencocokan predikat selama pemindaian. Position delete presisi dan kompatibel dengan v2 tetapi dapat mengakumulasi banyak file. DV menggabungkan banyak posisi untuk satu file data ke dalam objek biner yang dapat dialamatkan secara langsung.
2. Tangani versi dan kemampuan reader
Iceberg menempatkan penghapusan tingkat baris setelah v1, sementara deletion vector ditambahkan di v3. Tabel v3 tidak boleh menambahkan file position delete baru, tetapi position delete yang sudah ada dari tabel v2 yang ditingkatkan tetap valid dan harus digabungkan saat DV dibuat.
Oleh karena itu, peningkatan katalog saja tidak cukup. Lakukan inventarisasi apakah setiap reader dapat mengurai metadata v3, blob Puffin deletion-vector-v1, dan manifes penghapusan. Reader yang tidak didukung memerlukan snapshot yang kompatibel atau migrasi yang telah selesai; reader tersebut tidak dapat diharapkan untuk mengabaikan DV yang baru ditulis secara diam-diam.
3. Hormati cakupan pembacaan snapshot
Reader menerapkan DV ke file data hanya jika path file data sama dengan referenced_data_file, nomor urut file data kurang dari atau sama dengan nomor urut DV, serta spesifikasi dan nilai partisi cocok. Mencocokkan path saja dapat menerapkan penghapusan ke file yang ditulis ulang; mengabaikan nomor urut akan merusak semantik pengurutan.
Metadata penghapusan juga mencatat file yang memuatnya, offset blob, dan panjangnya. Reader harus menemukan lokasi blob melalui metadata snapshot, bukan memperlakukan file penyimpanan objek dengan nama yang familiar sebagai file otoritatif.
4. Rancang penggabungan writer dan commit bersamaan
Sebuah snapshot mengizinkan paling banyak satu DV untuk sebuah file data. Saat menambahkan penghapusan, writer membaca status penghapusan saat ini, menggabungkan posisi baru dengan DV lama dan file position-delete, lalu menulis DV pengganti. Jika file data dihapus, entri DV yang berlaku harus dihapus dari manifes penghapusan.
Commit tetap menggunakan konkurensi optimis snapshot Iceberg. Percobaan ulang saat konflik harus membaca ulang metadata saat ini dan manifes penghapusan; percobaan ulang tidak dapat menggunakan kembali bitmap yang dihasilkan selama upaya pertama. Catat jumlah percobaan ulang, penyebab konflik, dan id snapshot akhir.
5. Seimbangkan amplifikasi baca dan tulis
Untuk penghapusan yang jarang dan tersebar, equality delete menghindari pencarian file asli tetapi menambah pekerjaan pencocokan selama pemindaian. Untuk penghapusan yang sering dan terkonsentrasi pada beberapa file, DV dapat mengurangi pengelolaan file position-delete dan pekerjaan penggabungan. Untuk penghapusan yang luas atau file yang sudah waktunya ditulis ulang, menulis ulang data dan membersihkan file penghapusan mungkin lebih murah.
Jangan mengklaim bahwa DV selalu lebih cepat. Bandingkan byte yang dipindai, jumlah file penghapusan, ukuran bitmap, waktu baca manifes, CPU pemadatan, dan latensi ujung-ke-ujung pada beberapa tingkat kepadatan penghapusan.
6. Rencanakan pemeliharaan, rollback, dan bukti kepatuhan
Pemeliharaan harus menggabungkan file penghapusan lama, menulis ulang file data dengan kepadatan penghapusan tinggi, dan menghapus blob yang tidak direferensikan dalam jendela waktu yang aman. Aturan retensi untuk time travel harus dipatuhi, jika tidak, snapshot historis tidak dapat dibaca. Untuk GDPR, buktikan bahwa baris target tidak ada pada snapshot valid saat ini dan salinan di hilir.
Latihan rollback harus mencakup rollback setelah commit DV, ketersediaan berkelanjutan dari file Puffin-nya, penerapan position delete yang lebih lama, dan jaminan penghapusan pada snapshot baru. Simpan id permintaan, id snapshot yang di-commit, dan hasil verifikasi dalam catatan audit tanpa memasukkan data pribadi ke dalam log.
7. Tetapkan gerbang kompatibilitas dan observabilitas
Sebelum rilis, buat matriks untuk reader v2, reader v3, batch job, streaming reader, dan alat pemeliharaan. Uji perilaku equality, position, dan DV untuk masing-masing. Lacak kegagalan penerapan DV, file data yang tidak cocok, pertumbuhan manifes penghapusan, percobaan ulang konflik, kegagalan snapshot lama, dan backlog pemadatan.
Selama peluncuran, bandingkan hasil dari reader lama dan baru pada snapshot yang sama: jumlah baris, kumpulan kunci, dan nilai sampel. Jika reader lama tidak dapat menginterpretasikan penghapusan v3, hentikan penulisan DV atau beralih ke format yang kompatibel daripada memperluas dampak masalah.
Contoh jawaban berkualitas tinggi
Saya akan mulai dengan semantik penghapusan dan matriks reader. Penghapusan berbasis kunci menggunakan equality delete. Jika permintaan sudah mengidentifikasi file data dan posisi baris serta kompatibilitas v2 diperlukan, position delete tepat digunakan. Setelah tabel menjadi v3 dan penghapusan terkonsentrasi pada satu file data, saya akan menggabungkan posisi tersebut ke dalam deletion vector. DV adalah bitmap per file, dengan paling banyak satu DV untuk file data tersebut dalam sebuah snapshot, dan membuat yang baru harus menggabungkan position delete yang ada.
Reader tidak dapat hanya mengandalkan path file. Reader harus memvalidasi referenced_data_file, spesifikasi dan nilai partisi, serta bahwa nomor urut file data tidak lebih besar dari nomor urut DV; offset dan panjang blob harus berasal dari manifes penghapusan. Writer menggunakan konkurensi optimis snapshot, membaca ulang metadata saat ini jika terjadi konflik, dan tidak pernah mencoba ulang dengan bitmap yang basi.
Sebelum migrasi, saya akan memverifikasi dukungan v3, Puffin, dan DV di setiap reader dan mempertahankan tombol darurat (kill switch) untuk penulisan DV. Penerimaan mencakup visibilitas snapshot saat ini, time travel, penghapusan bersamaan, rollback, pemadatan, perbandingan reader lama, dan bukti kepatuhan. Performa membandingkan byte yang dipindai, waktu manifes, ukuran DV, CPU pemadatan, dan latensi ujung-ke-ujung. Pada kepadatan penghapusan yang tinggi, menulis ulang file data mungkin lebih baik daripada mengakumulasi lebih banyak DV.
Kesalahan umum
- Memperlakukan DV sebagai equality delete yang dikompresi dan mengabaikan semantik pencocokan.
- Mengklaim bahwa Iceberg v2 dapat menulis deletion vector.
- Menerapkan DV hanya berdasarkan path file, tanpa pemeriksaan partisi dan nomor urut.
- Menyimpan beberapa DV untuk satu file data atau gagal menggabungkan position delete yang lebih lama.
- Meningkatkan katalog tanpa menguji setiap reader dan alat pemeliharaan.
- Menggunakan satu kali eksekusi pemadatan sebagai jawaban universal tanpa membandingkan amplifikasi baca dan tulis.
- Membersihkan manifes penghapusan dengan cara yang merusak snapshot time-travel yang dipertahankan.
- Memasukkan data pribadi ke dalam log dan menyebutnya sebagai bukti penghapusan.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Mengapa tidak membiarkan reader v2 mengabaikan DV?
Mengabaikan metadata penghapusan dapat mengembalikan baris yang sudah dihapus, menciptakan kegagalan kebenaran data yang tidak disadari (silent correctness failure). Selesaikan matriks kemampuan dan perbandingan hasil terlebih dahulu, lalu pilih migrasi, penulisan yang kompatibel, atau jeda pada penulisan DV.
Pertanyaan lanjutan 2: Kapan Anda harus menulis ulang file yang penghapusannya terus meningkat?
Tetapkan ambang batas menggunakan kepadatan penghapusan, ukuran bitmap, CPU pemindaian, latensi kueri, dan anggaran pemadatan. Di atas ambang batas tersebut, tulis ulang file data, hapus DV yang berlaku dalam snapshot baru, dan verifikasi kebijakan retensi time-travel.
Pertanyaan lanjutan 3: Apa yang paling mudah terlewatkan selama percobaan ulang saat konflik?
Membaca ulang manifes penghapusan terbaru dan nomor urut data. Setiap percobaan ulang harus digabungkan dengan metadata tabel saat ini dan mencatat konflik beserta id snapshot akhir.
Pertanyaan lanjutan 4: Bagaimana Anda membuktikan penghapusan regulasi?
Simpan cakupan permintaan, id snapshot yang di-commit, hasil kueri snapshot saat ini, pemeriksaan salinan di hilir, dan status pemeliharaan. Nyatakan periode retensi time-travel secara eksplisit dan jauhkan data pribadi dari log.
Pertanyaan lanjutan 5: Kapan equality delete lebih disukai?
Ketika event hanya berisi kunci bisnis, file sering ditulis ulang, atau satu predikat harus mencakup banyak file, equality delete lebih langsung. Tetap ukur biaya pencocokan pemindaian dan tentukan kebijakan penulisan ulang.