Petunjuk dan konteks
Sebuah tabel Iceberg produksi menerima inkremen harian. Para engineer memerlukan penulisan yang terisolasi, pemeriksaan kualitas, publikasi atomik, penanda audit, dan pembersihan otomatis snapshot lama. Rancang branch, tag, referensi snapshot, commit konkuren, retensi, dan rollback. Ini adalah pertanyaan data tentang metadata format tabel dan tata kelola rilis.
Hal yang dievaluasi pewawancara
- Membedakan branch yang dapat diubah (mutable) dari tag yang tidak dapat diubah (immutable).
- Menjelaskan referensi snapshot,
main, dan snapshot saat ini. - Merancang pemeriksaan WAP, publikasi atomik, dan penanganan konflik.
- Mengonfigurasi retensi branch/tag tanpa menghapus bukti rollback.
- Membuktikan bahwa pembaca melihat satu snapshot yang konsisten, bukan berkas parsial.
Pertanyaan klarifikasi yang perlu diajukan
- Apakah katalog, engine, dan versi mendukung branch, tag, dan WAP?
- Apakah pembaca produksi selalu menggunakan
mainatau referensi eksplisit? - Batasan kualitas tabel, partisi, dan lintas-tabel apa saja yang diperlukan?
- Bisakah beberapa branch penulisan digabungkan secara bersamaan, dan bagaimana konflik diselesaikan?
- Berapa lama titik audit harus disimpan, dan siapa yang membersihkan berkas yatim (orphan)?
Jawaban 30 detik
“Saya akan menulis setiap job ke branch yang terisolasi dan menjalankan pemeriksaan kualitas terhadap snapshot-nya. Setelah disetujui, majukan main secara atomik dan buat tag yang tidak dapat diubah untuk titik audit. Branch dan tag mendapatkan aturan retensi independen; kedaluwarsa hanya dapat menghapus snapshot yang tidak direferensikan dan memenuhi kebijakan. Bandingkan ID snapshot, jumlah baris, metrik utama, dan hasil kueri sebelum dan sesudah rilis; konflik dicoba kembali atau diputuskan.”
Jawaban mendalam
Langkah 1: Tetapkan model referensi
Iceberg menyimpan branch dan tag sebagai referensi snapshot. Branch adalah rantai snapshot yang dapat diubah; tag menunjuk ke satu snapshot dan cocok untuk rilis, penutupan akhir bulan, dan audit. main produksi membutuhkan pemilik, dan layanan tidak boleh mengedit metadata tabel secara langsung.
main -> snapshot 120
audit-2026-08-01 (tag) -> snapshot 118
daily-load (branch) -> snapshot 121Diagram menunjukkan referensi; pemeriksaan commit katalog melindungi pembaruan sebenarnya.
Langkah 2: Mengimplementasikan Write-Audit-Publish
Fase penulisan melakukan commit data dan berkas hapus ke branch kerja tanpa mengubah main. Audit menjalankan pemeriksaan skema, keunikan, rentang, jumlah baris, dan lintas-tabel terhadap snapshot branch tersebut. Hanya snapshot yang disetujui yang memajukan referensi produksi, dengan pelaku, versi, dan laporan yang dicatat.
Langkah 3: Menangani commit konkuren
Pemeriksaan katalog optimistik menolak pembaruan berdasarkan leluhur yang lama. Job harus membaca ulang snapshot terbaru, menggabungkan atau me-rebase perubahannya, dan menjalankan ulang pemeriksaan yang diperlukan. Job tidak boleh menimpa referensi; bahkan penulisan partisi yang terpisah memerlukan kebijakan penggabungan yang eksplisit.
Langkah 4: Menjaga konsistensi baca
Kueri menyematkan ID snapshot atau versi referensi pada awal proses. Publikasi mengubah referensi metadata setelah berkas data selesai dan dapat dibaca. Job yang gagal mungkin meninggalkan berkas yang tidak direferensikan, tetapi pembersihan berkas yatim menunggu jendela commit dan keamanan.
Langkah 5: Mengatur kebijakan retensi dan audit
Tag mempertahankan snapshot rilis penting; branch dapat memiliki kebijakan usia maksimum dan jumlah snapshot. Masa kedaluwarsa pertama-tama menghitung snapshot yang direferensikan oleh main, branch, dan tag, kemudian hanya menghapus riwayat yang memenuhi syarat. Retensi tag audit harus mencakup jendela kepatuhan dan rollback.
Langkah 6: Merancang rollback
Rollback memindahkan main ke snapshot atau tag lama yang terverifikasi dan mencatat commit metadata baru. Jangan hapus snapshot yang rusak terlebih dahulu. Segarkan job hilir dan materialized view, memastikan cache tidak lagi menyajikan versi yang gagal.
Langkah 7: Tentukan metrik penerimaan
Lacak latensi commit branch, tingkat kelulusan pemeriksaan, keberhasilan publikasi, percobaan ulang konflik, jumlah snapshot yang direferensikan, volume kedaluwarsa, berkas yatim, dan waktu rollback. Bandingkan ID snapshot, jumlah baris, agregat utama, dan hasil hilir sebelum memperluas peluncuran.
Contoh jawaban
“Job harian menulis ke branch yang terisolasi dan menjalankan pemeriksaan terhadap snapshot tetap. Persetujuan memajukan main secara atomik dan membuat tag audit yang tidak dapat diubah. Kedaluwarsa melindungi setiap snapshot yang masih direferensikan oleh main, branch, atau tag sebelum membersihkan riwayat dan berkas yatim.
Pemeriksaan optimistik katalog menolak commit yang sudah usang; job membaca ulang leluhur terbaru dan menjalankan ulang validasi daripada menimpa referensi. Pembaca menyematkan snapshot, dan rollback mengarahkan main ke tag lama melalui commit metadata baru. Penerimaan membandingkan ID snapshot, baris, agregat, keberhasilan publikasi, konflik, dan waktu pemulihan.”
Kesalahan umum
- Memperlakukan branch sebagai tidak dapat diubah → commit berikutnya akan memindahkannya → gunakan tag untuk audit.
- Menimpa metadata
main→ melewati perlindungan konkurensi → lakukan commit melalui katalog. - Menghapus riwayat sebelum rollback → menghilangkan bukti → pertahankan tag dan buat commit rollback baru.
- Kedaluwarsa hanya berdasarkan usia → menghapus snapshot yang direferensikan → hitung set referensi terlebih dahulu.
- Tidak menyematkan snapshot kueri → pembacaan panjang mencampuradukkan versi → sematkan referensi atau ID snapshot.
- Membersihkan berkas yatim secara langsung → dapat menghapus berkas yang belum di-commit → tunggu jendela keamanan.
Pertanyaan lanjutan dan tanggapan
Tindak lanjut 1: Mengapa menggunakan tag untuk publikasi?
Branch bergerak maju; tag menetapkan satu snapshot, membuatnya cocok untuk audit, akhir bulan, dan rollback. Keduanya dapat memiliki siklus hidup terpisah.
Tindak lanjut 2: Bagaimana jika dua branch menulis partisi yang sama?
Tolak commit yang usang, gabungkan dari leluhur terbaru, atau lakukan adjudikasi manual. Jangan pernah menimpa berdasarkan nama berkas.
Tindak lanjut 3: Bisakah masa kedaluwarsa menghapus titik rollback?
Tidak selama snapshot direferensikan oleh branch atau tag dan berada dalam kebijakan retensi. Referensi harus menjadi bagian dari set yang dilindungi kedaluwarsa.
Tindak lanjut 4: Bagaimana Anda mencegah pembacaan data parsial?
Tulis berkas secara lengkap terlebih dahulu, publikasikan satu snapshot main atomik, dan jauhkan branch yang belum dipublikasikan dari kueri produksi.