Temu duga kejuruteraan data: menggunakan deletion vector Iceberg secara selamat

Kehendak soalan dan skop

Jadual Apache Iceberg menyimpan rekod pengguna dan mesti menyokong pemadaman GDPR serta pembetulan yang kerap. Pasukan merancang untuk menaik taraf daripada v2 kepada v3 dan sedang mempertimbangkan deletion vector. Terangkan pertukaran kompromi (trade-offs) antara ketiga-tiga format pemadaman peringkat baris dan cara anda memastikan pembaca lama, writer serentak, rollback dan pemadatan (compaction) kekal selamat.

Soalan ini menguji protokol baca/tulis format jadual, bukan sekadar suis fungsi (feature toggle). Spesifikasi Iceberg mentakrifkan deletion vector (DV) sebagai bitmap kedudukan untuk satu fail data yang dirujuk; skop, metadata dan kewajipan penyelenggaraannya berbeza daripada fail equality delete dan position delete.

Perkara yang dinilai oleh penemu duga

• Sama ada anda membezakan pemadaman berasaskan nilai, kedudukan fail dan bitmap.
• Sama ada anda mengetahui bahawa deletion vector ialah keupayaan Iceberg v3 dan tidak disokong secara baharu dalam v2.
• Sama ada anda boleh menerangkan syarat laluan fail, partisi dan nombor jujukan untuk bacaan snapshot.
• Sama ada anda mengambil kira maksimum satu DV bagi setiap fail data dan penggabungan position delete yang lebih lama.
• Sama ada anda menghubungkan pilihan format dengan amplifikasi bacaan, amplifikasi penulisan, ketumpatan pemadaman, keserasian dan bajet penyelenggaraan.
• Sama ada anda mereka bentuk kebolehcerapan, latihan rollback dan laluan selamat untuk pembaca lama.

Penjelasan yang perlu ditanya terlebih dahulu

Sahkan:

1. Adakah jadual tersebut Iceberg v2 atau v3, dan versi manakah bagi setiap reader dan writer yang digunakan?
2. Adakah permintaan pemadaman mengandungi nilai kunci perniagaan, atau adakah ia sudah mengenal pasti fail data dan kedudukan baris?
3. Apakah ketumpatan pemadaman, kadar kemas kini, sasaran kependaman kueri dan bajet pemadatan?
4. Adakah enjin v2 baca sahaja masih wujud, dan adakah time travel serta rollback snapshot diperlukan?
5. Adakah pemadaman mesti disalurkan ke aliran CDC hiliran, atau adakah ketiadaan paparan pada snapshot semasa sudah mencukupi?

Sekiranya butiran tiada, anggap kebanyakan reader menyokong v3, sebilangan kecil reader v2 masih kekal, dan commit yang berjaya mesti menjadikan pemadaman kelihatan dalam snapshot yang di-commit.

Kerangka jawapan tiga puluh saat

Saya akan memilih berdasarkan semantik: equality delete memadankan nilai lajur, position delete mengenal pasti fail dan kedudukan baris serta boleh menyediakan keserasian v2, dan jadual v3 boleh menyatukan position delete yang kerap untuk satu fail data ke dalam deletion vector. Reader mesti mengesahkan fail yang dirujuk, partisi dan skop nombor jujukan berbanding hanya melihat pada bitmap.

Writer mesti mengekalkan maksimum satu DV bagi setiap fail data dalam satu snapshot dan menggabungkan position delete sedia ada ke dalamnya. Commit menggunakan semakan keserentakan snapshot Iceberg. Oleh kerana reader v2 tidak dapat mentafsir DV, saya akan membina matriks keupayaan, perbandingan bacaan dwi-arah dan pelan rollback sebelum membenarkan penulisan. Ujian penerimaan merangkumi keterlihatan pemadaman, snapshot lama, konflik, pemadatan dan prestasi.

Analisis mendalam langkah demi langkah

1. Takrifkan semantik setiap format

Equality delete memadankan baris dalam mana-mana fail data yang berkenaan mengikut satu atau lebih nilai lajur, seperti id = 5. Position delete mengenal pasti laluan fail dan kedudukan baris berasaskan sifar. Deletion vector menyimpan bitmap kedudukan untuk satu fail data yang dirujuk; bit yang ditetapkan bermakna baris tersebut telah dipadamkan.

Ini bukan sekadar tahap mampatan. Equality delete sesuai untuk peristiwa berasaskan kunci tetapi memerlukan pemadanan predikat semasa imbasan. Position delete adalah tepat dan serasi dengan v2 tetapi boleh mengumpulkan banyak fail. DV menyatukan banyak kedudukan untuk satu fail data ke dalam objek binari yang boleh dialamatkan secara terus.

2. Mengendalikan versi dan keupayaan reader

Iceberg memperkenalkan pemadaman peringkat baris selepas v1, manakala deletion vector ditambah dalam v3. Jadual v3 tidak boleh menambah fail position delete baharu, tetapi position delete sedia ada daripada jadual v2 yang dinaik taraf kekal sah dan mesti digabungkan apabila DV dicipta.

Oleh itu, penaiktarafan katalog sahaja tidak mencukupi. Buat inventori sama ada setiap reader boleh menghuraikan metadata v3, blob Puffin deletion-vector-v1 dan manifes pemadaman. Reader yang tidak disokong memerlukan snapshot yang serasi atau migrasi yang telah selesai; ia tidak boleh dijangka mengabaikan DV yang baru ditulis secara senyap.

3. Menghormati skop bacaan snapshot

Reader menggunakan DV pada fail data hanya apabila laluan fail data sama dengan referenced_data_file, nombor jujukan fail data adalah kurang daripada atau sama dengan nombor jujukan DV, serta spesifikasi dan nilai partisi sepadan. Memadankan laluan sahaja boleh menyebabkan pemadaman dikenakan pada fail yang telah ditulis semula; mengabaikan nombor jujukan akan merosakkan semantik susunan.

Metadata pemadaman juga merekodkan fail yang mengandungi blob, ofset blob dan panjangnya. Reader mesti mencari blob melalui metadata snapshot, bukan menganggap fail storan objek dengan nama yang biasa dikenali sebagai berwibawa.

4. Mereka bentuk penggabungan writer dan commit serentak

Satu snapshot membenarkan maksimum satu DV untuk fail data. Semasa menambah pemadaman, writer membaca status pemadaman semasa, menggabungkan kedudukan baharu dengan DV lama dan fail position-delete, serta menulis DV pengganti. Jika fail data dialih keluar, entri DV yang berkenaan mesti dialih keluar daripada manifes pemadaman.

Commit masih menggunakan keserentakan optimistik snapshot Iceberg. Percubaan semula akibat konflik mesti membaca semula metadata semasa dan manifes pemadaman; ia tidak boleh menggunakan semula bitmap yang dijana semasa percubaan pertama. Rekodkan bilangan percubaan semula, punca konflik dan id snapshot akhir.

5. Mengimbangi amplifikasi bacaan dan penulisan

Bagi pemadaman yang berselerak dan teragih, equality delete mengelakkan keperluan mencari fail asal tetapi menambah kerja pemadanan semasa imbasan. Bagi pemadaman kerap yang tertumpu pada beberapa fail, DV boleh mengurangkan pengurusan fail position-delete dan kerja penggabungan. Bagi pemadaman yang luas atau fail yang sudah perlu ditulis semula, menulis semula data dan membersihkan fail pemadaman mungkin lebih menjimatkan.

Jangan mendakwa bahawa DV sentiasa lebih pantas. Bandingkan bait yang diimbas, bilangan fail pemadaman, saiz bitmap, masa membaca manifes, CPU pemadatan dan kependaman hujung ke hujung pada beberapa tahap ketumpatan pemadaman.

6. Merancang penyelenggaraan, rollback dan bukti pematuhan

Penyelenggaraan harus menggabungkan fail pemadaman lama, menulis semula fail data dengan ketumpatan pemadaman yang tinggi, dan membuang blob yang tidak dirujuk dalam tempoh masa yang selamat. Peraturan pengekalan untuk time travel mesti dipatuhi, jika tidak, snapshot sejarah tidak boleh dibaca. Untuk GDPR, buktikan bahawa baris sasaran tiada dalam snapshot sah semasa dan salinan hiliran.

Latihan rollback harus merangkumi rollback selepas commit DV, ketersediaan berterusan fail Puffin-nya, aplikasi position delete yang lebih lama, dan jaminan pemadaman dalam snapshot baharu. Simpan id permintaan, id snapshot yang di-commit dan hasil pengesahan dalam rekod audit tanpa memasukkan data peribadi ke dalam log.

7. Mewujudkan sekatan keserasian dan kebolehcerapan

Sebelum pelepasan, bina matriks untuk reader v2, reader v3, tugas kelompok (batch jobs), reader penstriman dan alat penyelenggaraan. Uji kelakuan equality, position dan DV untuk setiap satu. Jejaki kegagalan penggunaan DV, fail data yang tidak sepadan, pertumbuhan manifes pemadaman, percubaan semula konflik, kegagalan snapshot lama dan tunggakan pemadatan.

Semasa pelancaran, bandingkan hasil daripada reader lama dan baharu pada snapshot yang sama: jumlah baris, set kunci dan nilai sampel. Jika reader lama tidak dapat mentafsir pemadaman v3, hentikan penulisan DV atau beralih kepada format yang serasi dan bukannya meluaskan radius impak masalah.

Contoh jawapan berkualiti tinggi

Saya akan bermula dengan semantik pemadaman dan matriks reader. Pemadaman berasaskan kunci menggunakan equality delete. Jika permintaan sudah mengenal pasti fail data dan kedudukan baris serta keserasian v2 diperlukan, position delete adalah wajar. Sebaik sahaja jadual menjadi v3 dan pemadaman tertumpu dalam satu fail data, saya akan menyatukan kedudukan tersebut ke dalam deletion vector. DV ialah bitmap bagi setiap fail, dengan maksimum satu DV untuk fail data tersebut dalam satu snapshot, dan mencipta yang baharu mesti menggabungkan position delete sedia ada.

Reader tidak boleh bergantung pada laluan fail sahaja. Ia mesti mengesahkan referenced_data_file, spesifikasi dan nilai partisi, serta memastikan nombor jujukan fail data tidak lebih besar daripada nombor jujukan DV; ofset dan panjang blob mesti diperoleh daripada manifes pemadaman. Writer menggunakan keserentakan optimistik snapshot, membaca semula metadata semasa sekiranya berlaku konflik, dan tidak sekali-kali mencuba semula dengan bitmap lapuk.

Sebelum migrasi, saya akan mengesahkan sokongan v3, Puffin dan DV dalam setiap reader dan menyediakan suis pemati (kill switch) untuk penulisan DV. Penerimaan merangkumi keterlihatan snapshot semasa, time travel, pemadaman serentak, rollback, pemadatan, perbandingan reader lama dan bukti pematuhan. Prestasi membandingkan bait yang diimbas, masa manifes, saiz DV, CPU pemadatan dan kependaman hujung ke hujung. Pada ketumpatan pemadaman yang tinggi, menulis semula fail data mungkin lebih baik daripada mengumpulkan lebih banyak DV.

Kesilapan lazim

• Menganggap DV sebagai equality delete yang dimampatkan dan mengabaikan semantik pemadanan.
• Mendakwa bahawa Iceberg v2 boleh menulis deletion vector.
• Menggunakan DV mengikut laluan fail sahaja, tanpa semakan partisi dan nombor jujukan.
• Mengekalkan berbilang DV untuk satu fail data atau gagal menggabungkan position delete yang lebih lama.
• Menaik taraf katalog tanpa menguji setiap reader dan alat penyelenggaraan.
• Menggunakan satu larian pemadatan sebagai jawapan universal tanpa membandingkan amplifikasi bacaan dan penulisan.
• Membersihkan manifes pemadaman dengan cara yang merosakkan snapshot time-travel yang dikekalkan.
• Memasukkan data peribadi ke dalam log dan menganggapnya sebagai bukti pemadaman.

Soalan susulan dan jawapan

Soalan susulan 1: Mengapa tidak membenarkan reader v2 mengabaikan DV?

Mengabaikan metadata pemadaman boleh mengembalikan baris yang telah dipadamkan, menyebabkan kegagalan ketepatan secara senyap (silent correctness failure). Lengkapkan matriks keupayaan dan perbandingan hasil terlebih dahulu, kemudian pilih migrasi, penulisan yang serasi atau jeda penulisan DV.

Soalan susulan 2: Bilakah anda patut menulis semula fail yang pemadamannya terus meningkat?

Tetapkan ambang menggunakan ketumpatan pemadaman, saiz bitmap, CPU imbasan, kependaman kueri dan bajet pemadatan. Di atas ambang tersebut, tulis semula fail data, alih keluar DV yang berkenaan dalam snapshot baharu dan sahkan dasar pengekalan time-travel.

Soalan susulan 3: Apakah perkara yang paling mudah terlepas pandang semasa percubaan semula konflik?

Membaca semula manifes pemadaman terkini dan nombor jujukan data. Setiap percubaan semula mesti digabungkan dengan metadata jadual semasa serta merekodkan konflik dan id snapshot akhir.

Soalan susulan 4: Bagaimanakah anda membuktikan pemadaman peraturan (regulatory deletion)?

Simpan skop permintaan, id snapshot yang di-commit, hasil kueri snapshot semasa, semakan salinan hiliran dan status penyelenggaraan. Nyatakan tempoh pengekalan time-travel secara jelas dan jauhkan data peribadi daripada log.

Soalan susulan 5: Bilakah equality delete lebih diutamakan?

Apabila peristiwa hanya mengandungi kunci perniagaan, fail kerap ditulis semula atau satu predikat mesti merangkumi banyak fail, equality delete adalah lebih terus. Namun begitu, ukur kos pemadanan imbasan dan tetapkan dasar penulisan semula.