Prompt dan cakupan
Sebuah tabel Iceberg diorganisasikan berdasarkan tanggal dan tenant. Kueri sering kali memfilter kolom status dengan kardinalitas rendah, namun proses perencanaan masih memeriksa banyak file data. Tim ingin menyimpan indeks atau statistik yang tidak muat langsung di manifes ke dalam file Puffin dan membiarkan perencana (planner) menggunakannya secara selektif. Jelaskan snapshot binding, proteksi statistik usang (stale), statistik yang hilang, commit konkuren, dan bukti bahwa akselerasi tidak mengorbankan kebenaran data.
Kapasitas, selektivitas, dan jumlah file adalah asumsi wawancara, bukan tolok ukur universal. Pertanyaan ini cocok untuk peran data engineering, penyimpanan lakehouse, query engine, dan platform data. Keterampilan intinya adalah metadata dan perencanaan format tabel, sehingga termasuk dalam data.
Apa yang dinilai oleh pewawancara
Pertama, apakah Anda memahami batasan Puffin? Puffin adalah format file untuk indeks dan statistik tentang tabel Iceberg; metadata blob mendeskripsikan isinya. Puffin tidak menggantikan snapshot atau manifes tabel.
Kedua, dapatkah Anda memisahkan optimasi opsional dari metadata kebenaran? Reader dapat mengabaikan statistik dan tetap membaca dengan benar. Pemangkasan (pruning) hanya boleh menghapus kandidat yang terbukti tidak cocok.
Ketiga, dapatkah Anda mengikat statistik ke snapshot dan cakupan? Setiap blob memerlukan snapshot, partisi, atau rentang file data yang berlaku; pembaruan tidak boleh menggunakan kembali blob lama secara membabi buta.
Keempat, dapatkah Anda mengukur pemeliharaan? File tambahan menambah I/O penyimpanan objek, caching, pekerjaan pembuatan (generation jobs), dan tugas kedaluwarsa; kueri dengan selektivitas rendah mungkin membayar overhead perencanaan tanpa manfaat.
Kelima, dapatkah Anda merancang fallback? Blob yang hilang, tidak dapat dibaca, tidak kompatibel, atau tidak valid harus mengarahkan planner kembali ke manifes dan filter file data, jangan pernah ke hasil kosong.
Pertanyaan untuk diklarifikasi terlebih dahulu
- Versi Iceberg dan query engine mana yang mendukung jenis blob Puffin target?
- Apakah statistik dibuat per partisi, file data, kolom, atau rentang nilai?
- Seberapa sering snapshot di-commit, ditulis ulang, atau dilakukan time-travel?
- Tingkat keusangan (staleness) pembuatan apa yang dapat diterima, dan apakah optimasi eventual dapat diterima?
- Bagaimana kompresi blob, checksum, enkripsi, dan izin objek dikelola?
- Bagaimana planner membuktikan bahwa seorang kandidat aman untuk dikecualikan?
Kerangka jawaban 30 detik
"Saya akan memverifikasi jenis blob Puffin yang didukung dan kaitannya dengan snapshot Iceberg. Statistik adalah optimasi opsional, bukan prasyarat kebenaran; setiap blob mencatat snapshot, partisi, atau cakupan filenya, dan planner akan melakukan fallback ke manifes ketika blob hilang, usang, atau tidak dapat dibaca. Pekerjaan pembuatan menggunakan snapshot tetap dan meng-commit referensi secara atomik, alih-alih menggunakan kembali statistik lama untuk snapshot baru. Dalam canary test, saya akan membandingkan file kandidat, waktu perencanaan, I/O Puffin tambahan, latensi end-to-end, dan validasi hasil."
Jawaban langkah demi langkah
Langkah 1: Tetapkan hubungan Puffin dan snapshot
Puffin menyimpan indeks dan statistik yang tidak muat langsung dalam manifes Iceberg. StatisticsFile API mengekspos jalur, ukuran file, ukuran footer, metadata blob, dan snapshot ID terkait. Tempatkan bidang-bidang ini dalam kontrak metadata alih-alih hanya menyimpan jalur objek dalam pengaturan eksternal.
Langkah 2: Tentukan konten dan cakupan blob
Setiap blob harus mendeklarasikan tipe, versi, pengodean, partisi atau file data yang dicakup, snapshot pembuatan, kolom, dan aturan perbandingan. Kolom status dengan kardinalitas rendah dapat menggunakan jumlah partisi atau ringkasan rentang nilai; ringkasan kardinalitas tinggi yang tidak aman harus tetap observasional alih-alih memangkas file.
statistics = build_from_snapshot(snapshot_id, data_files)
blob = {
type, version, snapshot_id, partition_scope,
covered_files, column_rules, checksum, payload
}
commit_statistics_file(blob)Langkah 3: Rancang pemangkasan (pruning) yang aman
Planner mengecualikan kandidat hanya jika statistik membuktikan bahwa kandidat tersebut tidak cocok. Statistik yang hilang, rentang nilai yang tumpang tindih, semantik null yang tidak pasti, versi blob yang tidak dikenal, atau kegagalan checksum semuanya memicu pemfilteran manifes dan file data. "Tidak ada statistik" tidak boleh diartikan sebagai "tidak ada data".
Langkah 4: Tangani commit konkuren dan keusangan
Pekerjaan pembuatan membaca snapshot tetap dan, pada saat commit, memverifikasi bahwa tabel masih dapat mereferensikan snapshot tersebut atau turunan yang kompatibel. Operasi penulisan baru, penghapusan, dan evolusi partisi mengubah kumpulan file; blob lama hanya valid untuk cakupan yang dideklarasikan. Jangan memperbarui objek Puffin di tempat (in-place).
Langkah 5: Rencanakan pembacaan dan cache dengan aman
Puffin sendiri memiliki I/O footer dan blob. Planner harus menggunakan metadata ringan untuk memutuskan apakah sebuah blob layak dibaca, lalu memilih blob berdasarkan kolom kueri dan partisi. Kunci cache mencakup identitas tabel, snapshot, tipe blob, dan versi. Kesalahan pembacaan membatalkan cache dan memicu fallback; kesalahan tidak boleh di-cache sebagai statistik kosong.
Langkah 6: Anggarkan biaya, kedaluwarsa, dan izin
Lacak byte blob, rasio footer, CPU pembuatan, permintaan objek, dan hit rate pemangkasan. Setelah kedaluwarsa snapshot atau penulisan ulang file, bersihkan statistik berdasarkan hubungan referensi, bukan hanya waktu modifikasi objek. Berikan akses least-privilege ke generator dan reader, validasi checksum, dan enkripsi ringkasan sensitif jika diperlukan.
Langkah 7: Jalankan uji penerimaan canary
Pada snapshot yang sama, bandingkan perencanaan dengan statistik diaktifkan dan dinonaktifkan: file kandidat, byte yang dipindai, p50/p95 perencanaan, I/O Puffin tambahan, latensi end-to-end, dan hash hasil. Hapus blob, buat ketidakcocokan versi, dan lakukan race condition dengan commit konkuren untuk membuktikan bahwa fallback mengembalikan hasil yang lengkap. Pertahankan kueri dengan selektivitas rendah sebagai kontrol negatif.
Jawaban model
"Saya akan memperlakukan Puffin sebagai lapisan akselerasi perencanaan opsional. Generator membaca snapshot tetap, dan metadata blob mencatat snapshot, cakupan partisi atau file, aturan kolom, versi, dan checksum. Snapshot baru tidak boleh menggunakan kembali blob di luar cakupan yang dideklarasikan tersebut.
Planner hanya memangkas jika statistik secara aman membuktikan ketidakcocokan. Blob yang hilang, usang, tidak dapat dibaca, null yang ambigu, atau versi yang tidak dikenal akan melakukan fallback ke manifes dan filter file data; hilangnya statistik tidak pernah berarti hasil kosong. Kunci cache mencakup tabel, snapshot, tipe, dan versi.
Dalam canary test, saya akan membandingkan file kandidat, waktu perencanaan, I/O Puffin, p95 end-to-end, dan hash hasil, sambil menginjeksikan blob yang hilang dan commit konkuren. Saya akan memperluas penggunaannya hanya jika peningkatan performa stabil, fallback berjalan benar, dan biaya pemeliharaan dapat diterima."
Kesalahan umum
- Memperlakukan Puffin sebagai sumber kebenaran (source of truth) snapshot → statistik usang mengubah hasil → jadikan opsional dengan fallback ke manifes.
- Hanya mencatat jalur objek → cakupan dan snapshot tidak dapat diperiksa → simpan metadata blob yang lengkap.
- Memangkas dengan blob usang → penulisan atau penghapusan baru terlewatkan → ikat snapshot dan file yang dicakup.
- Mengembalikan hasil kosong untuk statistik yang hilang → yang tidak diketahui dianggap tidak cocok → fallback ke pemfilteran normal.
- Menimpa Puffin di tempat (in place) → reader konkuren melihat versi campuran → tulis file baru dan referensikan secara atomik.
- Caching tanpa snapshot → snapshot yang berbeda menggunakan kembali statistik yang salah → sertakan versi dan snapshot dalam kunci.
- Hanya mengukur waktu perencanaan → hasil pemindaian dapat berubah → bandingkan set kandidat dan hash hasil.
- Menghapus berdasarkan waktu modifikasi → snapshot yang dipertahankan mungkin masih mereferensikan file → kedaluwarsakan berdasarkan referensi.
Pertanyaan lanjutan
Pertanyaan lanjutan 1: Mengapa reader boleh mengabaikan statistik?
Statistik Puffin bersifat informasional. Tabel masih dapat dibaca dengan benar dari manifes dan file data, sehingga blob yang tidak didukung atau sementara tidak dapat dibaca harus menyebabkan fallback yang transparan.
Pertanyaan lanjutan 2: Bagaimana cara Anda mengedaluwarsakan statistik?
Konfirmasikan bahwa tidak ada snapshot, branch, atau tag yang dipertahankan yang memerlukan rentang yang dicakup blob, lalu bersihkan sesuai dengan referensi format tabel. Waktu modifikasi objek saja tidak cukup.
Pertanyaan lanjutan 3: Bagaimana jika rentang nilai tidak lengkap?
Perlakukan bagian yang tidak diketahui sebagai berpotensi cocok dan perluas kandidat atau lakukan fallback sepenuhnya. Optimasi boleh memiliki false positive, tetapi tidak boleh memiliki false negative.
Pertanyaan lanjutan 4: Kapan statistik harus dibuat selama penulisan konkuren?
Buat dari snapshot yang telah di-commit dan ikat setelah metadata di-commit; file sementara dari proses penulisan yang sedang berjalan tidak boleh terlihat oleh perencanaan. Periksa kembali kompatibilitas pada saat commit.
Pertanyaan lanjutan 5: Kapan Puffin tidak sepadan dengan biayanya?
Nonaktifkan atau persempit saat selektivitas rendah, I/O blob melebihi penghematan manifes, pembuatan terlalu usang, atau biaya pemeliharaan melebihi keuntungan. Pertahankan tombol pengaktifan per tabel.
Pertanyaan lanjutan 6: Bagaimana Anda membuktikan bahwa optimasi mempertahankan kebenaran hasil?
Jalankan kueri yang setara pada snapshot yang sama dengan statistik diaktifkan dan dinonaktifkan, bandingkan hasil lengkap, agregat, file kandidat, dan sampel batas, lalu injeksikan blob yang hilang, rusak, dan tidak kompatibel untuk menguji fallback.