Temuduga kejuruteraan data: Bagaimanakah salasilah baris (row lineage) Iceberg v3 mengekalkan identiti baris?

Gesaan dan skop

Jadual peristiwa Iceberg v3 mesti menyokong CDC, pengiraan semula, dan pengauditan rentas-snapshot. Pasukan inginkan identiti baris yang boleh dikesan dan commit yang terakhir mengemas kini setiap baris. Terangkan medan salasilah baris, masa pewarisan, percubaan semula commit, had equality-delete, dan pengesahan.

Perkara yang diuji oleh penemu duga

• Sama ada anda memahami pewarisan _row_id dan _last_updated_sequence_number dan bukannya mencipta nilai semasa waktu penulisan.
• Sama ada anda boleh menghubungkan first-row-id, next-row-id, dan manifes.
• Sama ada anda mengendalikan percubaan semula commit optimistik, penulis serentak (concurrent writers), dan pembaca lama.
• Sama ada anda memisahkan salasilah baris, kunci perniagaan, equality deletes, dan pembersihan fizikal.

Soalan penjelasan untuk ditanya

1. Adakah kita memerlukan identiti baris fizikal, identiti entiti perniagaan, atau kedua-duanya?
2. Adakah setiap pembaca menyokong Iceberg v3, dan apakah kaedah sandaran (fallback) untuk enjin lama?
3. Adakah kemas kini berbentuk copy-on-write, merge-on-read, atau equality deletes?
4. Adakah pengauditan merentasi snapshot diperlukan, atau hanya versi jadual semasa?

Rangka jawapan 30 saat

Iceberg v3 menggunakan _row_id untuk identiti baris jadual dan _last_updated_sequence_number untuk commit kemas kini terakhir. Pembaca mewarisinya daripada first-row-id fail data, kedudukan baris, dan nombor jujukan manifes. Penulis boleh mengeluarkan medan null sebelum commit, jadi percubaan semula mesti membaca semula metadata dan memperuntukkan first-row-id baharu. Salasilah baris bukan kunci perniagaan, dan equality deletes tidak mengekalkan ID baris lama. Wujudkan matriks keupayaan v2/v3, kemudian uji snapshot, konflik, dan percubaan semula.

Huraian mendalam langkah demi langkah

1. Asingkan identiti

Kunci perniagaan menyatakan entiti yang diwakili oleh sesuatu rekod; _row_id mengenal pasti baris dalam jadual ini. Jika entiti dipadam dan ditulis semula, kunci perniagaannya mungkin berulang manakala salasilah barisnya tidak boleh dianggap sebagai ID entiti kekal. Pengauditan harus mengekalkan kunci perniagaan, ID snapshot, dan ID baris bersama-sama.

2. Fahami pewarisan medan

_row_id dan _last_updated_sequence_number bagi baris baharu mungkin bernilai null dalam fail data. Semasa membaca, ID baris diperoleh daripada first-row-id fail ditambah dengan kedudukan baris, manakala jujukan kemas kini datang daripada entri manifes. Ini membolehkan penulis mengelak daripada menulis semula fail data sebelum commit berjaya.

row_id = data_file.first_row_id + row_position
last_updated = manifest_entry.data_sequence_number

3. Mengendalikan percubaan semula commit

Selepas konflik optimistik, next-row-id jadual mungkin telah berubah. Percubaan semula mesti membaca semula metadata semasa, memperuntukkan first-row-id baharu, dan membina semula senarai manifes; ia tidak boleh menggunakan semula julat daripada percubaan pertama. Rekodkan percubaan, sebab konflik, dan ID snapshot akhir.

4. Sempadan equality-delete

Enjin equality-delete lazimnya menulis perubahan tanpa membaca baris data lama, jadi ia tidak dapat menyediakan ID asal bagi baris yang digantikan. Spesifikasi menganggap kemas kini sedemikian sebagai memadam baris lama dan menambah baris baharu yang unik. Kekalkan kunci perniagaan dan peristiwa perubahan secara berasingan apabila identiti entiti adalah penting.

5. Keserasian dan pembacaan

Salasilah baris ialah keupayaan v3, dan pembaca lama mungkin tidak memahami medan rizabnya. Sebelum menaik taraf, bina matriks enjin dan sahkan sama ada pembaca lama melihat null, mengabaikan medan, atau gagal. Eksport tidak seharusnya bergantung pada setiap pembaca untuk memperoleh ID baris; perkhidmatan yang menyokong v3 boleh mematerialisasikan medan audit terlebih dahulu.

6. Pengesahan, pengunduran (rollback), dan pembersihan

Uji penulisan tunggal, commit serentak, percubaan semula konflik, pembacaan snapshot, padam-dan-tulis-semula, dan pemadatan (compaction). Sahkan keunikan ID baris dalam setiap snapshot, tiada penggunaan semula julat lapuk, dan penjajaran antara nombor jujukan dan snapshot akhir. Rollback menukar rujukan snapshot dan bukannya menulis semula ID sejarah; pembersihan fizikal masih di bawah skop tamat tempoh snapshot dan pembersihan fail yatim (orphan cleanup).

Model jawapan berkualiti tinggi

Saya akan mengekalkan kunci perniagaan berasingan daripada salasilah baris Iceberg. Dalam v3, _row_id dan _last_updated_sequence_number menyediakan identiti baris jadual dan susunan commit, yang diwarisi daripada first-row-id, kedudukan baris, dan nombor jujukan manifes pada masa membaca. Penulis membiarkan medan bernilai null sebelum commit; percubaan semula konflik membaca semula metadata dan memperuntukkan julat baharu dan bukannya menggunakan semula manifes lama. Equality deletes tidak menjamin ID baris lama, jadi data audit juga menyimpan kunci perniagaan, ID snapshot, dan peristiwa perubahan. Sebelum pelancaran, uji pembaca v2/v3, konflik, pembacaan snapshot, pemadatan, dan pembersihan, dengan rollback dihadkan kepada pertukaran rujukan snapshot.

Kesilapan lazim

• Menganggap ID baris sebagai kunci perniagaan → semantik padam-dan-tulis-semula rosak → kekalkan kedua-dua identiti.
• Memperuntukkan ID baris kekal semasa menulis fail → percubaan semula boleh menduplikasi atau membazirkan julat → bergantung pada pewarisan masa commit.
• Menggunakan semula manifes yang berkonflik → ia mengandungi next-row-id lapuk → baca semula metadata pada setiap percubaan semula.
• Menganggap equality deletes mengekalkan ID baris → spesifikasi tidak menjaminnya → jejak entiti dengan peristiwa perniagaan.
• Mengesahkan pertanyaan semasa sahaja → snapshot dan pembaca lama kekal berisiko → uji tingkah laku dan keupayaan rentas-snapshot.

Soalan susulan dan jawapan

Mengapakah tidak menggantikan _row_id dengan kunci perniagaan?

Kunci perniagaan boleh berulang, berubah, atau tidak unik merentas jadual. Salasilah baris ialah identiti baris jadual; kedua-duanya menjawab soalan audit yang berbeza dan kedua-duanya harus dikekalkan.

Bolehkah percubaan semula konflik meninggalkan jurang (gaps) dalam ID baris?

Julat yang tidak digunakan mungkin wujud, bergantung pada pelaksanaan. Peraturan keselamatan adalah jangan sekali-kali menggunakan semula ID yang didedahkan oleh snapshot yang berjaya dan memastikan ID kekal unik dalam snapshot akhir.

Adakah pemadatan (compaction) mengubah ID baris?

Pelaksanaan yang betul mengekalkan identiti melalui pewarisan salasilah. Sahkan pemetaan audit sebelum dan selepas pemadatan untuk semantik snapshot yang sama; laluan fail sahaja tidak mencukupi.