Wawancara data engineering: Menautkan indeks vektor dengan aman ke snapshot Apache Iceberg

Pertanyaan dan skenario

Rancang ekstensi pencarian vektor untuk tabel Iceberg. File data menyimpan data baris dan mesin kueri membaca snapshot; indeks vektor berada di file sidecar Puffin dan direferensikan oleh metadata snapshot. Rancangan harus mendukung kueri approximate nearest-neighbor tanpa merusak isolasi snapshot, time travel, atau pemeliharaan file data.

Asumsikan batch append harian dan pembaruan kecil. Hasil perkiraan hanya dapat diterima jika versi indeks terlihat oleh pemanggil. Bedakan kapabilitas format file Apache Puffin dari tata letak ANN tertentu yang diusulkan oleh riset; desain graf eksperimental tidak secara otomatis menjadi perilaku bawaan Iceberg.

Hal yang diuji oleh pewawancara

Konsistensi snapshot dan indeks

Jawaban yang kuat mengikat snapshot data, blob Puffin, dan metadata indeks dalam satu commit yang terlihat. Mengunggah file indeks saja tidak membuatnya langsung dapat dikueri.

Pencarian perkiraan dan pemangkasan file (file pruning)

Jelaskan bahwa indeks vektor mengambil kandidat, sedangkan pemeriksaan jarak akhir dan visibilitas tetap membaca baris data. Tangani indeks yang hilang, usang (stale), dan ber-recall rendah secara eksplisit.

Pemeliharaan inkremental dan penghapusan

Cakup append, pembaruan, penghapusan, merge, dan pemadatan (compaction). Jangan berhenti hanya pada proses pembangunan offline satu kali.

Operabilitas dengan komputasi dan penyimpanan terpisah

Jelaskan bagaimana penyimpanan objek menyimpan Puffin, bagaimana koordinator menjadwalkan shard, bagaimana sampah (garbage) dibatasi, serta bagaimana kesegaran (freshness) dan fallback dipantau.

Pertanyaan klarifikasi sebelum menjawab

Berapa dimensi embedding, fungsi jarak, latensi kueri, dan recall minimum?
Apakah kueri harus menggunakan snapshot terbaru, atau apakah lag indeks yang dibatasi dapat diterima?
Apakah pembaruan dan penghapusan berupa CDC append-only, equality deletes Iceberg, atau penulisan ulang file data?
Apakah ada satu mesin yang membangun indeks, atau apakah Spark, Flink, dan Trino harus membagikannya?
Apakah vektor bersifat sensitif, dan siapa yang mengelola kontrol akses serta enkripsi?
Apakah kueri time-travel harus menggunakan kembali indeks historis, atau apakah pengindeksan hanya diperlukan untuk snapshot saat ini?

Kerangka jawaban 30 detik

“Saya akan memisahkan file data Iceberg, blob indeks Puffin, dan metadata snapshot, tetapi memublikasikan ikatannya dalam satu commit untuk satu snapshot ID. Kueri memilih snapshot yang terlihat, membaca referensi indeksnya, melakukan pengambilan kandidat ANN, lalu memvalidasi versi baris dan jarak pasti dari file data. Indeks yang hilang atau usang akan beralih (fallback) ke pemindaian partisi atau file dan mengekspos status kualitas. Append dapat membuat indeks delta; pembaruan dan penghapusan difilter oleh tombstone atau layer penghapusan; compaction membangun kembali baseline. Tugas pengindeksan menggunakan commit snapshot optimis, dan kami memantau kesegaran, sampel recall, tingkat fallback, dan sampah Puffin.”

Jawaban mendalam langkah demi langkah

Langkah 1: Estimasi batasan data dan indeks

Sebagai asumsi ilustratif, 1 miliar vektor dengan 768 dimensi float32 membutuhkan 1 miliar dikali 768 dikali 4 byte, sekitar 3 TB untuk vektor mentah sebelum kompresi kolumnar atau overhead indeks. Estimasi ini menyingkirkan opsi menempatkan indeks dalam satu manifes atau memori koordinator; lakukan sharding di penyimpanan objek dan muat berdasarkan partisi kueri.

Langkah 2: Mengikat Puffin ke snapshot

Puffin menyimpan blob indeks atau statistik yang tidak dapat dibawa langsung oleh manifes Iceberg. Setiap blob mencakup metadata seperti tipe, field, partisi, atau referensi file data. Pembangun indeks menulis Puffin, lalu melakukan commit snapshot Iceberg baru yang ringkasannya (summary) mencatat lokasi, versi, dan cakupan indeks. Pembaca hanya menerima referensi jika terlihat bersama snapshot tersebut.

text

snapshot S42
  data files: D100, D101
  summary:
    vector.index.version = v7
    vector.index.puffin = s3://table/metadata/puffin-v7
    vector.index.covers = D100,D101

Langkah 3: Merancang alur kueri

Arahkan cabang saat ini atau permintaan time-travel ke snapshot S, lalu pilih blob Puffin berdasarkan cakupan. Graf atau shard ANN mengembalikan pengidentifikasi baris kandidat dan jarak perkiraan. Mesin membaca file-file data tersebut, memeriksa visibilitas baris di S, menerapkan otorisasi dan predikat, lalu menghitung ulang jarak pasti. Kembalikan snapshotid dan indexversion agar pemanggil dapat menilai kesegaran data.

Langkah 4: Menangani append, pembaruan, dan penghapusan

Append dapat menulis indeks Puffin delta dan mendeklarasikan file-filenya dalam commit snapshot yang sama. Sebelum pembangunan ulang, pembaruan atau penghapusan memfilter kandidat lama dengan equality deletes, position deletes, atau delta tombstone; kueri tidak boleh mengembalikan baris yang telah dihapus. Gabungkan indeks delta ke dalam baseline baru di latar belakang, lalu publikasikan ikatan snapshot baru secara atomik. Jika terjadi kegagalan, pertahankan indeks lama dan jalur fallback.

Langkah 5: Menangani concurrent commit dan compaction

Tugas indeks membaca baseline S42 dan membangun v7. Jika commit data memajukan tabel ke S43, konkurensi optimis memutuskan apakah akan mencoba lagi, menggabungkan delta, atau membatalkan v7. Ketika compaction mengubah jalur file data, indeks lama tidak dapat mengklaim cakupan atas file baru. Bangun blob baru yang terikat pada kumpulan file yang ditulis ulang, lalu bersihkan (garbage-collect) blob lama setelah pelacakan referensi dan masa tenggang (grace period).

Langkah 6: Operasi, isolasi, dan fallback

Penyimpanan objek menyimpan Puffin; koordinator menjadwalkan pembangunan berdasarkan partisi atau kumpulan file; node kueri menyimpan cache struktur perutean atau centroid kecil. Blob yang hilang, versi yang tidak kompatibel, kegagalan otorisasi, atau sampel recall rendah akan memicu fallback pemindaian file atau respons yang hanya berisi kandidat terverifikasi beserta alasannya. Lacak kesegaran indeks, build lag, p95 kueri, sampel recall, byte Puffin, tingkat fallback, dan blob yang tidak direferensikan.

Contoh jawaban berkualitas tinggi

“Saya akan menyimpan kolom vektor di file data Iceberg, menulis struktur ANN ke Puffin, dan memublikasikan referensinya sebagai bagian dari snapshot. Dengan asumsi ilustratif 1 miliar vektor float32 berdimensi 768, vektor mentah berukuran sekitar 3 TB, sehingga indeks harus di-shard di penyimpanan objek alih-alih ditampung oleh koordinator.

Pembangun membaca S42, membuat Puffin v7 yang mencakup D100 dan D101, dan menggunakan commit optimis untuk memublikasikan snapshot baru. Kueri menetapkan snapshot untuk permintaan time-travel, hanya membaca indeks yang dideklarasikan untuk snapshot tersebut, dan memvalidasi visibilitas kandidat, otorisasi, serta jarak pasti dengan membaca file data. Selama indeks usang, append menggunakan indeks delta dan pembaruan atau penghapusan difilter oleh file delete atau tombstone; compaction kemudian membangun kembali baseline.

Jika tabel telah beralih ke S43, v7 tidak dapat dinyatakan sebagai versi terkini tanpa percobaan ulang atau penanda usang yang eksplisit. Blob yang hilang, format yang tidak kompatibel, atau recall rendah akan memicu fallback pemindaian, dengan menyertakan snapshotid, indexversion, dan alasan pada metrik. Reklamasi Puffin lama hanya setelah tidak ada snapshot historis atau cabang yang mereferensikannya.”

Kesalahan umum

Memperlakukan Puffin sebagai format tabel utama yang baru → kueri tidak dapat membuktikan versi data mana yang dicakup oleh indeks → ikat cakupan ke snapshot.
Membuat indeks yang diunggah langsung dapat dibaca → file data dan indeks mungkin berasal dari snapshot yang berbeda → publikasikan referensi dalam satu commit optimis.
Mengembalikan kandidat ANN secara langsung → penghapusan, izin, atau kesalahan jarak membocorkan baris yang salah → periksa kembali visibilitas dan hitung ulang jarak pasti.
Terus menggunakan graf lama setelah pembaruan → baris yang dihapus dapat terambil kembali → filter dengan layer penghapusan, gabungkan delta, dan bangun kembali baseline.
Menggunakan kembali jalur file lama setelah compaction → indeks mengklaim mencakup file yang sudah tidak ada → bangun blob dan snapshot baru untuk set yang ditulis ulang.
Memperlakukan tata letak graf riset sebagai standar Puffin → mesin kueri tidak dapat saling beroperasi → gunakan Puffin untuk penyimpanan dan metadata, dengan algoritma graf yang dapat diganti.
Menggagalkan setiap kueri saat indeks hilang → layanan menjadi tidak tersedia selama peluncuran partisi baru → lakukan pemindaian sebagai fallback dan ekspos kesegaran beserta alasannya.
Menghapus Puffin tanpa pelacakan referensi → pembacaan time-travel atau cabang menjadi rusak → tunggu sampai setiap snapshot, cabang, dan masa tenggang melepaskannya.

Pertanyaan lanjutan dan tanggapan

Pertanyaan lanjutan 1: Bagaimana Anda menjamin indeks yang tepat untuk time travel?

Simpan referensi dalam ringkasan (summary) snapshot yang sesuai beserta cakupan file dan versinya. Tetapkan snapshot terlebih dahulu, tolak blob yang mencakup file yang lebih baru atau berbeda, dan lakukan pemindaian jika tidak ada alih-alih secara diam-diam menggunakan indeks saat ini.

Pertanyaan lanjutan 2: Apakah aliran pembaruan besar akan membuat indeks delta menjadi tak terbatas?

Tetapkan batas layer delta per partisi atau kumpulan file dan jadwalkan pembangunan ulang merge jika batas terlampaui. Beralih secara atomik ke snapshot baru setelah penggabungan, dengan mempertahankan delta lama hingga snapshot historis tidak lagi mereferensikannya.

Pertanyaan lanjutan 3: Bisakah dua mesin bertukar indeks ANN mereka?

Hanya jika tipe blob, fungsi jarak, pengodean vektor, pengidentifikasi baris, dan protokol versi kompatibel. Puffin mendefinisikan batas kontainer dan metadata; graf memerlukan deklarasi kapabilitas. Jika tidak, abaikan dan lakukan fallback.

Pertanyaan lanjutan 4: Bagaimana cara mengukur recall tanpa memindai seluruh tabel?

Ambil sampel sebagian kecil kueri langsung dan hitung perkiraan ground truth secara offline dengan pencarian eksak atau baseline tepercaya. Bandingkan recall@k berdasarkan partisi, versi vektor, dan fungsi jarak. Tandai indeks sebagai usang ketika sampel berada di bawah ambang batas alih-alih hanya memantau p95.

Pertanyaan lanjutan 5: Bagaimana jika file Puffin atau penyimpanan objek tidak tersedia untuk sementara?

Verifikasi checksum dan metadata blob, coba lagi dari replika, lalu lakukan pemindaian atau tolak pencarian perkiraan dengan status eksplisit setelah batas waktu (timeout). Jangan pernah memublikasikan snapshot baru yang mereferensikan blob yang rusak.

Sumber 1: Spesifikasi Apache Puffin

Spesifikasi Puffin mendefinisikan format file untuk indeks dan statistik yang tidak dapat disimpan langsung di manifes Iceberg, termasuk metadata blob dan referensi file data. Hal ini mendukung batasan sidecar, cakupan, dan snapshot dalam jawaban ini.

Sumber 2: Riset indeks vektor berbasis Puffin

Makalah tahun 2026 mengusulkan penautan struktur approximate-nearest-neighbor ke snapshot Iceberg dan membahas pemisahan komputasi-penyimpanan, manajemen indeks tingkat snapshot, dan lingkungan miliaran vektor. Jawaban ini memperlakukannya sebagai implementasi riset yang dapat diganti serta menambahkan batasan penghapusan, fallback, dan concurrent commit.

Sumber 3: Panduan persiapan wawancara data engineering

Panduan data engineering publik menekankan SQL, pemodelan data, pipeline, sistem batch dan streaming, serta keandalan. Jawaban ini memetakan sinyal-sinyal tersebut ke konsistensi snapshot, pemeliharaan indeks, sharding, verifikasi, dan fallback kegagalan.