Wawancara data engineering: Bagaimana silsilah baris (row lineage) Iceberg v3 mempertahankan identitas baris?

Perintah dan cakupan

Tabel peristiwa Iceberg v3 harus mendukung CDC, komputasi ulang, dan audit lintas-snapshot. Tim menginginkan identitas baris yang dapat dilacak dan commit yang terakhir memperbarui setiap baris. Jelaskan bidang-bidang silsilah baris, waktu pewarisan, percobaan ulang commit, batasan equality-delete, dan verifikasi.

Apa yang sedang diuji oleh pewawancara

• Apakah Anda memahami pewarisan _row_id dan _last_updated_sequence_number alih-alih mengarang nilai pada saat penulisan.
• Apakah Anda dapat menghubungkan first-row-id, next-row-id, dan manifes.
• Apakah Anda menangani percobaan ulang optimistic-commit, penulis bersamaan (concurrent writers), dan pembaca lama.
• Apakah Anda memisahkan silsilah baris, kunci bisnis, equality deletes, dan pembersihan fisik.

Pertanyaan klarifikasi yang perlu diajukan

1. Apakah kita memerlukan identitas baris fisik, identitas entitas bisnis, atau keduanya?
2. Apakah setiap pembaca mendukung Iceberg v3, dan apa fallback untuk engine lama?
3. Apakah pembaruan bersifat copy-on-write, merge-on-read, atau equality deletes?
4. Apakah audit lintas snapshot diperlukan, atau hanya versi tabel saat ini?

Kerangka jawaban 30 detik

Iceberg v3 menggunakan _row_id untuk identitas baris tabel dan _last_updated_sequence_number untuk commit pembaruan terakhir. Pembaca mewarisinya dari first-row-id file data, posisi baris, dan nomor urut manifes. Penulis dapat memancarkan bidang null sebelum commit, sehingga percobaan ulang harus membaca ulang metadata dan menetapkan first-row-id baru. Silsilah baris bukanlah kunci bisnis, dan equality deletes tidak mempertahankan ID baris yang lama. Buat matriks kemampuan v2/v3, lalu uji snapshot, konflik, dan percobaan ulang.

Pembahasan mendalam langkah demi langkah

1. Memisahkan identitas

Kunci bisnis menyatakan entitas apa yang diwakili oleh sebuah rekaman; _row_id mengidentifikasi baris dalam tabel ini. Jika sebuah entitas dihapus dan ditulis kembali, kunci bisnisnya dapat berulang sementara silsilah barisnya tidak boleh diperlakukan sebagai ID entitas permanen. Pengauditan harus mempertahankan kunci bisnis, ID snapshot, dan ID baris secara bersamaan.

2. Memahami pewarisan bidang

_row_id dan _last_updated_sequence_number baris baru dapat bernilai null dalam file data. Saat dibaca, ID baris diturunkan dari first-row-id file ditambah posisi baris, sedangkan urutan pembaruan berasal dari entri manifes. Hal ini memungkinkan penulis menghindari penulisan ulang file data sebelum commit berhasil.

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

3. Menangani percobaan ulang commit

Setelah konflik optimis, next-row-id tabel mungkin telah berubah. Percobaan ulang harus membaca ulang metadata saat ini, mengalokasikan first-row-id baru, dan membangun kembali daftar manifes; percobaan ulang tidak dapat menggunakan kembali rentang dari percobaan pertama. Catat percobaan, alasan konflik, dan ID snapshot akhir.

4. Batasan equality-delete

Engine equality-delete umumnya menulis perubahan tanpa membaca baris data lama, sehingga tidak dapat memberikan ID asli dari baris yang digantikan. Spesifikasi memperlakukan pembaruan semacam itu sebagai penghapusan baris lama dan penambahan baris baru yang unik. Pertahankan kunci bisnis dan peristiwa perubahan secara terpisah jika identitas entitas penting.

5. Kompatibilitas dan pembacaan

Silsilah baris adalah kemampuan v3, dan pembaca lama mungkin tidak memahami bidang cadangannya. Sebelum meningkatkan versi, buat matriks engine dan verifikasi apakah pembaca lama melihat nilai null, mengabaikan bidang, atau mengalami kegagalan. Ekspor tidak boleh bergantung pada setiap pembaca yang menurunkan ID baris; layanan yang sadar-v3 dapat mematerialisasi bidang audit terlebih dahulu.

6. Verifikasi, rollback, dan pembersihan

Uji penulisan tunggal, commit bersamaan, percobaan ulang konflik, pembacaan snapshot, hapus-dan-tulis-ulang, serta pemadatan (compaction). Verifikasi keunikan ID baris di setiap snapshot, tidak adanya penggunaan kembali rentang yang usang, dan keselarasan antara nomor urut dan snapshot akhir. Rollback mengubah referensi snapshot daripada menulis ulang ID historis; pembersihan fisik tetap menjadi bagian dari kedaluwarsa snapshot dan pembersihan yatim piatu (orphan cleanup).

Model jawaban berkualitas tinggi

Saya akan memisahkan kunci bisnis dari silsilah baris Iceberg. Pada v3, _row_id dan _last_updated_sequence_number menyediakan identitas baris tabel dan urutan commit, yang diwarisi dari first-row-id, posisi baris, dan nomor urut manifes pada saat pembacaan. Penulis membiarkan bidang bernilai null sebelum commit; percobaan ulang saat konflik membaca ulang metadata dan mengalokasikan rentang baru alih-alih menggunakan kembali manifes lama. Equality deletes tidak menjamin ID baris lama, sehingga data audit juga menyimpan kunci bisnis, ID snapshot, dan peristiwa perubahan. Sebelum peluncuran, uji pembaca v2/v3, konflik, pembacaan snapshot, pemadatan, dan pembersihan, dengan rollback terbatas pada pengalihan referensi snapshot.

Kesalahan umum

• Memperlakukan ID baris sebagai kunci bisnis → semantik hapus-dan-tulis-ulang rusak → pertahankan kedua identitas.
• Mengalokasikan ID baris permanen saat menulis file → percobaan ulang dapat menduplikasi atau membuang rentang → andalkan pewarisan saat commit.
• Menggunakan kembali manifes yang berkonflik → manifes tersebut berisi next-row-id yang usang → baca ulang metadata pada setiap percobaan ulang.
• Menganggap equality deletes mempertahankan ID baris → spesifikasi tidak menjaminnya → lacak entitas dengan peristiwa bisnis.
• Hanya memvalidasi kueri saat ini → snapshot dan pembaca lama tetap berisiko → uji perilaku dan kemampuan lintas-snapshot.

Pertanyaan lanjutan dan tanggapan

Mengapa tidak mengganti _row_id dengan kunci bisnis?

Kunci bisnis dapat berulang, berubah, atau tidak unik di seluruh tabel. Silsilah baris adalah identitas baris tabel; keduanya menjawab pertanyaan audit yang berbeda dan keduanya harus dipertahankan.

Bisakah percobaan ulang konflik meninggalkan celah pada ID baris?

Rentang yang tidak terpakai mungkin ada, tergantung pada implementasinya. Aturan keselamatannya adalah jangan pernah menggunakan kembali ID yang telah diekspos oleh snapshot yang berhasil dan menjaga ID tetap unik pada snapshot akhir.

Apakah pemadatan (compaction) mengubah ID baris?

Implementasi yang benar mempertahankan identitas melalui pewarisan silsilah. Verifikasi pemetaan audit sebelum dan sesudah pemadatan untuk semantik snapshot yang sama; jalur file saja tidak cukup.