Perintah dan ruang lingkup
Data lake Anda menggunakan tabel Iceberg dan sedang bermigrasi dari 1.10.1 ke 1.10.2. Tabel berisi equality deletes, penghapusan v2, dan writer yang bersamaan, sementara rilis tersebut mencakup perbaikan keamanan. Rancang peningkatan versi, validasi, rollback, dan pembersihan (cleanup).
Apache Iceberg mencatat 1.10.2 dirilis pada 18 Mei 2026, dengan perbaikan untuk pengurutan skema equality-delete, pemuatan snapshot setelah komit, pembersihan file yang tidak aman, peningkatan format secara bersamaan, dan kerentanan dependensi. Wawancara ini menguji kemampuan mengubah catatan rilis menjadi bukti kebenaran data.
Hal yang dievaluasi oleh pewawancara
- Memisahkan spesifikasi tabel, implementasi mesin (engine), Catalog, FileIO, dan dependensi runtime.
- Menjelaskan equality deletes, position deletes, delete vectors, dan visibilitas snapshot.
- Merancang validasi bayangan (shadow validation), pengujian penulisan bersamaan, perlindungan pembersihan, dan jendela rollback.
- Menyadari bahwa kelulusan peningkatan dependensi bukanlah bukti kebenaran kueri historis.
- Menentukan metrik yang dapat diaudit, batas penghentian (stop lines), dan gerbang pembersihan pasca-peningkatan.
Pertanyaan klarifikasi
- Mesin, Catalog, penyimpanan objek, dan runtime Iceberg mana yang diterapkan? Apakah writer bersifat multibahasa?
- Versi format, jenis file penghapusan, partisi, retensi snapshot, dan tingkat komit apa yang berlaku?
- Apakah ini hanya penggantian dependensi klien, atau writer, reader, dan layanan Catalog juga berubah?
- Writer streaming dan kueri downstream mana yang tidak dapat dijeda?
Matriks versi dan kompatibilitas
Kunci pohon dependensi aktual dan versi yang diterapkan. Buat matriks untuk reader, writer, Catalog, FileIO, penyimpanan objek, dan tugas pembersihan. Perbaikan pada 1.10.2 tidak membuktikan bahwa mesin lama memahami metadata baru; gunakan panduan kompatibilitas resmi ditambah pengujian pemutaran ulang (replay tests). Luncurkan secara bertahap pada reader hanya-baca, writer offline, writer online, dan tahap pembersihan.
Di lingkungan canary, salin snapshot produksi, file penghapusan, dan komit yang bersamaan. Catat ID snapshot, jumlah manifes, jumlah file penghapusan, dan versi format tabel yang dibaca oleh setiap komponen. Tandai kompatibilitas yang tidak diketahui sebagai penghambat (blocker), bukan memperlakukan fakta bahwa "itu bisa dibaca" sebagai bukti.
Semantik penghapusan dan validasi kebenaran
Buat set data acuan (golden dataset) dengan kunci kesetaraan berulang, beberapa versi baris, position deletes, delete vectors, dan pembaruan bersamaan. Bandingkan reader sebelum dan sesudah peningkatan pada snapshot yang sama, kueri time-travel, dan pemindaian inkremental. Periksa jumlah baris, set kunci utama, agregat, dan pengurutan skema; catat baris yang difilter dan penghapusan yang tidak cocok.
Jangan memvalidasi tabel saat ini saja: penghapusan yang buruk dapat muncul ke permukaan setelah pemadatan (compaction). Pertahankan manifes asli, file penghapusan, dan log snapshot, serta lakukan pemeriksaan silang dengan SQL independen atau implementasi kecil yang presisi. Jika terjadi kegagalan, pertahankan snapshot dan jangan langsung menjadikannya kedaluwarsa.
Komit bersamaan dan perlindungan snapshot
Jalankan pengujian append, overwrite, penghapusan tingkat baris, dan pemadatan selama peningkatan. Masukkan konflik komit, batas waktu Catalog, dan error 503 penyimpanan objek yang bersifat sementara. Konfirmasikan bahwa transaksi yang gagal tidak dapat membersihkan file yang dirujuk oleh snapshot aktif dan bahwa komit yang berhasil mengekspos satu snapshot yang konsisten. Tetapkan batas penghentian khusus untuk penghapusan v2 yang bersamaan dengan peningkatan format.
Pembersihan menghitung kandidat dari retensi, kueri aktif, referensi branch atau tag, dan waktu komit. Kandidat masuk ke dalam antrean tertunda dan dihapus hanya setelah konfirmasi kedua. Selama rollback, larang pembersihan yang tidak dapat dibatalkan (irreversible) agar riwayat yang dapat dibaca tetap tersedia.
Penerapan, rollback, dan tata kelola
Rilis secara bertahap: layanan hanya-baca, writer bervolume rendah, lalu semua tugas. Setiap tahap mencatat kesalahan, latensi komit snapshot, perbedaan hasil kueri, penghapusan yang terlewat (delete misses), error 404 penyimpanan objek, kandidat pembersihan, dan biaya sumber daya. Rollback beralih ke klien yang kompatibel sambil tetap mempertahankan snapshot yang dibuat oleh versi baru untuk ditinjau; menghapus metadata bukanlah rollback.
Kunci dan pindai dependensi transitif dalam artefak build. Jika 1.10.2 menghapus atau mengubah test fixture atau artefak runtime, validasi pemaketan, classpath, dan lisensi dalam matriks build sebelum masuk ke produksi. Catat pengecualian manual beserta tanggal kedaluwarsanya.
Simulasi kegagalan dan gerbang rilis
Latih skenario perubahan urutan skema equality-delete, peningkatan format bersamaan, kegagalan pemuatan snapshot, pembersihan yang menerima 503, reader lama yang memuat snapshot baru, keterlambatan penyimpanan objek, dan komit duplikat selama pemulihan. Gerbang mencakup nol perbedaan hasil yang tidak dapat dijelaskan, penghapusan yang terlewat masih dalam batas toleransi, tidak ada file snapshot aktif yang dibersihkan, riwayat dapat dibaca setelah rollback, dan pemindaian dependensi yang berhasil.
Jika hanya pengurutan yang berbeda, tentukan apakah pengurutan memang tidak ditentukan sebelumnya. Jika set kunci utama atau visibilitas penghapusan berbeda, segera hentikan perluasan rilis. Setelah jendela retensi dan observasi, pulihkan pembersihan secara bertahap; tekanan kapasitas disk tidak membenarkan pengabaian retensi bukti.
Pertanyaan lanjutan dan jawaban referensi
Mengapa hanya membandingkan jumlah baris terbaru tidak cukup?
Hal itu mengabaikan time travel, pembacaan inkremental, penerapan file penghapusan, dan pembersihan historis. Bandingkan beberapa snapshot, set kunci utama, agregat, dan penghapusan yang terlewat pada golden dataset.
Bagaimana Anda membuktikan bahwa rollback aman?
Pertahankan snapshot sebelum dan sesudah, hentikan pembersihan yang tidak dapat dibatalkan, verifikasi bahwa reader lama dapat membaca jendela retensi, dan lakukan simulasi pemulihan setelah konflik komit dan kegagalan penyimpanan objek.
Bagaimana perbaikan keamanan dependensi masuk ke dalam validasi data?
Kunci dependensi transitif dan pindai artefak, lalu jalankan pengujian matriks classpath, lisensi, dan reader/writer. Pemindaian keamanan yang bersih tidak membuktikan semantik penghapusan.