Pertanyaan dan cakupan
Sebuah batch job melakukan backfill dimensi pesanan selama 90 hari dan logika transformasinya kemudian diketahui salah. Penulisan streaming terus berlanjut selama proses berjalan. Rancang cara menemukan snapshot yang buruk, mereproduksi kueri yang terpengaruh, mengisolasi perbaikan, menangani konflik commit, dan mengatur retensi. Keterampilan intinya adalah pembuatan versi format tabel (table-format versioning), lineage, dan operasi yang dapat dipulihkan, sehingga ini termasuk dalam data engineering.
Apa yang dievaluasi pewawancara
Jawaban harus menjelaskan bahwa snapshot adalah penunjuk metadata (metadata pointer), bukan sekadar salinan file biasa, dan bahwa time travel bergantung pada retensi. Cakup commit konkuren, efek rollback, konsistensi pembacaan downstream, kedaluwarsa snapshot, dan pembersihan orphan file. Hanya menjawab "pulihkan ke kondisi kemarin" tidak menunjukkan keamanan.
Pertanyaan klarifikasi di awal
- Katalog, mesin, dan kunci commit apa yang digunakan, serta bagaimana ID snapshot diaudit?
- Partisi, snapshot, dan tabel downstream mana yang terpengaruh?
- Apakah streaming job melakukan commit selama backfill yang buruk, dan bisakah mereka dijeda atau diputar ulang dari snapshot?
- Apakah bisnis meminta rollback tabel secara menyeluruh, rewrite partisi, atau tabel pengganti untuk validasi?
- Berapa lama snapshot dan file data disimpan, dan mungkinkah pembersihan menghapus bukti pemulihan?
Kerangka jawaban 30 detik
“Saya pertama-tama mengidentifikasi commit backfill dari riwayat tabel dan log job, lalu membandingkan snapshot-nya dengan parent menggunakan kueri time-travel untuk membatasi partisi yang terpengaruh. Saya mengisolasi input yang benar, menjalankan ulang validasi, dan memilih rewrite partisi, snapshot perbaikan, atau rollback hanya jika tidak ada commit valid berikutnya yang harus dipertahankan. Sebelum mengubah pointer, saya memeriksa commit konkuren dan reader; setelah itu saya membangun kembali tabel downstream. Tunda kedaluwarsa snapshot dan pembersihan orphan file hingga jendela pemulihan ditutup, serta pantau metrik snapshot, file, dan kualitas data.”
Solusi langkah demi langkah
Baca riwayat tabel, daftar snapshot, dan ringkasan commit. Catat ID snapshot, waktu commit, ID eksekusi, rentang partisi, dan versi input. Jangan menyimpulkan target hanya dari waktu jam dinding (wall-clock time) karena commit konkuren dapat saling bertumpukan. Bandingkan snapshot yang buruk dengan parent-nya dalam metadata dan file data, lalu gunakan log job, peringatan kualitas, dan statistik partisi untuk membatasi dampak.
Gunakan kueri time-travel untuk mereproduksi metrik bisnis yang sama sebelum dan sesudah penulisan yang buruk. Snapshot memberikan tampilan baca yang konsisten, tetapi tidak mempertahankan riwayat tanpa batas; selesaikan kueri sebelum kedaluwarsa atau ekspor sampel validasi dan referensi metadata jika diperlukan.
Jika penulisan streaming masih aktif, jeda partisi yang berkonflik atau buat branch terisolasi atau tabel sementara. Baca input yang benar pada snapshot yang sesuai, perbaiki transformasi, dan lakukan commit perbaikan hanya setelah memeriksa bahwa snapshot parent masih merupakan versi yang diharapkan. Jika terjadi konflik, baca ulang snapshot terbaru dan hitung ulang alih-alih menimpa paksa (force-overwrite) penulisan yang valid.
Rollback seluruh tabel hanya tepat dilakukan jika tidak ada commit valid berikutnya yang harus dipertahankan dan pembaca (reader) dapat menerima regresi sementara. Lebih seringnya, tulis ulang partisi yang terpengaruh atau publikasikan tabel yang telah diperbaiki dan alihkan referensi downstream. Memindahkan pointer metadata tidak memperbaiki data yang telah dimaterialisasi ke dalam tabel lain.
Setelah perbaikan, jalankan kembali pemeriksaan keunikan, jumlah baris, nominal, latensi, dan rekonsiliasi bisnis. Bandingkan snapshot yang buruk, snapshot perbaikan, dan raw event. Hitung ulang tabel downstream dari versi perbaikan dan catat snapshot baru serta versi kode agar eksekusi dapat direproduksi.
Retensi harus mencakup batas waktu backfill, peninjauan, komputasi ulang downstream, dan audit. Mengedaluwarsa snapshot terlalu dini dapat menyebabkan time travel gagal. Hanya file yang tidak lagi direferensikan oleh snapshot yang dipertahankan yang boleh dihapus setelah memastikan tidak ada reader yang membutuhkannya; pembersihan orphan file tidak boleh menghapus file yang masih direferensikan oleh job yang belum di-commit atau berjalan konkuren.
Pantau usia snapshot, konflik commit, jumlah rollback, jumlah orphan file, kegagalan kedaluwarsa, kualitas partisi, keterlambatan komputasi ulang downstream, dan selisih rekonsiliasi. Tulis ID snapshot, ID eksekusi, versi kode, dan partisi input ke tabel audit sehingga hasilnya dapat dilacak kembali ke commit-nya.
Contoh jawaban berkualitas tinggi
“Saya menyimpan riwayat tabel, ID snapshot, dan ID eksekusi, mengidentifikasi commit backfill, serta menggunakan kueri time-travel antara parent dan child untuk membatasi partisi yang terpengaruh. Jika penulisan streaming berlanjut, saya menjeda rentang konflik atau menulis perbaikan ke tabel terisolasi, memvalidasi snapshot parent pada waktu commit, dan membaca ulang saat terjadi konflik alih-alih menimpa secara paksa.
Jika tidak ada commit valid berikutnya yang harus dipertahankan, saya dapat melakukan rollback pointer metadata; jika tidak, saya menulis ulang partisi dan memublikasikan snapshot perbaikan. Rollback tidak memperbaiki tabel downstream yang telah dimaterialisasi, jadi saya menghitungnya kembali dari versi perbaikan dan menjalankan ulang pemeriksaan kualitas serta rekonsiliasi. Kedaluwarsa snapshot dan pembersihan orphan file ditunda hingga melewati jendela audit, dan setiap snapshot, versi kode, serta rentang input dicatat.”
Kesalahan umum
- Menebak snapshot dari timestamp-nya → commit konkuren dapat saling bertumpukan → gunakan riwayat, garis keturunan parent (parentage), dan ID eksekusi.
- Memperlakukan snapshot sebagai cadangan file → rollback mungkin tidak memperbaiki tabel downstream → inventarisasi pointer metadata dan data turunan.
- Menimpa paksa snapshot terbaru → kehilangan penulisan konkuren yang valid → periksa parent dan coba lagi saat terjadi konflik.
- Membersihkan snapshot lama secara langsung → time travel dan bukti audit menghilang → pertahankan jendela pemulihan.
- Hanya memvalidasi sampel baris → kesalahan agregat tetap ada → periksa partisi, metrik, keunikan, dan rekonsiliasi.
- Hanya melakukan rollback pada tabel utama → hasil downstream tetap salah → hitung ulang tabel turunan dari versi perbaikan.
- Menganggap pembersihan orphan file tidak berbahaya → job konkuren mungkin masih mereferensikan file → bersihkan dengan memeriksa status commit dan reader.
- Menghilangkan versi kode dan input → perbaikan tidak dapat direproduksi → hubungkan snapshot, eksekusi, dan versi dalam data audit.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Kapan rollback tabel lebih baik daripada rewrite partisi?
Hanya ketika tidak ada commit valid setelah titik rollback yang harus disimpan dan reader menerima regresi sementara. Jika tidak, tulis ulang partisi atau publikasikan tabel yang telah diperbaiki.
Pertanyaan lanjutan 2: Mengapa time travel bisa gagal?
Snapshot target mungkin telah kedaluwarsa, atau file-filenya mungkin telah dihapus. Retensi harus mencakup investigasi dan komputasi ulang, dan pembersihan harus dipantau.
Pertanyaan lanjutan 3: Bagaimana cara menghindari penimpaan data streaming baru?
Batasi perbaikan pada partisi yang terpengaruh, jeda writer yang berkonflik atau isolasi pekerjaannya, validasi snapshot parent, dan hitung ulang dari versi terbaru setelah terjadi konflik.
Pertanyaan lanjutan 4: Apakah rollback membatalkan event downstream?
Tidak. Tindakan ini hanya mengubah pointer metadata tabel. Event yang telah terkirim, tabel yang telah dimaterialisasi, dan efek eksternal memerlukan kompensasi atau komputasi ulang terpisah.
Pertanyaan lanjutan 5: Apa perbedaan antara snapshot dan full backup?
Snapshot biasanya merupakan tampilan metadata dari sekumpulan file dan bergantung pada retensi file tersebut. Full backup juga memerlukan salinan lintas penyimpanan (cross-storage), status katalog, dan prosedur pemulihan.
Pertanyaan lanjutan 6: Bagaimana Anda membuktikan bahwa perbaikan backfill sudah benar?
Kunci snapshot input dan versi kode, jalankan ulang partisi, bandingkan raw event dan metrik bisnis, periksa keunikan dan nominal, lakukan rekonsiliasi, dan simpan snapshot perbaikan untuk ditinjau.
Pertanyaan lanjutan 7: Mengapa konflik commit itu penting?
Commit Iceberg diperbarui dari snapshot parent. Mengabaikan konflik dan memaksakan penulisan dapat membuang commit valid milik job lain; konflik harus memicu pembacaan ulang, komputasi ulang, atau keputusan manual.